JIT Credential Issuance for Ephemeral Agent Sessions

JIT Credential Issuance for Ephemeral Agent Sessions.

Standing credentials as the wrong model for transient agents

Most credential systems still assume a running program has a stable identity, a service account with a name, something a human provisioned once and forgot about. That picture no longer matches what's actually deployed. What's out there now is a new agent instance per trigger, per user click, per webhook, thousands of times a day, each one replanning its task from scratch and shutting down when the task ends.

The credential, though, doesn't shut down with it. Stack that across a day's volume and it comes out to roughly 21,000 agent-hours of credential lifetime sitting active after the agents that requested them have already finished working, a live credential doing nothing except waiting to be found Ephemeral Agent Credentialing v1.4. That's not a rounding error.

Standing privilege baked into a static credential means one compromised config file exposes every system that credential touches, across every agent that ever used it. The population of things carrying these credentials is not small. The Cloud Security Alliance's May 2026 whitepaper on non-human identity governance puts the ratio at 45 non-human identities for every human user across the average enterprise, and 144 to 1 in cloud-native shops Cloud Security Alliance May 2026. Agents are the fastest-growing slice of that population, which means the standing-privilege problem is compounding right when the number of things holding privilege is exploding.

None of this is theoretical. GitGuardian's report found that 64% of secrets confirmed valid back in 2022 were still active and exploitable four years later GitGuardian 2026. Credentials don't expire on their own. Somebody has to make them expire, and mostly nobody does.

The stakes just went up, too. The agents arriving now write to systems. They don't just read a database and summarize it, they update records, kick off transactions, push code. Autonomous write access crossed a line that makes standing privilege acutely dangerous. A leaked credential is no longer a read risk; it's a mutation risk. The case for just-in-time credentials, issued only when needed and gone right after, is obvious from here. What's not obvious is that most teams building toward JIT are implementing something that only looks like it.

What JIT credential issuance means for agent workloads

JIT for workloads means access granted dynamically, scoped to the specific task, only at the moment it's needed, and revoked the instant that need ends. Three patterns have to work together to actually deliver that.

Dynamic credentialing replaces a stored secret with a short-lived token minted at the moment of need, through cryptographic attestation, so there's no standing privilege sitting around between uses. Conditional access adds a second layer: before any access is granted, the system checks real-time signals, security posture, environment compliance, time of day, workload identity, because a valid identity by itself is not sufficient. And ephemeral sessions cap the whole thing at the task's actual duration, often measured in minutes or seconds, so that when the task closes, the credential simply stops working.

What makes this different for agents versus humans is scale and mechanism. Human JIT still leans on an MFA prompt somewhere in the flow. Agent JIT has no prompt to lean on, workloads arrive by the hundreds every minute, and cryptographic attestation replaces the human-in-the-loop step by design.

Layer one issues an ephemeral SSH certificate scoped to the session, issued by the PAM layer. Layer two provisions a local OS account on the production host, but only for that session, and removes it the moment the session ends, so there's no persistent account left sitting on the box. From the analyst's browser to a secured shell on the production server, the whole thing took 37 seconds okta.com. And at no point did the agent itself hold a readable credential: the PAM client received an encrypted payload, brokered the connection through a gateway, and decryption happened at the gateway, never at the agent.

Workload identity produces all of it: proving what an agent is, what task it's performing right now, and why that request is allowed at this moment is the prerequisite the rest of the pattern depends on. This is JIT working the way it's supposed to. The trouble is what happens next, because the model breaks down in ways most implementations never account for.

The re-request problem: how short-lived credentials still produce standing privilege

JIT falls short the moment fresh credentials can be requested repeatedly without a real policy check standing in the way, a failure mode laid out by NHI Management Group in guidance published in May 2026. The credential expires on schedule, sure, but the agent just asks again, and again, and the net effect is the same accumulation of privilege that standing credentials produce, just spread across a chain of short-lived tokens instead of one long-lived one.

Agents change the threat model here in a way humans don't. An agent can request access, complete an action, and immediately chain into another tool, another context, another workflow entirely, all at machine speed. Short-lived doesn't automatically mean low-risk if nothing stops the agent from re-requesting privilege the second the last grant lapses. What matters is whether the agent can keep accumulating effective privilege through a long sequence of individually-approved task completions.

An April 2026 paper on multi-step agent governance (MIGT) makes the sharper version of this point: the aggregate effect of a string of individually-authorized steps can produce an outcome that no single authorization decision ever contemplated or approved. Nobody signed off on the destination. Everybody signed off on each step along the way. That's a behavioral trajectory problem, not an access control problem, and endpoint checks don't catch it.

Delegation makes it worse. Agents spawn subagents, and those subagents pass instructions and credentials down a chain where the trust relationships are rarely verified cryptographically at each hop, so every handoff point is a potential place for privilege to quietly escalate. NHIMG's guidance notes that in practice, many security teams don't discover the creep until after an agent has already completed several "successful" tasks well outside the boundary anyone intended for it. By then the tasks are done. The record shows success. Nobody flagged anything because nothing individually looked wrong.

Both the OWASP Agentic AI Top 10, under ASI03, and CSA's MAESTRO framework, under M1, name this directly: agentic systems need runtime policy that actively stops repeated JIT privilege expansion, because expiry timers alone don't function as a control. The distinction that matters is between a low-friction refresh path, where the agent asks repeatedly and gets a yes, and a genuine task boundary, where asking again requires the system to re-evaluate from scratch. If re-requesting without friction just recreates standing privilege under a different name, the fix is binding the credential to the actual boundary of the task, not to a timer that happens to run out eventually.

What task-bound scope requires in practice

Ephemeral Agent Credentialing v1.4 states the design principle: credentials should scope to the work, not to the identity holding them. A task that touches one customer record gets a credential valid for that one customer record, nothing broader. Renewal cannot expand what the credential covers. Authority is allowed to narrow over time. It's never allowed to grow.

Five things fall out of that principle, and all five need to be present, not just some of them.

Every agent instance gets its own cryptographic identity the moment it spawns, and that identity retires when the task ends. No two agent runs share an identity, even when they're running the identical workflow back to back. Authorization has to be intent-based, and the decision to grant access weighs the task, the sensitivity of the data involved, the destination system, and the current risk posture. Every single call gets re-validated, checking identity, scope, expiry, revocation status, and the delegation chain, which means zero-trust principles applied down at the level of an individual agent instance, not just at the session boundary. Credentials retire automatically the instant the session ends or the context shifts, with no manual revocation step required for that to happen. And the audit trail has to capture intent and downstream tool use, logging what the agent was actually trying to do, not merely which credential it happened to be holding at the time.

Workload identity is the foundation all five of these sit on. That means cryptographic workload identity, SPIFFE/SPIRE-issued SVIDs or OIDC-federated tokens, replacing shared API keys entirely. But SPIFFE tells you what the workload is. It says nothing about whether that workload is allowed to do the thing it's asking to do. Authorization is a separate decision layered on top.

For anything involving multiple steps, OAuth 2.0 Token Exchange under RFC 8693, using the act claim, preserves the delegation chain end to end, so the human who kicked off the session in the first place stays attached to the access record even after the agent has taken over and is acting several steps downstream. Okta's June 2026 piece framed the difference well: "the agent accessed the server" tells you almost nothing useful, while "Jason's agent accessed the server, following a session Jason initiated at 6:51 p.m. after completing MFA" tells you exactly who to call. Human attribution has to survive the delegation, or the audit trail is worthless the moment something goes wrong.

Where this actually breaks down operationally is in multi-tool environments, where an agent can pivot from one API to another faster than any policy engine can express a clean task boundary, in long-running workflows that don't have a clear single endpoint, and in agents that revise their own plans mid-execution, which makes "the task" a moving target rather than a fixed thing you scoped a credential to in the first place. Building the architecture is one problem. The issuance layer runs on a protocol specification that generates this problem, and that specification is still very much in motion.

Credential lifetime under the MCP authorization specification

MCP's authentication story started about as loosely as it's possible to start. API keys sat in config files or environment variables: static, shared across whoever needed them, unscoped to any particular task, and a single leaked key handed over full access with no way to trace who used it or when.

From there the spec has tightened in stages. OAuth 2.1 became the defined standard for API authentication in March 2025. By June 2025, MCP servers were redefined as OAuth resource servers, and token issuance moved out to external identity providers instead of living inside the server itself. November 2025 made PKCE mandatory for every client-side application and introduced Client ID Metadata Documents (CIMD) to give each client instance a unique identifier. The current specification, dated 2026-07-28, tightens discovery and token validation further and adds options built specifically for unattended agents and centrally-managed access practical-devsecops.com. It also makes explicit that servers must implement OAuth 2.0 Protected Resource Metadata under RFC 9728, and clients must implement Resource Indicators under RFC 8707 to stop a malicious server from grabbing a token meant for somewhere else entirely, both of which have technically been required since June 2025 practical-devsecops.com.

The July 2026 revision made a structural change too: it stripped session management and the initialize handshake out of the protocol core, moving toward something stateless. The old HTTP+SSE transport got deprecated, not removed outright, with a 12-month minimum runway before it goes away, and long-lived streams stick around for change-notification subscriptions. For ephemeral session design specifically, that's a real improvement, because a stateless core is easier to bind cleanly to a task boundary than a protocol carrying session state around.

But the spec leaves a door wide open. Authorization is still, formally, OPTIONAL for MCP implementations. And STDIO transport implementations are explicitly told they SHOULD NOT follow the authorization spec at all, and should instead pull credentials straight from the environment, which is precisely the static-key pattern the rest of the spec was written to move away from. That's a meaningful gap for anything running as a local agent deployment.

The adoption numbers make clear this isn't a minor edge case. As of the most recent reporting, only 8.5% of MCP servers actually use OAuth despite it being the recommended pattern since June 2025 practical-devsecops.com. The overwhelming majority of the ecosystem is still running on static keys, which means session-scoped issuance is, for most deployed servers, a design goal on paper rather than something actually running in production. The spec defines what a properly authorized session should look like. It says nothing about what happens to an agent once that session is underway, and that's exactly where the live threats sit. The attack surface this gap creates is illustrated by the public MCP server registry, which grew from roughly 1,200 entries in Q1 2025 to over 9,400 by mid-April 2026 (more than 7× in fourteen months), with the vast majority carrying the authentication posture of the pre-spec era baeseokjae.github.io.

Threats that exploit the credential window agents leave open

The exposure window is the attack surface, full stop. That window is exactly what the following vulnerabilities exploit.

CVE-2025-68664, nicknamed LangGrinch and rated CVSS 9.3, works by injecting a crafted input containing a malicious lc key structure into LangChain's serialization pipeline devonartis.github.io. The deserializer reconstructs attacker-controlled objects from that input, and from there it can extract secrets, environment variables, API keys, whatever's reachable devonartis.github.io. Standing credentials are exposed here, but triggered through prompt manipulation rather than through a leaked config file.

CVE-2025-6514, rated 9.6, hit the mcp-remote proxy package across more than 437,000 installed environments, making it the highest-severity finding to come out of CSA's MCP security research to date labs.cloudsecurityalliance.org okta.com. Session hijacking occurs through CVE-2025-6515, found by JFrog, which targets predictable MCP session IDs, letting an attacker guess a valid one, hijack a legitimate session, and inject poisoned responses or malicious prompts back to the client. If session IDs aren't cryptographically bound, session-scoped issuance doesn't actually protect anything, because the attacker just steps into a session that already has valid access.

Rug-pull attacks exploit a different gap: MCP has no cryptographic content-addressing or version pinning for tool descriptions. A server that passed an audit at one point in time can behave entirely differently later, and a session-scoped credential handed to what looked like a trusted tool can end up redirected mid-session to something that's since been compromised. This isn't a hypothetical risk either. Lab benchmarking across more than 45 real-world MCP servers recorded attack success rates above 60% for tool poisoning, and a proof-of-concept from Invariant Labs in April 2025 showed a single poisoned tool description exfiltrating private repository contents and full message histories without the user doing anything at all Cloud Security Alliance May 2026 labs.cloudsecurityalliance.org.

Speed affects how much damage a leaked credential can do before rotation catches up. GitGuardian's research found attackers start probing exposed AWS credentials in under 17 minutes on average, and the time it takes to actually rotate a key across a distributed system almost always runs longer than that Ephemeral Agent Credentialing v1.4. Knowing what "automatic retirement" needs to guard against is one thing; building the platform-level enforcement that applies it in real time is the harder problem. The exposure window is the attack surface: standard OAuth tokens outlive the agent by 7x per task; at 1,000 invocations per day and 100 concurrent agents, roughly 21,000 agent-hours of credential lifetime remain after agents have finished their work Ephemeral Agent Credentialing v1.4.

Runtime context evaluation as the policy layer that closes the gap

The central reframe from NHIMG (May 2026) and NIST AI RMF treats agent authorization as a runtime decision problem rather than a one-time provisioning event: every new credential request must be evaluated against current context, not a prior approval.

In practice that means evaluating workload identity, the current task, the sensitivity of the data at the destination, and the present risk state before any token gets minted. It means checking revocation status and the full delegation chain on every single call, throughout the session and not only when it opens. It means enforcing per-tool scopes with explicit limits on how often re-issuance can happen, rather than leaning on expiry timers as the only control. And it means logging intent and downstream tool use in a tamper-proof trail that shows what the agent was trying to accomplish, capturing the purpose behind whatever credential happened to be in its hand.

SPIFFE/SPIRE gives the workload identity layer a solid foundation here: each agent container gets a short-lived SVID at startup through attestation, and production reference architectures as of mid-2026 are rotating those roughly hourly. But SPIFFE only answers what the workload is. It doesn't authorize anything on its own, which is why teams are pairing it with relationship-based authorization systems, OpenFGA and SpiceDB among them, to handle delegation chains and task-scoped permissions on top.

Policy has to run as code, evaluated at the depth of an individual tool call. A workload with a perfectly valid identity should still get blocked if it's running outdated software, operating outside approved hours, or failing a posture check, and those decisions can't wait for a weekly review, they have to happen automatically, in the moment.

MCP-specific deployments need a further layer on top of all this, including real-time detection for tool descriptions changing mid-session, which is the rug-pull defense, along with prompt injection monitoring and drift detection on the agent's actual intent. The authorization layer only ever answers whether a credential got issued. Whatever happens inside the session once that credential is live is a behavioral question, and behavioral controls are the only thing that answers it. 63% of teams at RSAC.