JIT Credential Provisioning for AI Agents in Enterprise Pipelines

AI agents have broken the core assumption behind enterprise IAM: that the thing requesting access is a human being. The fix is not a tighter policy or a shorter token lifetime. It is JIT credential provisioning, a structural inversion that replaces standing access with task-scoped, time-bound credentials tied to every agent action.

Why AI agents broke enterprise IAM before anyone had a governance answer

Enterprise identity and access management was built around a single premise, and that premise has collapsed. The primary subject of access control was always a human being, someone who authenticates interactively, exercises judgment, holds organizational accountability, and can be suspended with one administrative action. AI agents do none of those things in the same way. They authenticate programmatically, execute at machine speed, cross trust boundaries that span organizational perimeters, and spawn child agents dynamically.

An AI agent is a goal-directed system that plans, selects tools, invokes external services, generates sub-tasks, and delegates authority to other agents, all in real time and without step-by-step human direction. When an orchestrating agent creates ephemeral sub-agents to run parallel research tasks, each one needs authenticated access to tools, data sources, and APIs. That means credentials, scope definitions, tracking, and revocation on task completion. None of this happens automatically under legacy IAM architectures.

The scale makes the mismatch unavoidable. The Agent Identity Governance Framework cites Cloud Security Alliance research showing that non-human identities outnumber human identities by more than 90 to 1 in many organizations, with some enterprises reporting ratios as high as 144 to 1 [1]. Meanwhile, the same research found that most legacy IAM solutions cannot effectively manage AI and NHI risks, and a large majority of organizations lack formally documented policies for creating or removing AI agent identities.

The stakes are now existential for enterprise security. CrowdStrike found that 82% of detections are malware-free, meaning intrusions move through authorized pathways using trusted systems. Identity has become the primary attack surface, and the identities multiplying fastest are the ones least governed.

How standing privileges become the dominant failure mode in agent deployments

The default way enterprises deploy AI agents copies the worst habit of service-account management. Credentials are issued at creation time and stay valid until someone explicitly revokes them, long after the business context that justified them has ended. Some agents use hardcoded API keys. Very few organizations track agent provenance, time-to-live, or risk level in any consistent, enforceable way.

The difference between an agent and a service account is the conceptual lever the entire problem turns on. A service account is static. An AI agent decides at runtime what tool to call, what data to read, and what action to take. The credential was issued with good intentions, but the agent holding it can be redirected without warning.

What that credential can do when redirected is the frightening part. Research cited in the Agent Identity Governance Framework found that nearly three-quarters of secrets held by non-human identities carry excessive permissions. When an agent inherits such a credential, the blast radius of compromise extends far beyond the agent's original purpose.

This is not a theoretical concern. That accountability gap is what makes standing privilege dangerous rather than merely untidy. A credential no one tracks, held by an identity no one owns, attached to an agent whose intent can change mid-session: that is the dominant failure mode, and every downstream problem starts there.

Why MCP servers turned the credential problem from theoretical to active

The Model Context Protocol has become the primary integration layer for enterprise AI agents. The result is a problem that is no longer hypothetical. Trend Micro found 492 MCP servers exposed to the internet with zero authentication.

The authentication gap is structural, not incidental. Research shows only a small fraction of MCP implementations use OAuth, and a great majority carry path traversal risks. The named incidents make the threat concrete. In January 2026, researcher Yarden Porat published an exploit chain against Anthropic's own official Git MCP server, covering unrestricted git_init, argument injection, and repository scoping bypass across three CVEs. An attacker could access configuration details, API keys, and authentication tokens without valid credentials. That vulnerability carries a CVSS score of 9.1. In April 2026, OX Security disclosed a systemic architectural flaw exposing an estimated 200,000 vulnerable instances across a supply chain with more than 150 million package downloads.

The exploit surface extends beyond exposed servers. The ClawHub and OpenClaw marketplace incident in February 2026 confirmed the risk at industrial scale. Antiy CERT identified 1,184 malicious skills, and Snyk's ToxicSkills audit found that 36.82% of thousands of skills contained at least one security flaw, with 13.4% rated critical.

What ties these incidents together is not a failure of the protocol's design. Most MCP servers assume trust where none should exist, and agents inherit that assumption when they connect. The authentication gap is the root cause of most incidents in this ecosystem, and no amount of prompt filtering or output scanning closes a hole that starts with an unauthenticated connection.

What JIT credential provisioning actually does and how it inverts the standing-privilege relationship

JIT credential provisioning solves standing privilege not by tightening expiry times on existing credentials but by changing the architecture. An agent receives no operational privileges at creation time. It must declare intent before any credential is issued. That is the inversion.

Instead of receiving a standing grant at provisioning time, an agent gets a minimal baseline identity. It is sufficient to identify itself to the authorization infrastructure and declare intent, but nothing more. When the agent is assigned a task that requires privileged access, it submits an intent declaration to the authorization system before requesting any privilege elevation. A shorter TTL still grants the credential up front. JIT withholds it until the moment of need, and the agent must say what it intends to do before the system decides whether to grant access.

The practical pattern follows from that core move. Use workload identity for the agent rather than a shared service account. Issue short-lived credentials only for the current task. Attach policy checks to the request path. Log the intent, the action, and the downstream tool use. For orchestrator identities, the Agent Identity Governance Framework recommends mutual TLS or SPIFFE SVIDs rather than API tokens alone. For ephemeral sub-agents that spin up at high velocity, a lightweight delegation token derived from the orchestrator's SVID works, with the orchestrator's trust domain and parentage recorded in the token claims. That preserves the audit trail while reducing attestation latency.

The audit consequence is decisive. All three are linked by agent identity and task identifier. That linkage is what a static service account can never provide, because a static service account has no moment of intent to record.

Two JIT models apply depending on the agent type. Minimal-profile JIT gives an agent a unique identifier with token-based claims and no full directory profile, which suits ephemeral or external agents. Full-profile JIT registers the agent in the identity provider with complete attributes, provenance, delegation information, TTL, and risk classification, which suits recurring internal agents. Both models share the same principle: the intent declaration comes first, and the credential follows only after the system has decided the intent is legitimate.

How the MCP specification's OAuth 2.1 requirements create the authorization foundation JIT needs

The MCP specification has moved toward OAuth 2.1 as a required standard for remote servers. The June 18, 2026 MCP Enterprise-Managed Authorization extension marked a stable release of the Identity Assertion JWT Authorization Grant, known as ID-JAG. During SSO, the client obtains an ID-JAG token from the identity provider, then exchanges it for an access token from the MCP server's authorization server. The per-server consent step disappears, which matters for enterprise SSO integration at scale.

Named implementations have started shipping. The GA release includes Client ID Metadata Document registration, on-behalf-of token exchange for downstream API calls, and Resource Parameter Compatibility Mode for spec compliance. The July 28, 2026 MCP spec revision went further, requiring MCP clients to implement Resource Indicators for OAuth 2.0 as defined in RFC 8707, with the resource parameter mandatory in both authorization requests and token requests.

Yet OAuth scopes alone cannot answer fine-grained tool authorization. AuthZEN reached final specification status in January 2026 and is built specifically for fine-grained authorization in agentic deployments. It is the standards-aligned complement to OAuth. Above the technical layer, the CSA AI Controls Matrix, released in July 2025 with 243 control objectives across 18 security domains including a dedicated Identity and Access Management domain, provides the governance mapping that turns these technical controls into auditable requirements.

The infrastructure is arriving, but it is not yet complete. That is not a failure of the standard. It is an honest accounting of where the industry stands.

Where JIT provisioning breaks down and what must accompany it

JIT narrows the window of exposure, but it does not eliminate privilege accumulation unless policy checks govern every re-issuance. Short-lived credentials do not automatically mean low risk if the agent can re-request privileges with no meaningful policy friction. An agent that keeps getting fresh credentials in short bursts has effectively recreated standing privilege, just in smaller increments.

The structural objection from long-running workflows is legitimate. When an agent must operate across multi-step tasks, delegate subtasks to other agents, or survive interrupted execution, strict JIT can create friction. The answer is not to abandon JIT but to pair it with policy-as-code, per-tool scopes, and explicit limits on re-issuance. Automatic revocation on context change matters as much as automatic expiry on timer.

Operational cost is real. JIT credentials alone do not satisfy audit requirements unless the intent-declaration to token-issuance to action-execution chain is captured and linked. OWASP ASI01 and NIST AI Risk Management Framework's Govern function both make the same point: agent authorization must be a runtime decision problem, not a one-time provisioning event.

Implementing JIT credential provisioning: what enterprises need at each maturity level

A working JIT architecture for AI agents requires four layers operating together: agent inventory and baseline identity, intent-declaration and policy enforcement at tool-call depth, credential issuance with workload binding, and tamper-proof audit logging with a full delegation chain. The right starting point depends on where an organization sits. The Agent Identity Governance Framework's implementation roadmap defines three maturity tiers, and each one maps to a different reader.

Tier 1 organizations have no consistent view of what agents exist, what credentials they hold, or who owns them. The starting action is basic inventory: establish agent provenance tracking and eliminate hardcoded API keys. Before any JIT work begins, that ledger must exist.

Tier 2 organizations have partial automation with inconsistent lifecycle controls. The priority is binding each agent to a workload identity, introducing per-task credential issuance, and attaching policy checks to the request path rather than relying on periodic reviews. This is the platform team that has solved inventory but still grants credentials at provisioning time.

Tier 3 organizations are ready for full JIT orchestration. That means intent-based authorization with real-time policy decisioning, SPIFFE SVIDs or delegation tokens for orchestrator and sub-agent chains, and automated deprovisioning tied to task completion. The five controls from the AGENT framework, drawn from the 2026 CISO Playbook, serve as a production checklist at this tier. Attest: a unique, cryptographically verifiable identity tied to a human owner. Enclose: agents run inside a sandbox with explicit allow-lists on tools, data, and outbound calls. Terminate: automatic deprovisioning at end of lifecycle.

For MCP deployments specifically, three requirements sit on top of general JIT. Use OAuth 2.1 with RFC 9728 Protected Resource Metadata. None of these are optional at Tier 3.

Procurement is already reflecting this shift. Weak agent governance now blocks deals in a way analogous to missing SOC 2 reports a decade ago. The market has decided that agent governance is table stakes.

Runlayer addresses this architecture as a unified platform. It provides SSO and SCIM for agent identity tied to the enterprise directory, JIT credential issuance with OAuth and credential handling built in, policy enforcement at tool-call depth across 18,000+ MCP servers, real-time detection for MCP-specific threats including tool poisoning and prompt injection, and tamper-proof audit logs with full OTEL tracing. That covers the inventory, policy, issuance, and audit layers a complete JIT implementation requires without forcing separate agent builders, gateways, and security tools to coordinate.

The governance posture reversal is the real ending. When JIT provisioning is implemented correctly, security and platform teams become the ones who make broad agent adoption possible, because every agent action is auditable and every credential is scoped. They stop being the teams who must slow adoption down to contain unknown risk. They become the teams who can say yes. And saying yes at scale is the entire point of enterprise AI.