LEGITMFA.IO

A human decision at the moment a secret is released. On your phone, not on the machine asking.


The Problem

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.

This stopped being theoretical in July 2026

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.

Where It Hurts

The gap above shows up as seven specific pains. Anyone running agents against real credentials has met most of them.

  1. Everything you run is you. A script, a postinstall hook and an agent all present the same identity to the keychain as your own shell does. There is no point at which the system can tell them apart, so there is no point at which it can say no.
  2. The instructions are poisoned before you see them. An agent takes direction from whatever it reads: a dependency's README, an issue comment, a web page, the output of a tool it was told to trust. To the agent, content and command are the same text. Anyone who can put words in front of it can steer it, and the person at the keyboard never sees the instruction that was followed. You cannot authenticate a sentence.
  3. Theft is silent, and it leaves through the front door. A credential read is not an event anyone sees, and its departure does not look like exfiltration. A secret that lands in an agent's working context is sent to a frontier model provider as part of the next ordinary API call. A secret that lands in a log, a transcript or a telemetry event is forwarded to wherever those are collected. Both are sanctioned traffic to approved destinations, encrypted and expected, so nothing on the network objects. The first signal is usually the damage.
  4. Approvals rot into reflexes. Prompts that arrive one at a time, out of context, train a person to tap without reading. A gate that looks strong per action erodes in practice.
  5. One mistake lasts forever. A single approval given in error can hand over a long-lived, broadly scoped credential. Nothing ends it until someone notices and rotates it.
  6. The safe posture is the unusable one. An environment strict enough to deny an agent any credential reduces it to an advisor while a person does the actual work by hand.
  7. Recovery is an unaided memory test. Controls that hold secrets in memory come back empty after a reboot, by design. If bringing them back requires recalling a sequence a few times a year, the control fails on the day it is needed, and stays failed for days while the alerting works perfectly.

What legitMFA Does

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:

  1. Nothing is released without a person deciding, on a second device. Something asks for a credential. Your phone shows what is asking and for what. Denial and timeout are the same outcome: the request fails. There is no ungated path. An agent acting on poisoned instructions can still ask. It cannot approve.
  2. The decision is over a reviewed list, not a stream of prompts. Related actions are approved together as one list. The list is bound to the decision, so what was reviewed is what runs, and nothing can be added after the fact. One action is simply a list of one.
  3. The caller is identified by what it is, not by what it says. The request carries the identity of the process that made it, established by the operating system rather than claimed by the requester, so the prompt names the real asker.
  4. Credentials are manufactured, not dispensed. Where a provider allows it, the system issues a short-lived credential scoped to the task instead of handing out a stored one. Nothing durable lives on the workstation, so there is no standing credential to rotate, to leak, or to find in a backup.
  5. The machine at rest holds nothing worth stealing. The authority to release secrets exists only while the system is running, on no disk. The secret itself never crosses the network. Only the request for permission does.
  6. Every release leaves a record you can act on. Who asked, for what, what the credential could do, on which resources, for how long. The credential value itself is never recorded, so the record can be forwarded and collected without becoming a leak of its own.
  7. Recovery is a rehearsed, single step. Bringing the system back from cold is one command that asks only for what a person alone holds. Off-box recovery material is exercised on a schedule, because a credential nobody has used is a credential nobody has verified.
  8. The control it depends on can be demonstrated, not just assumed. A gate is only meaningful where the direct paths to a secret are closed. The system can show that they are, and measure what happens when they are not, rather than taking it on faith.
  9. One provider built in, others attach. GitHub is supported out of the box. Other providers connect through a published contract whose conformance can be checked, so an integration cannot quietly reopen a path the gate closed.
What this actually buys you

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.

Which is also the point

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.

The Honest Limitation

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.

Shorten What A Stolen Credential Is Worth

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.

Revocation, the next step

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.

This depends on what the platform offers

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.

Where This Leaves You

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.