How it works
- The operator authenticates to the gateway with their own named identity and MFA. This is the only credential they know.
- The gateway checks authorisation — is this person permitted this target, as this account, right now, and does it require approval?
- The gateway retrieves the target credential from its encrypted vault. This happens server-side; nothing is sent to the operator’s browser or client.
- The gateway authenticates to the target and presents the established session to the operator.
- The session is recorded and expires on whatever clock the authorisation set.
The operator gets a working shell or desktop and never possesses the credential that opened it.
What it actually prevents
| Risk | Why injection removes it |
|---|---|
| Credential reuse | Nothing to reuse — the operator has no copy |
| Passwords in notes, wikis, scripts | Nothing to write down |
| Departure risk | A leaver takes no production credentials with them |
| Phishing of target credentials | The operator cannot disclose what they do not know |
| Shoulder surfing and keyloggers | The credential is never typed on the endpoint |
| Shared account attribution | The shared account can persist while the human is still named — see shared accounts |
Write-only by design
The property that makes a vault trustworthy is that no path returns a secret — not to an operator, not to an administrator, not through an export. Secrets go in and are used; they do not come back out.
This has a consequence worth stating plainly: a write-only vault cannot check password strength, because it cannot read the password. Its hygiene reporting is built on metadata it can prove — when a secret was last rotated, whether a privileged account has no secret stored at all, how many people can reach it, whether anyone has used it in months. Those checks catch real problems, and they do it without ever reading a value back.
What it does not solve
- What the operator does in the session. They have a legitimate privileged session; injection governs how it opened, not what happens inside. Recording and command policy cover that.
- Credentials embedded elsewhere. Passwords hardcoded in application config and scripts are untouched by this and are usually the larger population.
- A compromised gateway. The gateway can authenticate to everything, which is exactly why it needs the hardening, monitoring, and separation of duties the rest of this series describes.
- Standing privilege. An operator who can inject into a target at any hour still holds standing access. Pair injection with expiry and approval.
The operational objection
Administrators sometimes resist on the grounds that they need the password for the case where the gateway is unavailable. That is a legitimate operational requirement, and the answer is a designed break-glass path — sealed, alarmed, reviewed, and rotated after use — rather than every administrator retaining a permanent copy against a bad day.