A push-to-phone approval gate on secret retrieval.
Multi-factor authentication is applied at the boundary of a session. You prove who you
are, you get a shell, and from that moment every process running under your account
inherits the result. The token in your keychain, the key in ~/.ssh, the
variable your build script exports: all of it is readable by anything with your uid,
without any further challenge, for as long as you remain logged in.
That was a reasonable design when the things running as you were things you had personally started. It fits poorly on a machine that also runs package installers, language servers, browser extensions, and increasingly, autonomous agents acting on instructions that arrived from somewhere else.
Authentication establishes who is at the keyboard. It says nothing about what is reading your keychain twenty minutes later.
A coding agent with access to a developer environment was induced to retrieve stored credentials and transmit them to an external endpoint. The credentials were properly stored. The machine was not compromised in any conventional sense. No malware was installed, no privilege was escalated, and no control failed in the way controls are normally understood to fail.
The agent had the same access the developer had, and it was asked nicely.
Every existing control behaved correctly. Disk encryption was on. The keychain was locked at rest and unlocked by an authenticated session. The credential was never written to a file in plaintext. It left the building anyway, because none of those controls are designed to ask a question at the moment a secret is handed to a caller.
Put a human decision at the point of retrieval, on a device that is not the machine making the request.
The secret itself never crosses the network. Only the prompt does. The vault's authority lives in process memory and never touches disk, so the machine at rest holds nothing worth stealing.
Not that credentials cannot be stolen. That a theft cannot be silent. Every retrieval produces a decision on a device an attacker on the workstation does not control, and an audit record of who asked, for what, and when.
An approval gate governs who may obtain a secret. It has nothing to say about what happens to that secret afterwards. Approve a request from a process that has been compromised and the gate has worked exactly as designed while you have still lost the credential.
This is not a hypothetical concession. It was observed on a system during recent testing and development: an agent requested a token, the prompt appeared, a human approved it intending to approve it, and the token was then written into a transcript that went to a third party. The gate did its job. The secret leaked anyway.
That failure is the argument for the second half of the design.
Because the gate cannot follow a secret past the door, the remaining lever is to make what goes through the door expire quickly and reach very little.
Rather than releasing a stored, long-lived access token, the broker mints a credential on demand: it signs an assertion with a key that never leaves the vault, exchanges it with the provider, and returns a token valid for one hour, scoped to a named set of repositories. Nothing durable is stored on the workstation, so there is no standing credential to rotate, to leak, or to find in a backup.
gating reduces the CHANCE of exposure (a person must approve)
minting reduces the IMPACT of exposure (1 hour, narrowly scoped)
revocation reduces the WINDOW of exposure (planned: the length of the action)Neither control is sufficient alone. Gating without expiry means one approved theft lasts until somebody notices. Expiry without gating means anything on the machine can help itself, quietly, as often as it likes.
An hour is better than forever, but it is still an hour longer than necessary. A credential released to run one command has no business outliving that command.
The next release revokes the credential the moment the action it was released for completes, so a token that lives for a two-second API call is valid for two seconds rather than sixty minutes. Expiry stops being the working lifetime and becomes what it should always have been: a backstop for when revocation fails.
Some release modes cannot see when the caller has finished, because the credential was handed to a shell rather than to a child process the system controls. Those keep the expiry as their bound, and that limitation is stated rather than papered over.
Minting and revocation are only available where the provider supports them. They require an API that will issue a short-lived credential on demand and invalidate one before its expiry. Where a platform provides that, the approach above applies directly and the working lifetime of a credential can be measured in seconds.
Many platforms do not. They offer long-lived API keys, and nothing else. For those, the recommendation is the closest available approximation: fine-grained tokens with the narrowest scope the task allows and the shortest expiry the platform permits. A token restricted to three repositories and expiring in thirty days is not equivalent to one that lives for an hour, but it is a different proposition from an account-wide key with no expiry at all.
The gate still applies regardless. Whether the credential behind it expires in sixty seconds or ninety days, requiring a person on a second device to release it is independent of what the provider is willing to issue.
A workstation is not a trustworthy place to keep a durable credential, and it has not been for some time. The practical response is not to trust it harder. It is to hold nothing durable there, to require a person for anything consequential, and to accept that the person will sometimes approve the wrong thing, which is why the thing they approve should expire before it matters.