A human decision at the moment a secret is released. On your phone, not on the machine asking.
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.
The gap above shows up as seven specific pains. Anyone running agents against real credentials has met most of them.
Put a human decision at the point of release, on a device that is not the machine making the request, and make what is released worth as little as possible to steal. In terms of what the system can do:
Not that credentials cannot be stolen. That a theft cannot be silent, cannot be broad, and cannot last. Every release is a decision on a device an attacker on the workstation does not control, for a credential that expires before it matters, with a record of who asked and what they got.
A gate like this is usually described as a restriction placed on an otherwise free agent. Read from the other direction, it is the mechanism that makes an agent useful inside a restriction that already existed. The same policy that would otherwise reduce an agent to giving advice becomes one it can work inside: the agent operates continuously, and each release of a credential is a decision a person makes on a second device rather than a command a person retypes.
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. On 2026-07-24, during development, an agent requested a token, the prompt appeared, a person 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. The audit record made the diagnosis immediate and the token was revoked in twelve minutes, and the threat model was corrected: it had assumed a caller whose output goes to a terminal, and that assumption predates agents.
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. Three controls, on three different axes:
gating reduces the CHANCE of exposure (a person must approve)
minting reduces the IMPACT of exposure (short-lived, narrowly scoped)
revocation reduces the WINDOW of exposure (planned: the length of the action)
Neither of the first two 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.
A short lifetime is better than forever, but it is still longer than necessary. A credential released to run one command has no business outliving that command. The next capability ends the credential the moment the action it was released for completes, so expiry stops being the working lifetime and becomes what it should always have been: a backstop for when revocation fails. Where the system cannot see the action finish, the expiry remains the bound, and that limitation is stated rather than papered over.
Minting and revocation are only available where the provider supports issuing a short-lived credential on demand and invalidating one before its expiry. Many platforms offer long-lived API keys and nothing else. For those, the recommendation is the closest available approximation: 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 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, to know that the person will sometimes approve the wrong thing, which is why the thing they approve should expire before it matters, and to have rehearsed what you do when the machine comes back empty.