The Ninety-Second Token - Minting Credentials That Die With the Action

The problem

I built an agent to handle the kind of SharePoint housekeeping nobody wants to do by hand: move finished marketing assets into an archive folder, rename files to match a naming convention, share a link with an outside agency contact once a campaign wraps. Routine work, low judgment required, the kind of task that gets automated first because it looks safe.

The way I set up the credential was the way almost everyone sets up a credential for a background agent. It authenticates once when the process starts, with a single token scoped to full read and write across every library on the site, and it keeps using that same token for every action for as long as the process runs. I didn't think of it as a decision at the time. It was just how you write the auth code before lunch.

Then I tested it properly. I gave the agent fifteen ordinary housekeeping tasks against a seeded set of forty files across five libraries, plus three attempts to replay a token after the fact, the way a leaked log line or a captured request would let an attacker do. The token I'd issued was valid across all five libraries and every one of the forty files, regardless of which single file the agent was actually touching at that moment. All three replay attempts succeeded. Nothing in the architecture checked whether a token was being used for the action it was minted for, or whether it should have expired an hour ago.

The token worked exactly as designed. It proved the bearer was allowed to act on the site, and that's all a bearer token is built to prove. What never got asked was a second question sitting right next to the first one: how much of the site should one token be allowed to reach, and for how long. A stolen copy of that credential could touch every file in every library for as long as the process stayed alive, which in practice meant indefinitely. The blast radius of one leaked token was, by construction, everything the agent could see.

The pattern

The fix is a broker that sits between the agent deciding what to do and the agent doing it, minting a fresh, narrow credential for every single action instead of handing out one standing grant at startup.

I split the agent into three steps. A planning step decides on one operation and one target and nothing else: move this file, rename that one, share this specific link. A credential broker takes that single decision and mints a token scoped to exactly that file, that operation, and a short time-to-live, ninety seconds in my test. An execution step uses the token once. The broker invalidates it the moment it's used, or the moment the ninety seconds runs out, whichever comes first, and refuses to let the same token cover a second action under any circumstances.

Run the same fifteen tasks and three replay attempts through that version and the numbers move all the way to the other end. Every action mints its own token, so the blast radius of any single credential is exactly one file and one operation. Compare that to the standing-token run: five libraries, forty files, one credential covering all of it. All three replay attempts fail here, because by the time anyone tries to reuse a captured token, it has either already been consumed by the action it was minted for or has already expired.

I can't take credit for inventing this move. Auth0 built the same shape into Token Vault. OAuth 2.0 Token Exchange, standardized as RFC 8693, describes the identical pattern: exchange a broad credential for a narrow, short-lived one scoped to the specific call you're about to make, instead of carrying the broad one all the way to the resource. Okta's Agent SSO registers agents the same way, issuing governed tokens minted per action rather than one refresh token that lives for the life of an integration. Three identity vendors converging on the same mechanism in the same year tells me the standing-broad-credential habit was never really a considered choice. It was the path of least resistance before anyone built the broker to replace it.

Design considerations

The obvious cost is latency and operational surface area. Minting a token per action means a broker call on every single operation instead of once at startup. For fifteen housekeeping tasks that overhead is invisible. For an agent taking thousands of fine-grained actions a minute, the broker becomes real infrastructure you now have to keep available, fast, and correctly configured, and a broker that's down is an agent that can't act at all. You're trading a security exposure for an availability dependency, and it helps to go in knowing that's the actual trade rather than discovering it during an outage.

Scoping correctly is harder than it looks from outside the code. My broker mints a token against the file, the operation, and the TTL, which works cleanly because the planning step already knows exactly which file and which verb it needs before it asks for a credential. Plenty of real workflows don't decide things at that granularity. An agent that has to enumerate a folder before it knows which file to touch next runs into a sequencing problem: it needs some access to figure out what access it actually needs. In practice that means minting a slightly broader token for the discovery phase and a narrow one for the action phase, and every workflow draws that line in a different place depending on how its planning step is built.

The credential is only one layer of the perimeter, and scoping it tightly doesn't close every gap next to it. A properly scoped, short-lived token says nothing about the runtime it executes inside. If that process shares memory, a cache, or a subprocess pool with other tasks or other tenants, a corrupted step can still leak context sideways through the shared runtime itself, in a way no amount of credential scoping ever touches. I've only found one source describing that specific failure mode so far, which isn't enough evidence for me to treat it as an established pattern in its own right, but it's enough to keep me from claiming the credential broker has contained the whole system on its own.

A related gap sits on the other side of the token. Scoping a credential to one action says nothing about what that action's own process can reach independent of the credential: the local filesystem, a local network socket, whatever the process itself is permitted to touch on the machine it runs on. A sandboxed process holding no credential at all can still cause damage through channels the token was never built to gate. The token controls what a remote call authorized by that token can do. The process running the token is a separate fence, built and maintained separately, and a tight broker is not a substitute for having built that second fence too.