WHAT YOU NEED
TO KNOW NOW
AI agents are not humans, and they are not traditional service accounts. They plan, decide, and act — sometimes across dozens of systems, sometimes with no human present — and they do so under identities that most enterprise IAM programs have never modeled. The absence of a first-class identity framework for agents is not a gap on a roadmap; it is an active control failure. Agents are already in production in most enterprises. The question is whether their access is governed or accidental.
This framework defines how AI agents are identified, credentialed, governed, and retired within the enterprise. It is grounded in three governing standards — NIST AI RMF, the OpenID Foundation and IETF OAuth working group's token delegation specifications, and the CNCF SPIFFE/SPIRE workload identity framework — and maps each lifecycle stage to the authoritative event sources that should trigger autonomous IAM action. It covers the four human-oversight modes that determine an agent's authorization model, the agent-to-agent delegation pattern that creates transitive trust chains, and the access mechanics that make it real: workload identity federation, PAM adapted for unattended operation, and MCP server access control as a governed IAM boundary.
The core discipline is straightforward: treat agent lifecycle events the same way you treat human joiner-mover-leaver events — but at machine speed, driven by authoritative data, with no grace periods and no orphaned credentials. The hard work is instrumenting the event sources and closing the control gaps before a regulatory examination or an incident forces the conversation.
THE NEW
IDENTITY CLASS
Enterprise IAM has historically managed two identity types: human identities governed by joiner-mover-leaver processes, and non-human identities (service accounts, API keys, certificates) governed by secrets hygiene and rotation policies. AI agents fit neither category cleanly — and forcing them into either produces dangerous gaps.
- No interactive authentication — cannot enroll in MFA or approve a push notification
- No natural change signal — a human job change is visible in HR; an agent's equivalent (model swap, prompt update) may be invisible to IAM
- Scale and velocity — a single orchestrator can spawn hundreds of worker agents; human IAM processes cannot match that pace
- Behavioral drift — effective behavior can change without a configuration change, through model version updates or prompt injection
- Agentic reasoning — they decide what to do, not execute a predetermined sequence; blast radius of a compromise is therefore unpredictable
- Dynamic capability discovery — agents using MCP or similar protocols acquire capabilities at runtime, not at deployment
- Human accountability chain — every agent action must trace back to a human or business function; a service account has no equivalent requirement
- Declared intent — agents have a stated purpose that constrains what they should do, enabling behavioral monitoring against a declared baseline
Treat agents as a distinct identity class that inherits discipline from both sides: human IAM provides joiner-mover-leaver structure, recertification cadence, ownership accountability, and dual attribution in audit logs. Non-human identity (NHI) management provides workload attestation, ephemeral credentials, vault-brokered secrets, and rotation automation. The additions unique to agents are: declared intent, behavioral scoping, mode-based authorization, and kill-switch capability with a defined SLA.
What "first-class identity" means in practice
An agent has a first-class identity when it has a unique, registered entry in the authoritative identity store — not a borrowed human account, not a shared service credential, not a generic API key. That entry carries: a unique identifier, a named owner, an accountable executive, a declared operating mode, a risk tier, a list of permitted systems and action types, permitted MCP servers, and a status (active, suspended, decommissioned). Every credential the agent holds traces to that registry entry. Every action it takes is attributed to that identity. No registry entry means no credentials — no exceptions.
GOVERNING
STANDARDS
Three bodies of work provide the authoritative foundation for agent identity governance. None of them are agent-specific — but together they cover the three planes that agent IAM requires: risk management and governance structure, delegation and token semantics, and workload identity. Emerging standards specific to AI agents are building directly on these foundations.
NIST provides the risk management vocabulary that enterprise governance bodies already understand. The AI Risk Management Framework 1.0 (AI RMF, 2023) establishes four functions — Govern, Map, Measure, Manage — that map directly to agent lifecycle governance: Govern establishes policy and accountability structure; Map identifies which agents exist and what they affect; Measure assesses behavioral drift and control effectiveness; Manage drives the remediation workflows triggered by lifecycle events. The Generative AI Profile (AI 600-1, 2024) extends this to LLM-based agents, identifying excessive agency, data poisoning, and prompt injection as primary risks — all addressed by the mode classification and behavioral monitoring in this framework.
NIST SP 800-207 (Zero Trust Architecture, 2020) provides the access control philosophy: never trust, always verify, assume breach. For agents this translates directly to the ephemeral credential model — no standing access, every credential request is an authentication and authorization decision evaluated against current policy. NIST SP 800-63 (Digital Identity Guidelines) provides the assurance level structure that determines credential strength requirements per operating mode.
The delegation and token semantics problem — how does an agent prove who it is, on whose authority, with what scope — is the domain of the OpenID Foundation and IETF OAuth working group. RFC 8693 (OAuth 2.0 Token Exchange) is the foundational specification for agent identity in practice. It defines the protocol by which an agent presents its workload identity and receives an enterprise-issued access token scoped to the interaction. The actor and may_act claims in the resulting token carry the dual attribution that P7 requires: which agent, acting on behalf of which human or delegation grant.
RFC 9396 (OAuth 2.0 Rich Authorization Requests) extends this by allowing the token request to carry a structured authorization detail object — describing not just what the agent is allowed to do in general, but what specific operation it is requesting right now. This is the technical mechanism for "declared intent at token time." The OpenID Foundation has active working group discussions on non-human identity (NHI) patterns and agent authorization built on OIDC Core and token exchange. The IETF OAuth working group's identity chaining draft directly addresses the agent-to-agent delegation problem: how attribution and scope constraints survive when Agent A delegates to Agent B.
SPIFFE (Secure Production Identity Framework for Everyone) is the CNCF specification that defines how software workloads — containers, pods, VMs, serverless functions — prove their identity without static secrets. A SPIFFE identity is a URI (the SPIFFE ID) issued in a cryptographically verifiable document called an SVID (SPIFFE Verifiable Identity Document). SVIDs come in two forms: X.509-SVIDs for mTLS-based workload authentication, and JWT-SVIDs for HTTP bearer token scenarios. Both are short-lived, automatically rotated, and issued by a SPIRE (SPIFFE Runtime Environment) deployment that performs workload attestation — verifying that the software claiming an identity is actually running where and how policy says it should be.
For agent IAM, SPIFFE/SPIRE solves the bootstrap problem: how does an agent get its first credential without a human handing it a secret? Workload attestation — the SPIRE agent verifies the workload's properties (container image digest, Kubernetes service account, cloud instance identity) and issues an SVID. That SVID is the agent's proof of identity, used to authenticate to the secrets management platform, enterprise APIs, PAM systems, and MCP servers. The SPIFFE trust bundle integrates with enterprise IdPs through federation, enabling token exchange (RFC 8693) from SVID to enterprise OAuth 2.0 token.
Additional reference frameworks
LLM08 (Excessive Agency) and LLM09 (Overreliance) directly address the scope and oversight controls in Modes 3 and 4. The OWASP taxonomy provides threat language that maps to the operating mode controls in this framework.
The international standard for AI management systems. Provides the management system structure — policy, objectives, risk assessment, internal audit — that sits above this technical framework and is increasingly referenced in global regulatory guidance.
OPERATING
MODES
Every deployed agent must be classified into exactly one primary operating mode. The mode is a control selector, not a label — it determines the identity construct, credential pattern, authorization model, accountability structure, and recertification emphasis. Moving an agent from a lower-autonomy mode to a higher one is a material change requiring re-approval, exactly as a promotion into a privileged role triggers access review for a human.
The agent acts as an extension of a specific human's session and entitlements. It holds no meaningful entitlements of its own; authorization decisions evaluate the human's identity. The agent's token carries an act claim (the agent) nested within the subject's (human's) token — the RFC 8693 actor pattern. The agent can never exceed the human's access and should receive less via scope intersection. Every action is attributed as "User X via Agent Y." The human is the accountable party. Kill-switch is the human ending their session. MCP tool access is bounded by the human's effective scope at token issuance.
The agent acts under an explicit, scoped, time-bound delegation grant from a human or business function. It has its own first-class identity and constrained entitlements provisioned specifically for the delegation. The delegation grant is a recorded artifact: who delegated, what scope, what duration, what constraints, what revocation path. Accountability is dual — the delegator remains accountable for the grant; the agent owner is accountable for agent behavior within it. Grant expiry is an authoritative lifecycle event: when it fires, delegated credentials are revoked automatically. MCP access is bounded by the delegation grant scope and expires with it.
The agent operates with its own identity and entitlements, but a human is present in the session and gates consequential actions in real time — approve/deny checkpoints, step-up authentication for sensitive operations. High-impact actions require in-session human approval, captured as a signed approval event in the audit trail. Accountability is shared at the action level: the agent owner is accountable for agent behavior; the approving human is accountable for each gated action they approve. MCP tool invocations classified as high-impact require in-session human approval before execution.
The agent runs independently with no human in the loop at execution time, within a pre-approved operating envelope. No interactive approval path exists — all risk acceptance happens up front through governance, and at runtime through guardrails, anomaly detection, and circuit breakers. Autonomy is a privilege granted by the governance body, not a default. Mode 4 requires explicit sign-off from an accountable executive. Irreversible or customer-impacting actions in regulated processes default to a human gate until the governance body explicitly accepts the residual risk. The tightest MCP scope applies; manifest changes trigger re-approval without exception.
Agent-to-Agent Orchestration — the cross-cutting trust chain
Agent-to-Agent (A2A) orchestration is not a fifth mode. It is a trust chain pattern that applies within any of the four modes when one agent (an orchestrator) invokes another agent (a worker). The IAM challenge is that each hop in the chain is a delegation decision that must be enforced at the control plane, not assumed.
An orchestrator can only delegate a subset of its own authority to a worker. A worker agent cannot receive permissions the orchestrator does not have. The effective permission of any operation in a chain equals the narrowest intersection of all principals in the chain. This must be enforced at the token validation layer — not by trusting the orchestrator to self-limit.
[User U] → [Orchestrator A] → [Worker B]. Every API call B makes carries this lineage, enabling full attribution. The IETF OAuth working group's identity chaining draft defines this token structure.Vendor-embedded agents
Agents embedded in SaaS products run in the vendor's environment — you cannot deploy SPIFFE/SPIRE on them. The approach: register them in your agent registry as vendor-managed class, scope their access via OAuth 2.0 connected apps with explicit minimal scopes, require the vendor to provide agent identity in their audit logs, and ingest those logs into your SIEM. Mode classification still applies — most embedded agents are Mode 2 or Mode 3. The accountability and recertification requirements do not relax because the workload is vendor-hosted.
THE AGENT
IDENTITY LIFECYCLE
The agent identity lifecycle has eight stages. The diagram below shows the flow, the three governance loops that branch from the active stage, and the end-of-life path. The event trigger table in the next section maps the specific authoritative data sources that drive each transition automatically.
FIGURE 1 — AI AGENT IDENTITY LIFECYCLE · 8 STAGES · 3 GOVERNANCE LOOPS FROM ACTIVE STATE
Business justification, operating mode declaration, data classifications, target systems, named owner and accountable executive, and risk tier assignment. High-tier and all Mode 4 requests route to the AI governance body. No registry entry is created until the request is approved.
Agent registered in the Agent Registry — the system of record. Captures: unique ID, owner, accountable executive, builder/vendor, model lineage, environment, declared intent (purpose, permitted action types, target systems, data classifications, permitted MCP servers), risk tier, applicable regulations, gateway and guardrail configuration. No credentials are issued before registration is complete and approved.
Identity created in the enterprise IdP as an agent-class object — never disguised as a human account. Entitlements provisioned via IGA to declared intent: least privilege, birthright equals nothing. Credentials issued per mode. Default expiration set on the agent identity itself. Pre-production validation and behavioral baseline established before go-live.
All agent traffic routes through an instrumented control point — agent gateway or API proxy — enforcing policy, capturing dual-attribution logs, and applying rate limits. Continuous monitoring for intent drift: actions outside declared scope, novel target systems, anomalous volume or timing. This stage feeds three governance loops: Change Review (5), Recertification (6), and Suspension (7).
Triggered by: mode change, material model/prompt/toolset update, new MCP server or expanded tool scope, new target system or entitlement expansion, or ownership change. Re-review depth proportional to risk tier. Entitlement deltas flow through IGA, not side channels. On approval, agent returns to Stage 4 with updated registry record.
Owner and accountable executive recertify on a tier-based cadence (Tier 1: quarterly; Tier 2: semi-annual; Tier 3: annual). Covers: continued business need, entitlement appropriateness, mode appropriateness, MCP server scope, and behavioral-drift review. Unused entitlements are auto-flagged. Failed or missed recertification triggers automatic suspension — no grace period.
Tested procedure to suspend an agent within the defined SLA: token revocation, vault lease revocation, PAM session termination, and gateway block — all four must execute together. Suspension preserves identity, registry record, and audit history. The agent can be reinstated or retired. Kill-switch procedures are tested at least annually.
Formal retirement: entitlements revoked, credentials destroyed, secrets rotated on shared systems, gateway enrollment removed, MCP server access revoked, downstream dependencies notified. Registry record retained with full lifecycle history. Post-decommission scan confirms no residual access, tokens, or API keys. Orphan detection runs continuously.
EVENT TRIGGERS &
AUTHORITATIVE SOURCES
Autonomous IAM governance requires machine-readable events from authoritative systems — not manual tickets, not periodic reports. Each row maps a lifecycle transition to the event that should trigger it and the authoritative source category that generates it. Source categories are vendor-neutral; parenthetical examples illustrate common implementations without prescribing them.
If your IAM platform cannot receive structured events from these source systems in near-real-time, agent lifecycle governance will be manual, delayed, and incomplete. Integrating these event feeds — not building the agent registry — is the foundational infrastructure investment. Everything else in this framework depends on it.
| Trigger Event | Transition | Authoritative Source (category) | IAM Action |
|---|---|---|---|
| New agent deployment request submitted | Pre-birth | Access request system / IT service management platform | Initiates governance approval workflow; no registry entry created yet |
| Governance approval granted | → Register | IGA platform (approval engine) | Creates registry record; risk tier assigned; no credentials issued |
| Registration complete; risk tier confirmed | → Provision | Agent Registry (system of record) | IGA provisions IdP agent-class object; workload identity enrollment begins |
| Pre-production validation passed; go-live approved | → Operate | CI/CD pipeline; pre-production test results store | Agent enrolled in gateway; behavioral baseline recorded; monitoring active |
| Model version upgrade (major or breaking change) | → Change | Model registry / ML operations platform; container image registry | Triggers re-review workflow in IGA; agent may be paused pending approval |
| System prompt or toolset change committed | → Change | Version control system (commit hook / pull request merge event) | Change review proportional to risk tier; may require governance sign-off |
| MCP server manifest updated (tool added, scope expanded) | → Change | MCP server inventory / manifest hash comparison at gateway | Re-approval required before agent may use updated server; manifest diff logged |
| New target system or entitlement expansion requested | → Change | Access request system / IGA | Routes through IGA entitlement workflow; may trigger risk re-tiering |
| Agent owner / accountable executive departure | → Change | HR / workforce system (joiner-mover-leaver event stream) | Initiates ownership transfer; if unresolved within SLA, agent auto-suspended |
| Delegation grant reaches expiry | → Suspend (scoped) | IGA delegation store; token expiry metadata | Delegation-scoped credentials revoked; MCP access within that grant revoked |
| Recertification window opens (cadence trigger) | → Recertify | IGA recertification engine (calendar / SLA-based timer) | Certification campaign sent to owner and accountable executive |
| Recertification completed and approved | → Operate | IGA recertification engine | Agent reinstated; cadence timer reset; unused entitlements trimmed |
| Recertification missed or failed | → Suspend | IGA recertification engine (missed-deadline event) | Automatic suspension; escalation to accountable executive; no grace period |
| Behavioral anomaly / intent drift detected | → Suspend | SIEM / behavioral analytics platform; agent gateway telemetry | Auto-suspend (Tier 1) or alert-and-throttle (Tier 2/3); incident opened |
| Security vulnerability in model or dependency | → Change | Vulnerability database / CVE feed; vendor security advisory channel | Emergency change review; may auto-suspend pending patch validation |
| Kill-switch command issued | → Suspend (immediate) | IAM admin console; security orchestration / incident response platform | Token revocation + vault lease revocation + PAM session end + gateway block within SLA |
| Formal retirement decision | → Decommission | Governance record; IGA offboarding workflow | Entitlement revocation, credential destruction, MCP access revoked, registry tombstone |
| Orphan credential detected post-decommission | → Incident | Orphan credential scanner; cloud security posture management (CSPM) | Security incident opened; immediate revocation; registry audit triggered |
ACCESS MODELS
IN PRACTICE
The framework's authorization principles require a practical implementation stack. Three domains define the mechanics: workload identity (how an agent proves who it is without static secrets), PAM adapted for unattended operation (how privileged access works when no human is in the loop), and MCP server access control (how tool-invocation capability is governed as an IAM boundary).
Workload Identity — the credential root of trust
Traditional agent deployments start with a secret: an API key in a config file, a service account password in a vault, a certificate managed by a human. This is the wrong starting point. The right starting point is workload attestation — the platform proves the workload is who it claims to be, and a short-lived cryptographic identity flows from that proof automatically, without a human ever touching a credential.
Workload starts → Platform attests identity → Short-lived SVID or cloud-native token issued → Agent exchanges for enterprise token (RFC 8693) → Enterprise token used for all API calls and MCP connections → Token expires → Agent gets a new one automatically. No human touched a credential. No secret was stored. Every token carries the agent's registered identity, so every action is attributable.
PAM for Agents — privileged access without a human in the room
Traditional PAM was designed around human privilege: interactive checkout, terminal/RDP session recording, time-window-based JIT, and manager review. When the privileged actor is an agent operating unattended at high frequency, every one of those assumptions needs to be revisited.
| PAM Concept | Human Model | Agent Model |
|---|---|---|
| Credential checkout | Interactive: human authenticates, requests, receives credential for a time window | Programmatic: agent authenticates via workload identity; PAM API issues JIT credential scoped to the declared task. Pre-approved access profiles eliminate interactive approval for routine operations. |
| Session recording | Terminal or RDP session captured as video / keylog | API-level capture at the agent gateway: every request, response, resource, and outcome recorded as structured logs. Enables automated anomaly detection against the declared intent baseline — terminal recording is not meaningful for an API-only actor. |
| JIT elevation | "Elevate this user to admin for 2 hours on Server X" | "Elevate this agent to invoke create_account on System X for the duration of Task ID: ABC." Scope is operation-level and task-bound, not time-window and host-bound. The task ID ties the elevation to the declaring registry entry. |
| Segregation of duties | Policy: no single person can initiate and approve a transaction | Enforced at the control plane — gateway and IGA: an agent cannot approve its own PAM access requests, certify its own entitlements, or both initiate and authorize a high-value action. Must be a hard enforcement, not a trust-the-agent self-limit. |
| Emergency revocation | Check credential back in; terminate session; notify manager | Kill-switch: revoke token + revoke vault lease + block at gateway + end PAM session — all four within the defined SLA. Partial revocation leaves a residual access path and is not acceptable. |
Most enterprise PAM deployments lack agent-aware access profiles and API-level session recording configuration. Agents end up either excluded from PAM entirely (accessing privileged resources with long-lived secrets) or forced through interactive human approval workflows that create bottlenecks and workarounds. Building agent-aware PAM profiles is a prerequisite for any Mode 4 deployment.
MCP Server Access Control — governing tool invocation as an IAM boundary
An MCP server is a controlled resource that grants capabilities to agents. Every connection to an MCP server is an authorization decision. Three IAM problems must be solved for every MCP server in the enterprise estate.
sub (agent identity), aud (this MCP server), and scope (permitted tools). (b) Workload identity (SPIFFE SVID) — agent presents X.509-SVID or JWT-SVID; MCP server validates against the SPIFFE trust bundle; no static secrets exchanged. (c) mTLS — client certificate from enterprise PKI; strongest assurance but highest operational overhead. Prefer (a) or (b) for new deployments.mcp:tickets:read vs mcp:incidents:write. Declared intent enforcement: the MCP server validates that this agent has this server and these tool categories in its registered declared intent (via a registry claim in the token or a registry API call). Data classification guard: tools exposing restricted data require elevated assurance-level claims. The MCP tool manifest is an authorization document — reviewed at onboarding and on every server update, treated with the same rigor as an IAM policy document.sub), human context (act claim or delegation grant ID), tool name and sanitized parameters, result code, timestamp, and MCP server identity. These logs flow to the SIEM for correlation with gateway telemetry, enabling full dual attribution: "Agent Y invoked tool Z on MCP server W, on behalf of User X under Delegation Grant G." This is the audit trail that satisfies P7 for tool-invocation paths.MCP servers that expose write access to production systems, code execution capability, or access to sensitive data stores must be treated as PAM-controlled resources. JIT elevation, API-level session recording, and rate limiting all apply. An agent calling delete_record via MCP is executing a privileged write — MCP is the transport, not a bypass of the access control requirement.
Registered MCP server inventory
Just as agents are registered, the MCP servers they may connect to must be registered and approved. Each inventory entry captures: server identity, owner/operator, tool manifest hash (to detect manifest changes), list of permitted calling agents, data classifications exposed, and last manifest review date. An agent connecting to an MCP server not in its declared intent is a policy violation flagged at the gateway — not a configuration gap to be cleaned up later.
Defense in depth for the capability plane
Two enforcement layers must both be present: the agent gateway prevents unauthorized connections to MCP servers (allowlist enforcement at the network/transport layer); the MCP server enforces tool-level authorization against the agent's token claims (allowlist enforcement at the application layer). Either layer alone is insufficient — the gateway prevents unauthorized connections; the server prevents unauthorized tool invocations within an authorized connection.
THE 12
PRINCIPLES
These principles extend human IAM discipline to the agent identity class. They are design rules, not aspirations — each has a direct control implication in the lifecycle and access model described above.
MODE CONTROL
MATRIX
| Control Dimension | Mode 1 — OBO | Mode 2 — Delegated | Mode 3 — Supervised | Mode 4 — Autonomous |
|---|---|---|---|---|
| Agent identity | Registered (attribution only) | First-class | First-class | First-class |
| Effective authorization | Human entitlements ∩ agent scope | Delegation grant ∩ agent scope | Agent's own, with gated actions | Pre-certified envelope; strictest scope |
| Human presence | Required (session) | Not required at runtime | Required for gated actions | None |
| Credential pattern | RFC 8693 token exchange; no standing entitlements | Scoped, grant-bound, time-boxed token from workload identity exchange | Workload identity → JIT vault-brokered; PAM for privileged paths | Workload identity → JIT vault-brokered; strictest scope; PAM pre-approved profiles |
| MCP authorization | Bounded by human's effective scope at token issuance | Bounded by delegation grant scope; grant expiry revokes MCP access | Agent's declared MCP scope; high-impact tool calls require in-session approval | Strictest declared MCP scope; no runtime expansion; manifest changes trigger re-approval |
| PAM integration | Minimal — human's PAM session applies | PAM checkout for any privileged operations within the grant | PAM with API-level session recording; human approves privileged invocations | Pre-approved PAM profiles mandatory; API-level recording; full audit required |
| Accountability | Initiating human user | Delegator + agent owner | Approving human per action + agent owner | Accountable executive + agent owner |
| Approval authority | Standard access model | Delegator within their own rights | Governance + in-session approvals | Governance body (highest bar); accountable executive sign-off required |
| Recertification emphasis | Human's access review via existing IGA | Grant validity + scope appropriateness | Gate effectiveness + entitlement + MCP scope review | Behavioral envelope + drift analysis + kill-switch test + MCP manifest review |
| Default risk posture | Lowest incremental risk | Medium | Medium | Highest; reversibility required or risk formally accepted by governance body |
GOVERNANCE
STRUCTURE
Every agent must have a named individual in each of the following roles at all times. An agent without an accountable owner or executive is in violation of this framework regardless of its operational status.
WHERE TO
START
The full framework is the destination. The right starting point depends on where you are. If agents are already in production with no formal identity program, prioritize inventory and containment first. If you are in the design phase, build the registry and mode classification before touching credentials.
Regulators examining AI governance will ask: For any agent action that caused a loss or control failure — who authorized it, what was the agent supposed to be able to do, and how quickly could you have stopped it? If you cannot answer those three questions from your registry, audit logs, and kill-switch documentation within minutes of being asked, your framework is incomplete regardless of how sophisticated the architecture looks on paper.