Every breach post-mortem you have read ends the same way: a credential was somewhere it should not have been, and it worked for the attacker exactly as well as it worked for you. It usually started in a vault. It did not stay there, because the application had to read it in order to use it.
What it changes for the business
- A compromised application yields nothing. There is no working value inside it to take, so the incident is a service outage rather than a disclosure with a deadline.
- Rotation stops being a fire drill. Nothing has to be redeployed when a credential changes, because nothing was holding one.
- Third-party access stops being permanent. Access is granted for an action rather than issued to a system and forgotten about for two years.
- You can let an agent act for a person without handing the agent that person's access, which is usually the thing that stops the project.
How it works, briefly
Your applications, and the agents acting through them, carry a stand-in value rather than a working one. The real value is substituted at the moment the call is dispatched, and what comes back to your application is the result.
Which path a call takes follows from one question: whose secret is it? A person's own credential can stay on their phone, and the phone can make the call itself. A company credential cannot go the same way, because putting it on a personal device hands company data to the person holding that device, who is free to inspect everything that device sends. So any call touching your vault is completed by the gateway, including one that also needs a value from the owner, who supplies only their own half. Approval is a separate question again: a person can be asked to agree to a call that the gateway then makes.
| How this is handled elsewhere | How Squidder does it |
|---|---|
| A secret in the environment | Nothing to put in the environment |
| A vault your application reads at call time | Your vault, read by the gateway, never by your application |
| The gateway keeps the key on your behalf | Held for the one call, then discarded |
| One placement, fixed by the tool | Vault or the owner's phone, chosen by policy |
| Access issued once, valid until revoked | Access exists for the action, then it is gone |
| A leaked log is an incident | A leaked log has no working value in it |
Where it fits, and where it does not
This covers values that leave through the gateway. A secret your own code keeps for its own purposes is untouched, and so is anything your applications never send anywhere. An overnight batch with nobody behind it is served by the vault path, without inventing somebody to ask.
Where to start
Take one integration where a third party holds a credential of yours and nobody is comfortable about it. Move that one, and pick the placement that suits it. Then check your own logs and storage for the value: it is not there to find.