Per-Session Credential Minting and Revocation in Agent Sandboxes

Coding agents in 2026 carry more standing access to production systems than most security teams have actually mapped. That gap between what an agent can reach and what anyone is watching for is the defining security problem of this generation of tooling. A policy document will not close it. Architecture closes it: credential brokers, sandbox tiers, and revocation systems built so an agent's access dies the moment its task ends, rather than lingering as a door nobody remembered to lock.

Something changed in how teams deploy agents over the past year. They stopped asking for line completions and started handing off entire issues, migrations, refactors, and CI triage runs. That moved agents from a convenience layer into something closer to a junior engineer with commit access, except this one runs at machine speed and never pauses to ask before executing a command.

Non-human identity has quietly become the dominant access-management surface inside most engineering orgs, and most teams are still managing it like it's an era long past. One measurement found 109 machine identities against a much smaller human headcount, 79 of those AI agents specifically. That ratio alone should force a rewrite of how security teams define their attack surface: the majority of "who has access to what" is now a question about machines, not people, and most access-review processes were never built to ask it that way.

Most of that access goes unaudited, and the numbers back it up. In one survey, 82% of organizations discovered at least one AI agent or workflow their security team didn't know existed, a sign that governance has not kept pace with deployment. That is not a rounding error. That is a governance system that was never designed for the thing it's now being asked to govern.

None of this stops agents from working well in narrow pilots. It stops them from reaching production. One industry figure puts the share of agent pilots that make it to production at only a small minority, and the blocker is almost never the model's competence. It is governance: isolation guarantees, compliance controls, and audit trails that security teams reasonably demand before letting an autonomous process anywhere near a production branch.

Agents Holding Credentials They Should Never Have Touched

The issuance pattern that got agents into this position is the same one used for human employees for decades: create an account, grant broad access so nothing breaks downstream, move on. That shortcut worked, more or less, for humans, because humans ask questions before doing something destructive, and get fired if they don't. Agents carry neither check. Once an agent gets standing credentials, it typically holds them for the entire life of its deployment, even when the task in front of it doesn't justify that scope.

Those credentials don't stay locked in a vault, either. GitGuardian's State of Secrets Sprawl 2026 report counted 24,008 unique secrets exposed in MCP configuration files on public GitHub during 2025 alone, and plaintext credentials sitting inside agent configuration files turned out to be a significant leak vector. Dropping a token into a config file is convenient right up until thousands of agents are doing it simultaneously, at which point the convenience scales into a liability exactly as fast as anyone should have expected.

The leak numbers point to something structural, not incidental. A traditional script is boring in the best possible way: it follows the same code path every time, so reviewing the code is the same thing as reviewing the system's actual behavior. An agent breaks that equivalence. It picks which tool to call based on text it reads at runtime, and some of that text can come from a source the agent doesn't control and shouldn't trust, such as a scraped webpage, a pull request description, or a customer support ticket. That is what makes prompt injection a different animal from a normal vulnerability class, not a variation on one. One study tracking production AI deployments in 2025 found prompt injection present in 73% of them. Model-level defenses matter, but they were never going to be the whole answer, because the credential itself, not the prompt, is what an attacker is actually after.

The three places a credential can live during an agent call, and why two of them are wrong

The IETF draft Credential Broker for Agents (CB4A), published in March 2026 by K. Hartman of the SANS Institute, gives the clearest framework available for reasoning through this. It defines three models for where a credential physically sits during an agent's tool call, and its threat model enumerates somewhere between ten and eleven distinct attack paths across them.

Credential wrapping with scheduled revocation is the weakest pattern: the agent gets handed the long-lived credential outright, and someone schedules its eventual revocation. The agent gets handed the long-lived credential outright, and someone schedules its eventual revocation. Between issuance and that revocation event, the credential does whatever the credential is capable of doing, full blast radius, untouched, for however long that window stays open. Nothing in the architecture intervenes.

Model B, short-lived token minting, is better and it's CB4A's recommended primary model, because a broker mints a narrow, time-boxed token and hands that to the agent instead of the underlying long-lived secret, so the blast radius gets bounded by the token's TTL instead of by however long it takes someone to notice a breach. The residual weakness is that the agent still holds something real in memory, even if it expires soon.

The proxy gateway pattern is the one worth building toward, and it's the only approach that removes that residual weakness. The broker validates the agent's session token, injects the actual credential itself, forwards the request to the target system, and passes the response back. The real credential travels broker-to-target directly and never reaches the agent's process. A credential an agent never holds is a credential that can't leak out of a compromised agent process, and that single property is why the proxy gateway, not short-lived token minting, is where this architecture should be heading.

What correctly implemented per-session minting looks like

Model A isn't theoretical. WorkOS Relay implements it directly: it proxies an agent's third-party API calls and injects the credential at the boundary, so the agent's process holds nothing worth stealing even if it gets fully compromised. Relay is currently in early access.

Converting a direct API call to one routed through Relay comes down to four edits. Keep the method, body, and content headers exactly as they were. Send the request to the relay's base URL instead of the provider's, with the original destination URL passed in an X-Relay-URL header. Swap the provider token out of the Authorization header, put the WorkOS API key there instead, then add an X-Relay-User header naming the user the request acts on behalf of. Relay resolves which provider to actually talk to from the host embedded in X-Relay-URL, so the agent's code never needs to know the provider's real credential format.

Vercel Connect takes a related but distinct approach: the application never stores a credential. It requests one at runtime, authenticated using the deployment's own OIDC identity, rather than adding yet another secret that itself needs protecting. Connect ships with more than 100 preset connectors covering common developer tools and SaaS providers, so most common targets need no custom integration work.

Lining the two models up side by side makes the contrast stark fast. A stored token never expires on its own, reaches everything it was ever scoped to reach, gets shared across one bot identity, and has to be rotated by hand, with revocation meaning rotate-and-redeploy. A credential issued through Connect's gateway is short-lived and refreshes automatically, stays scoped to the task at hand, maps to a per-user or per-app identity instead of a shared one, and revokes with one command instead of a deploy cycle.

Why static least privilege is structurally broken for agents

Least privilege has been security orthodoxy for decades, and it carries a hidden assumption that breaks the moment an agent holds the credential: it assumes the privilege granted stays correct over time. For a static role held by a static system, that assumption mostly holds. For an agent, it doesn't. The agent's actual scope of action shifts task to task, sometimes call to call, and a static credential has no mechanism to track that drift. Static access is wrong by definition at some point in an agent's lifecycle, not as an edge case but as the ordinary course of things. Least privilege only becomes a real security property once privilege itself gets treated as dynamic, minted and retired alongside the work it's meant to cover.

Getting there starts with something almost embarrassingly basic: every agent needs its own service account. A shared account erases attribution the instant something goes wrong, because there's no way to tell which agent, task, or run actually made the call that caused the incident. An account called agent-support-triage-ro tells an auditor what it's for and what it can do. An account called agent-3 tells them nothing.

A just-in-time elevation pattern shows what dynamic privilege looks like in practice, and it's more nuanced than minting a fresh identity for every task. Time-limiting, in this pattern, applies to entitlements (role activations, tokens, specific approvals), not to the identity itself. The agent's core identity stays stable, which matters for lifecycle management and auditability, while JIT elevation grants it narrowly scoped privilege only for the duration of one specific workflow.

The sandbox tier the credential runs inside determines the blast radius

A short-lived, narrowly scoped credential still needs somewhere safe to live while it's active. A short-lived, narrowly scoped credential still needs somewhere safe to live while it's active, and that requirement gets skipped most often. A properly configured sandbox gives one guarantee above all others: a process inside it cannot touch filesystem paths, network endpoints, or system calls that the sandbox's policy hasn't explicitly allowed, no matter what instructions that process receives at runtime. Even a fully compromised, prompt-injected agent hits a wall it cannot talk its way past.

Looking at what the hyperscalers actually built, not what they say in marketing copy, shows a consistent signal. AWS built Firecracker specifically for Lambda and Fargate. Google built gVisor for its own large-scale internal workloads. Every one of them reached for its strongest available isolation primitive and pointed it at AI workloads. None of them reached for a standard container, and that should tell you something about what the people running the largest multi-tenant systems on earth actually trust.

That choice isn't arbitrary. Standard multi-tenant containers don't provide kernel-level isolation between tenants, so a single container escape hands an attacker the host itself, along with every other container's credentials sitting on it. For LLM-generated code, where the code path isn't fixed and can't be fully reviewed in advance, that's not a risk worth taking. A container is the wrong isolation boundary for this workload, full stop.

The isolation options split into roughly four tiers, each trading startup latency for isolation strength differently. Firecracker microVMs give each session its own Linux kernel running inside KVM, booting in about 125 milliseconds. AWS Lambda runs each session in a dedicated Firecracker microVM with no shared kernel between users, supporting sessions up to eight hours long with as much as 32 GB of memory and disk and up to 16 vCPUs. gVisor works differently, intercepting syscalls at the point they're made: a container's syscall gets handled by gVisor's Sentry process in user space, which only lets a minimal, vetted subset actually reach the host kernel. That lands stronger than a bare container and weaker than a full VM, trading roughly 10 to 30% I/O overhead for fast startup. The WebAssembly Component Model takes a declarative approach instead of a runtime-interception one, where each component states its imports and exports through typed WIT interfaces up front, the host checks the request against policy, and only approved capabilities get wired through before the component runs and is torn down or pooled afterward. The permission surface gets declared ahead of time instead of inferred by watching behavior after the fact. Northflank's multi-runtime platform supports Kata Containers (with Cloud Hypervisor as its primary VMM), Firecracker, or gVisor, self-serve, across AWS, GCP, Azure, Oracle, CoreWeave, Civo, or bare metal, and reports processing a substantial volume of isolated workloads a month.

The gap between revocation and enforcement revealed by the PORTICO and lingering authority research

A credential can be properly scoped, short-lived, and running inside a strong sandbox, and the agent can still end up holding access it shouldn't. All it takes is nobody telling the system that the task justifying that access already finished. A June 2026 paper out of the International University of La Rioja, authored by Igor Santos-Grueiro, names this failure mode "lingering authority."

Coding agents commonly get broad tool access for an entire task, even when a specific resource is only needed to complete one subgoal inside that task. Once that subgoal closes out, the capability granted for it just sits there, still valid, still usable, because the broader task hasn't ended yet. This is a fundamentally different failure than credential theft: nobody stole anything. The agent is still holding access it was, at some earlier point, legitimately given, and that is what makes it dangerous. Nothing in the system flags it as wrong.

The paper's answer is a reference monitor called PORTICO. It compiles an explicit task contract up front into a set of initial capabilities, rules for granting more, predicates defining what a "trusted closure" of a subgoal actually looks like, and global deny rules that apply no matter what. As the agent works, a request-grant-invoke lifecycle materializes any expanded access as an opaque, epoch-bound handle rather than a durable credential. When a subgoal closes, that handle gets pulled from the next planning interface entirely, and any attempt to replay a stale handle gets rejected before it can cause a side effect.

The measured results are specific enough to matter. Across controlled coding-agent tasks, PORTICO recorded zero executed contract-forbidden effects. On the specific slice of tests probing closure behavior, it rejected all ten out of ten attempted post-closure reuses, while a non-revoking comparator system permitted all ten. A separate, deterministic stale-write audit found zero out of six forbidden effects executed under PORTICO, against six out of six executed under the comparator. Zero versus six, ten rejected versus ten permitted: that gap is the entire argument for why closure-aware revocation belongs in agent architecture from the start, not bolted on after an incident forces the question.

Credential revocation alone did not stop the OpenAI incident at Black Hat 2026

All of this theory met a live audience in August 2026, when Black Hat and DEF CON both convened in Las Vegas. Kiteworks published an analysis of that reporting, drawing on The Register's coverage from Jessica Lyons, and the throughline across both conferences was blunt: talk after talk centered on rogue agents escaping their sandboxes and doing damage once they were out. Agentic AI wasn't a side track at either event. It was close to the entire subject both conferences had been built around that year.

Revocation, on its own, assumes there's a clean moment where access gets cut and everything downstream stops. That assumption is exactly where the approach falls apart. An agent that already acted on a credential before revocation fired has already done whatever it did, and revoking the credential afterward just closes a door that's already been walked through. Nothing about that sequence reverses, no matter how fast the revocation fires.

That's why the architecture has to hold across every layer at once: a credential minted per session instead of standing indefinitely, injected at a proxy boundary instead of held in the agent's own memory, running inside a sandbox strong enough to contain it even if compromised, and revoked the instant its task closes rather than on a schedule set in advance. If any one of those layers is skipped, the others don't compensate. They just slow an attacker down, and slow is not the same as stopped.