A secrets manager has one job: keep your secret in one place instead of scattered everywhere. Then you turn on an integration, and the manager does the opposite. A "sync" takes your secret and writes a copy of it into that other platform's own storage. Turn on five integrations and your one secret is now stored in five more companies' systems, on top of your vault. You did not connect your secret to those platforms. You handed each of them a copy to keep.
That is secret sprawl, and the integrations page is where it happens.
An integration stores your secret on another platform
When a secrets manager "integrates" with your CI, your host, or your cloud, it is almost always doing one thing: copying the secret value out of the vault and writing it into that platform's native secret store.
Connect your CI, and your database password is now stored in your CI provider's secret storage. Connect your host, and it is stored in your hosting platform's environment-variable store. Connect your cloud, and it is stored in the cloud's own secret manager. Connect your cluster, and it is stored in etcd. A background sync keeps those copies updated, but the point stands: the same secret now physically lives in every one of those systems, at rest, in storage you do not own.
You started with a secret in one place. After integrations, you have the same secret stored across half a dozen vendors' systems.
One secret in the manager, copied into every store you connect.
The integration count is the copy count
This is the part the marketing inverts. A long integration catalog gets sold as reach: works with a hundred platforms. But each entry is not a place you can safely use your secret. It is a place the product will store a copy of your secret. The number of integrations you switch on is the number of extra platforms now holding your credential.
So the feature presented as "your secret works everywhere" actually means "your secret is stored everywhere." The breadth that looks like strength is a measure of how far your secret has been spread.
Every place it is stored is a place it can leak
It does not matter how well your vault is secured if the same secret is also sitting in five other stores. Each one is a separate platform that can be breached, with its own access rules that are not yours, and its own copy to hunt down when the secret is compromised. You can no longer answer the simplest question about a credential: where is it stored. The honest answer becomes "in our vault, and in everything we synced it into."
A secret stored in six places is six times the exposure of a secret stored in one. A sync does not move your secret to where it is needed. It leaves a copy behind in every store it touches.
The fix is to never store the copy
There is a model where the secret is stored in exactly one place and nowhere else. Instead of writing the value into every platform ahead of time, the machine reads it from the vault at runtime, the moment it needs it. The application proves who it is, asks for the secret, uses it, and keeps nothing. The CI store, the host's environment variables, the cloud secret manager, the cluster: none of them ever receive a copy.
Under that model your secret has exactly one home. There is nothing to sync, because nothing was copied. "Where is this secret stored" has one answer, and it stays that way no matter how many machines read it.
That is how SikkerKey works: every machine reads from one vault at runtime by signing its request, and the secret is never written into another platform's store.