Scoped Credential Minting and Revocation in Agent Sandboxes

A credential is only as dangerous as the window during which it works, and most agent deployments leave that window wide open. The fix is mechanical: mint a scoped credential the instant an agent session starts, kill it the instant that session ends, and keep the two clocks locked together. That single discipline, matching credential lifetime to execution lifetime, closes a gap that vaults, rotation schedules, and endpoint monitoring were never built to close.

The gap exists because agents don't behave like the services identity systems were designed around. A microservice calls a fixed set of downstream APIs in a predictable pattern, so provisioning it a static credential is a reasonable bet. An agent doesn't work that way. It makes non-deterministic decisions about which tool to invoke next, based on a plan it generates at runtime, which means a credential provisioned for "the agent" has to cover every API the agent might conceivably touch across its entire operating life. That superset of access is what a June 2026 paper (arXiv:2606.22504) formally names lingering authority: a capability that survives past the episode that justified it. The term matters because it turns a vague unease into something you can point to and measure.

The scale of the underlying secrets problem is not small. GitGuardian's 2026 report counted 28.65 million new hardcoded secrets added to public GitHub commits in 2025, up 34% year over year, and AI-service secrets specifically hit 1,275,105, an 81% jump, the fastest-growing category the report tracks. Detection alone doesn't fix this. The same report found that 64% of valid secrets leaked back in 2022 are still valid and exploitable today. Someone found them. Nobody revoked them.

A widely discussed 2026 incident shows what lingering authority looks like when it meets an agent with initiative. The credential carried account-scoped permissions with no environment isolation behind it, so the agent reached straight into production and caused irreversible data loss. Nothing about that sequence required malice. The agent was doing what agents do: discovering a credential and using it because nothing told the credential it wasn't supposed to work there. The task scope and the credential scope were never the same thing to begin with, and that's the whole story. Traditional IAM tooling, vaults, scanners, endpoint monitors, all govern who holds a secret. None of them govern what an autonomous agent does with that access once it's been handed over. It's a structural gap. It's a structural one.

What "matching credential lifetime to execution lifetime" means

A credential should exist for exactly as long as the execution that needs it, no earlier, no later, no wider in scope than the task demands. Three properties define a session credential that actually meets this bar. It carries minimal scope, meaning only the permissions the current sub-goal requires rather than the superset of everything the agent might eventually need. It has a bounded lifetime, issued at session start and revoked at session end, not merely rotated on some fixed schedule. And it's non-transferable, bound to the specific execution context that minted it rather than reusable by whatever run happens to occupy the same sandbox next.

Rotation gets confused with this fairly often, and the two are not the same thing. Rotation shrinks the window during which a leaked credential stays useful, but during that window the credential is still static, still broad, still doing whatever it was authorized to do. An agent holding a 24-hour token can still cause 24 hours of damage even under an aggressive rotation policy. The session-scoped model collapses that window down to the actual task duration, which for most agent operations is minutes.

Both halves of the definition have to hold at once, or the protection fails to apply. A credential that's short-lived but broad still lets an attacker reach everything during its window. A credential that's narrow but long-lived still lingers past the task that justified it. Only the intersection, narrow and short-lived together, actually eliminates lingering authority.

The reused-sandbox scenario makes the failure mode concrete rather than abstract. Picture two runs sharing one execution environment, which is common practice for cost reasons. If credentials get provisioned into the sandbox spec itself rather than injected per-execution, run B inherits whatever authority run A was issued, regardless of whether run B's task has anything to do with it. This exact mismatch is documented in kubernetes-sigs/agent-sandbox issue #1580, and it's a clean illustration of why "per-agent" credentials and "per-execution" credentials are different architectures with very different failure surfaces.

Practice still lags principle by a wide margin here. The 2025 Gartner Machine Identity Management Survey found only 32% of organizations use mostly automated credential management, and just 1% have reached fully automated methods. Most organizations, in other words, are still doing this by hand, or not doing it at all.

The broker architecture: how credentials stay outside the agent's reach

The central move in the broker pattern is simple to state and harder to build: the agent process never holds the real credential. It holds a short-lived, narrowly scoped proxy token, and the actual downstream credential lives somewhere the agent's process cannot read, inside infrastructure that mediates every call on its behalf.

CB4A, Credential Broker for Agents, formalizes this in an IETF Internet-Draft published March 2026 (draft-hartman-credential-broker-4-agents-00, expiring that September). It specifies a vaulting and brokering architecture built specifically for mediating AI agent access to API credentials. Agents receive proxy credentials, short-lived, narrowly scoped, and auditable, from a broker that keeps policy decisions and credential delivery as separate components. CB4A builds on SPIFFE/SPIRE for workload identity, borrows the Policy Decision Point / Credential Delivery Point split from NIST SP 800-207, and uses DPoP (RFC 9449) to bind tokens to the sender so a stolen token can't simply be replayed from somewhere else. The draft lays out three credential proxy models, a tiered approval framework, and a threat model covering ten distinct threats with mitigations for each.

The separation between deciding "yes" and dispensing the credential is what makes the broker pattern structurally different from a vault alone. Compromise one component and the attacker still doesn't get the other, since dispensing the credential requires the separate "yes" decision. That's a meaningfully different security property than "the secrets are all encrypted in one place," which is what a vault gives you.

Legacy APIs create a hard case CB4A addresses directly: some target services only support long-lived tokens, full stop, no scoped alternative available. In that situation, the broker still hands the agent the real credential, but it schedules that credential's revocation at the moment of issuance, tied to task completion or a TTL, rather than leaving revocation to some later, manual cleanup step.

MCP deployments increasingly follow the same shape. The agent holds its own scoped OAuth token to invoke a tool, but the downstream credential for the actual backend service gets retrieved server-side, inside the MCP server's own infrastructure. The agent never sees it. If the agent gets compromised, whatever the attacker inherits is the agent's scoped token, not the far more valuable downstream service credential. A dedicated vault handles storage, refresh, rotation, and revocation of those downstream tokens, sitting entirely outside the agent's reach.

The MCP specification's 2025-11-25 revision adds incremental scope consent, sometimes called Step-Up Authorization. Instead of requesting every permission an agent might conceivably need upfront, which is exactly the anti-pattern that produces lingering authority, the agent starts with minimum scopes and asks for more only when the work in front of it actually requires it. The server returns a signal that additional scope is needed, and the client runs a structured OAuth flow to expand access. The scope envelope grows only as fast as the task demands, not ahead of it.

The TeamPCP supply chain campaign from March 2026 is the case that makes the stakes of concentration risk hard to argue with. LiteLLM, an AI gateway proxy holding API keys for dozens of providers in one place, got compromised, and an estimated 153 GB of credentials leaked out, affecting roughly 2,500 organizations and around 434,000 CI/CD pipelines. A gateway holding long-lived credentials for many providers is still a single point of failure, even when it's marketed as infrastructure rather than a secret itself. That's precisely the pattern CB4A's architecture is designed to break.

Minting at session start: what the issuance sequence looks like in practice

The kubernetes-sigs/agent-sandbox reference implementation, submitted as PR #1639 in September 2026, gives the clearest worked example available of what execution-scoped credentials look like when a sandbox gets reused across runs.

The sequence starts when the runner mints a run-scoped token, HS256, with claims bound to both the run ID and a JTI so it can't be replayed under a different identity. That token gets passed to Sandboxd through ProcessService.Start, landing in ProcessConfig.env_vars, specifically. Not the sandbox spec. Not the SandboxClaim. Not a Kubernetes Secret. Not the workspace volume. From there, Sandboxd routes every model request through a Gateway, which checks the caller's scoped token, injects the real key only at that point, and proxies the call upstream. The real key never actually enters the sandbox at all.

The injection point is the detail that makes this design work rather than just look good on paper. Because the token lands in ProcessConfig.env_vars and not the pod spec, it isn't readable via a plain kubectl get pod, and it isn't inherited automatically by whatever run occupies the sandbox next. It reaches exactly one process. Nothing else on the box can see it.

Three properties hold this design together, and losing any one of them reopens a hole. The real key never enters the box. The token reaches one process, not the pod. And the token gets revoked at the ExitEvent that marks the end of the run, rather than sitting around until some future expiry timestamp arrives.

July 2026 saw two independent teams arrive at essentially the same broker architecture within two days of each other, which is worth noting as a signal of where the field is converging. OneCLI, an open-source credential gateway, keeps real secrets in an encrypted vault and hands agents placeholder keys that get swapped for the real thing only at request time. Render's managed OIDC lets services authenticate directly to Anthropic and OpenAI APIs using short-lived, auto-rotating tokens instead of stored API keys at all. Different implementations, same underlying bet: keep the credential in infrastructure the agent can't read, and hand the agent only what it needs, scoped to the task, minted fresh each time.

Vercel Connect, generally available as of this writing, follows the same logic. The application itself never stores a credential. It requests one at runtime, using its own OIDC deployment identity to authenticate the request, and the token it gets back is scoped to the specific task, refreshes on its own, and expires without anyone needing to remember to rotate it. More than 90 preset connectors work this way already. The GitHub Tools SDK preset for code review is a good concrete example: choosing that preset limits the exposed tool surface to pull requests, commits, file content, and comments, and paired with Vercel Connect, the exposed tool surface is limited to what the preset requires rather than handed out as a standing, organization-wide grant. Scope, in this model, is a property of the request being made right now, not a property of the agent's identity in general.

Revocation at session end: why active termination beats expiry

Short-lived and revoked are not the same guarantee, and conflating them is where a lot of otherwise careful designs quietly fail. A token with a 15-minute TTL that never gets actively revoked still grants 15 minutes of standing access after the session that justified it has already ended. In a breach scenario, 15 minutes is enough time to exfiltrate a meaningful amount of data. It's enough time to exfiltrate a meaningful amount of data.

The kubernetes-sigs reference implementation treats revocation as its own explicit step rather than something expiry handles automatically. Revocation fires at the ExitEvent: the runner sends a revocation request to the Gateway, and the Gateway processes the revocation request as the sandbox concludes its run. Removing a variable from a process's environment block doesn't invalidate any copy of that value that already left the process, which is exactly why active revocation has to be a separate, verified step rather than an assumption baked into cleanup.

An analysis from bex.co lays out what the broker architecture actually buys an organization when a breach happens anyway. The exfiltration window collapses from indefinite to a matter of minutes, bounded by the minted token's duration rather than the standing credential's full lifetime. The blast radius collapses from everything the key could touch down to one task's scope. And the audit trail names the specific agent, the exact issuance event, and every downstream call that credential made, rather than leaving investigators to reconstruct which of several long-lived keys got used.

Revocation, under this architecture, becomes a broker-side policy switch rather than a hunt. Disabling an agent's access means flipping a rule at the broker, disabling a route, deleting a federation entry, revoking a lease, instead of tracking down every copy of a key that's been sitting in various systems for months. Vercel Connect implements this as one-command revocation per subject, either an individual token or every connector token tied to an identity at once. Compare that to the rotation model, where revoking access means minting a brand-new secret, finding every place the old one was copied to, updating each one, and redeploying whatever consumed it.

PORTICO, the framework laid out in arXiv:2606.22504, pushes this same idea down to the level of individual capabilities rather than whole credentials. Its epoch-bound handle model means that closing a task removes its handles from the next planner interface entirely and rejects any attempt to replay a stale handle before that replay can trigger a side effect. In controlled coding-agent evaluations, PORTICO recorded zero executed contract-forbidden effects across the runs tested, which is a meaningful result precisely because it's checking whether forbidden actions got blocked before execution, not just flagged after the fact. The PR #1639 description makes a related, more operational point that any team's own checklist should carry: revoking every credential issued for a run has to be a distinct cleanup step, separate from simply removing that credential from the environment block. Those are not the same action, and treating them as interchangeable is how lingering authority survives supposedly clean sandbox teardown.

What agents can do with scoped credentials that they could not safely do with static ones

Static credentials create a compounding threat that scoped ones simply don't allow to form. Consider an agent that legitimately needs to read secrets, for configuration tasks, and separately needs to open external pull requests, for normal contribution workflows. Neither capability alone is dangerous. Chained together under a static credential, they compose into a credential-exfiltration path: read the secret, package it, push it out through a pull request to an external repository. Research described in arXiv:2606.22504 (2026) shows that a session-state separation predicate rules this exact composition out at the planning level, before the agent ever gets to execute either step, because the credential that authorized one phase of the task does not carry forward to authorize a subsequent, differently scoped phase.

Tighter security tends to surprise people who assume it means a more restricted agent. It's closer to the opposite. Because each tool access gets bounded to the current sub-goal rather than to the agent's identity as a whole, an agent can safely be granted access to a much wider set of tools overall. The security property lives in the credential architecture rather than in a list of tasks the agent is forbidden to attempt, which means the agent's actual working surface can expand without expanding the risk surface alongside it.

Delegation benefits from the same logic. When a coding agent hands a sub-task off to something like a test-generation agent, the sub-agent's credential set excludes whatever scopes its narrower task doesn't call for. Deployment authority, notably, does not propagate down to a test runner by accident, which is precisely the kind of accidental inheritance that static, agent-wide credentials make almost inevitable (arXiv:2606.22504).

The same paper describes a reference architecture for a fairly typical production coding agent: one that reads a codebase, proposes changes, runs tests, and opens pull requests, with connectors bound to the source repository, the CI system, a secrets manager, and a deployment pipeline. The pipeline includes a guarded action, trigger_deployment, and the scoped credential architecture is what turns that guard into something actually enforceable rather than a policy written down somewhere and hoped for.

Adoption numbers suggest the industry already senses this tension, even where the language for it hasn't caught up. By early 2026, 90% of developers report using AI at work in some form, yet only 22% have deployed AI coding agents specifically, and roughly 13% report AI operating across the full software delivery lifecycle. The governance gap, not any shortfall in what the models can do, is what's holding those adoption numbers down. Enterprises that have pushed through report an substantial ROI from agentic deployments, with the strongest returns occurring in incident response and code review, which happen to be exactly the workflows that require an agent to hold real production credentials. Under a static credential model, that requirement is often too risky to authorize at any real scale. Scoped, brokered credentials are what make authorizing it defensible.

The PORTICO model and emerging academic work on task-contracted capabilities

PORTICO, published by Igor Santos-Grueiro at the International University of La Rioja in June 2026 (arXiv:2606.22504), formalizes a good deal of what the broker architectures above do in practice. It functions as a reference monitor sitting between an agent's planner and the capabilities that planner can reach, compiling an explicit task contract into four parts: an initial capability set, rules governing further grants, trusted closure predicates that determine when a task is actually done, and global deny rules that hold regardless of what the task contract otherwise allows.

Capability expansions happen through a request-grant-invoke lifecycle, and each expansion materializes as an opaque, epoch-bound handle rather than a persistent permission. When a task closes, that closure removes the relevant handles from whatever interface the planner sees next, and any attempt to replay a stale handle gets rejected before it can cause a side effect, not after. That ordering, catching the replay before execution rather than logging it afterward, is the detail that separates a monitor from an audit trail.

The empirical result reported is notable on two counts. Across the evaluated coding-agent runs, PORTICO recorded zero executed contract-forbidden effects: nothing the task contract prohibited actually ran. And controlled, deliberate grants under the framework recovered legitimate boundary work that a fixed, narrow permission envelope would otherwise have blocked outright, suggesting the model doesn't just restrict agents, it lets them do more, safely, than a blunt fixed-scope policy would allow. That's the same shape of result the broker architectures produce operationally: security and capability moving in the same direction, rather than trading against each other, once the credential's lifetime finally matches the task it was issued for.