Enterprise IAM for Autonomous AI Agents: Adequate Foundations, Incomplete Control

Review period: Through September 23, 2026; no fixed start date, because foundational standards are included. Scope: Enterprise controls for production-access AI agents, starting with the September 2026 Blueprint Alliance and comparing identity protocols, vendor approaches and unresolved security gaps. Source policy: Primary standards, government guidance and vendor documentation prioritized; announcements distinguished from documented availability and independent validation.

Executive summary

Existing IAM is necessary, but conventional login-centric IAM is not sufficient for autonomous agents. The evidence supports extending modern identity infrastructure—not replacing OAuth, workload identity or enterprise directories with an entirely new identity system. NIST explicitly identifies existing authorization and workload-identity standards as useful foundations for agent deployments. The missing work is integrating those foundations with task-specific authority, tool-level enforcement, delegation, execution isolation and reliable containment. (nist.gov)

The Blueprint Alliance, announced on September 22, 2026, is a useful architectural coordination effort. It is not proof that its members already provide an interoperable, production-ready implementation of every control. Its reference architecture acknowledges that comprehensive multi-hop delegation remains aspirational. (okta.com)

Assessment: Enterprises can deploy bounded agents with production access today when enforceable controls constrain what they can do even after a prompt-injection or reasoning failure. They should not approve broad, unattended access merely because an agent has an identity, uses OAuth, connects through MCP, or appears in a governance dashboard. Model defenses themselves cannot guarantee containment. (anthropic.com)

The decisive procurement and deployment question is: Can the enterprise demonstrate, at the actual resource, who authorized this specific action, why it was permitted, and how further actions would be stopped?

1. What the Blueprint Alliance establishes—and what it does not

The founding membership includes the companies in the question—Okta, AWS, Google Cloud, CrowdStrike, Databricks, Docker, Salesforce, ServiceNow, Wiz, Proofpoint and Zscaler—plus Lovable. The September initiative expands a blueprint first introduced in March 2026. Its stated objectives cover agent discovery, accountable identity, scoped access, traceable delegation, runtime monitoring and containment. (okta.com)

The substantive reference architecture is more qualified than a simple claim that traditional IAM has become obsolete. It describes task-specific dynamic grants as an architectural goal, while recognizing practical combinations of short-lived grants and baseline permissions. It also explicitly acknowledges that end-to-end, multi-hop delegation is not yet comprehensively supported by current tooling. (okta.com)

Revoqra synthesis: The initiative is best understood as a shared reference architecture and integration agenda. It is not equivalent to a finalized wire protocol, an interoperability certification, or an independently demonstrated security outcome. Its value is identifying the control points vendors must connect; membership alone does not establish that those connections work across a customer's entire application estate. (okta.com)

A concrete example is Okta's own launch announcement: Agent SSO, Agent-to-Agent Connections and Resource Access Certifications were generally available, while Agent Gateway and endpoint shadow-agent discovery were listed for planned Q3 availability, and expanded runtime Kill Switch capabilities for Q4—using Okta's quarter labels. Announced capabilities must therefore be separated from available ones. (okta.com)

2. Is the problem inadequate IAM—or inadequate deployment of IAM?

The strongest argument for reusing existing architecture

OAuth already supports delegated authorization; token exchange can distinguish the subject from the acting party; SPIFFE/SPIRE can identify and attest workloads; policy engines can authorize individual requests; and revocation, introspection and shared security signals already exist. An IETF agent-authentication draft deliberately builds on these mechanisms rather than proposing an entirely new protocol. (rfc-editor.org)

NIST's August 2026 analysis identifies credential sharing, static credentials and weak accountability as recurring identity-security failures—not problems uniquely created by AI. It recommends treating agents as identifiable entities and applying established identity practices. (nist.gov)

What changes with autonomous agents

The difficult change is that authority can be selected, combined and exercised dynamically. An agent can interpret untrusted material, choose tools, delegate work and continue an asynchronous workflow. Consequently, deciding that a client may access an application does not settle whether a particular tool call, argument, recipient or sequence of actions is legitimate. The OpenID Foundation distinguishes authorization primitives from enforcement architecture and the trust relationships governing issuers, tools and metadata. (openid.net)

Assessment by architecture:

• Shared service account or borrowed human session: unsuitable as the default for production agents because accountability and privilege boundaries are blurred. (nist.gov)
• Per-agent OAuth identity with static broad scopes: improves attribution, but does not by itself constrain task-specific behavior. Richer authorization and resource-side policy remain necessary. (rfc-editor.org)
• Modern workload identity plus non-bypassable, resource-aware authorization and isolated execution: a viable foundation for bounded production use. This is an architectural assessment, supported by documented gateway-policy and containment implementations—not a guarantee for every configuration. (docs.aws.amazon.com)

The right dividing line is therefore not simply old IAM versus agent-native IAM. It is authentication-only integration versus enforceable control over execution.

3. What the architecture must control

The requirements below are Revoqra recommendations, informed by the cited standards and implementations. They are not claims that every vendor already supplies them.

3.1 Agent identity: identify the workload, its owner and its execution

A production identity model should distinguish:

1. Agent definition: approved software, model/configuration, tool set and intended purpose.
2. Deployed agent principal: the security identity granted access.
3. Execution or task: a particular run, with its initiating authority and bounded objective.
4. Sub-agent: a separately identifiable principal or execution context when it has distinct authority or isolation requirements.

Do not assume one permanent directory object is required for every model invocation. What matters is an authenticated mapping from the actual executing workload to its approved principal, plus attributable task and delegation records. SPIRE's workload attestation and Microsoft's blueprint-to-agent identity model illustrate different ways to separate workload instances from administrative identity templates. (spiffe.io)

Required ownership: assign an accountable human owner or operational team, lifecycle dates, environment and permitted purpose. Reassignment, employee departure and agent retirement must trigger access review rather than leave an orphaned automation running indefinitely. Microsoft's production guidance explicitly calls for validating sponsors, permissions and applicable policies before release. (learn.microsoft.com)

3.2 Authentication: credentials should prove the workload—not merely be available to it

Prefer managed workload credentials, federation, short-lived certificates or asymmetric client authentication over embedded secrets. Use sender-constrained tokens, such as DPoP-bound tokens, where the complete client/server path supports them. OAuth's security BCP and DPoP specification address token theft and replay; these mechanisms remain relevant to agents. (rfc-editor.org)

Two distinctions matter:

• An access token is not necessarily proof of the particular agent instance presenting it. A bearer credential can be used by another holder.
• Proof of possession is not proof of benevolent behavior. If the authorized runtime itself is manipulated, binding a token to that runtime does not stop it from making harmful permitted requests. DPoP's security properties should not be confused with semantic authorization. (rfc-editor.org)

Human authentication belongs at delegation and approval boundaries. An unattended agent should not automate a person's MFA ceremony or reuse their browser session; it should authenticate as a workload under explicitly granted authority. The agent-authentication draft separates user approval from the agent's subsequent client authentication. (ietf.org)

3.3 Authorization: enforce task boundaries outside the model

A useful design rule is:

Effective permission = agent ceiling ∩ valid task grant ∩ resource policy ∩ current contextual restrictions.

For user-delegated work, the user's permitted authority is an additional ceiling. For service-owned automation, the source of authority is an approved operational policy, not a fictitious logged-in user. OAuth recognizes both delegated and client-owned authorization patterns. (ietf.org)

The enforcement point should evaluate, where relevant:

• The specific tool and operation—not just access to the server.
• Resource, tenant, row, object and field boundaries.
• Parameters such as recipient, destination, amount and environment.
• Cumulative limits, workflow state and separation of duties.
• Whether an approval covers the exact pending action.

These are proposed implementation requirements. Existing building blocks include structured authorization requests and gateway policies evaluated for each tool invocation; neither automatically supplies an enterprise's business rules. (rfc-editor.org)

Illustrative failure: an agent can be permitted to read customer records and send messages, yet misuse that combination to disclose records externally. Both individual calls may pass conventional access checks. Invariant's original research documents this class of dangerous tool combination and prompt-injection-driven data flow. (invariantlabs.ai)

3.4 Delegation and sub-agents: preserve authority, not just a trace

For a child agent, require a distinct attributable execution, a narrower or equal delegated grant, a bounded lifetime and limits on further delegation. Restrict delegation depth, fan-out and aggregate resource consumption. A child must not gain broader authority simply because it can invoke a more privileged helper. These are recommended controls against the propagation problems examined in current multi-agent authorization research. (arxiv.org)

A particularly important standards limitation is often overlooked: RFC 8693 supports nested actor history, but prior actors in nested act claims are informational, not inputs to the resource server's access-control decision under that specification. The current actor and top-level claims are what the consumer evaluates. A nested actor list therefore does not automatically enforce every ancestor's constraints. (rfc-editor.org)

Implementation consequence: the token issuer or a trusted delegation service must validate the relevant grants and mint appropriately narrowed authority. Logging “human → orchestrator → sub-agent” is not equivalent to enforcing that chain. Likewise, scope attenuation must survive token exchanges and changes of vendor or trust domain. (rfc-editor.org)

3.5 Short-lived credentials: reduce exposure without confusing expiry with containment

Use short-lived, audience-specific access tokens; protect refresh credentials; and re-evaluate whether the task remains authorized before renewal. OAuth's security BCP addresses refresh-token protection, while NIST finalized additional token-protection guidance on September 15, 2026. (rfc-editor.org)

There is no universal safe token lifetime for all agents. Recommendation: choose lifetimes according to the maximum harmful action possible before expiry, and provide a faster denial mechanism for sensitive operations. A credential valid for only a short time can still authorize an immediate bulk export or destructive command.

Prefer credential injection at a trusted broker or gateway so the model and its general-purpose execution environment do not receive reusable secrets. Where a legacy application only supports API keys, vault and rotate them, restrict their use through the broker, and explicitly record the remaining limitation. Google's documented gateway integration and Docker's credential-injection design illustrate this pattern. (docs.cloud.google.com)

3.6 MCP access: secure the protocol path and the actual tool

The current reviewed MCP specification is July 28, 2026. Its authorization profile concerns HTTP transports, uses OAuth-based mechanisms and protected-resource discovery, and does not apply the same flow to local STDIO servers. Authorization is optional at the overall protocol level; “MCP-compatible” therefore does not mean “enterprise-authorized.” (modelcontextprotocol.io)

For production use, require:

• Approved server identities and trusted discovery/registration paths.
• Correct issuer, audience, expiry and authorization validation.
• Separate downstream credentials rather than forwarding an inbound token to a different resource.
• Per-tool and resource-level authorization after authentication.
• Isolation and restricted filesystem, process and network privileges for local MCP servers.

MCP explicitly prohibits token passthrough and describes confused-deputy, SSRF and session-related risks. Authentication to a server does not validate the safety of its descriptions or outputs. (modelcontextprotocol.io)

The July profile prefers Client ID Metadata Documents and retains Dynamic Client Registration for backward compatibility. This is useful interoperability progress, but registration metadata should not be mistaken for independent evidence of trustworthy agent behavior. (modelcontextprotocol.io)

3.7 Cross-application access: centralize grants without erasing application policy

Okta's Cross App Access uses an Identity Assertion JWT Authorization Grant, or ID-JAG, to move enterprise-managed authorization between the identity provider and a resource application's authorization server. The resource application still issues its own access token. This is not a universal token that should be accepted unchanged by every application. (support.okta.com)

MCP's Enterprise-Managed Authorization extension became stable on June 18, 2026 and applies a related enterprise-IdP flow to MCP access. It reduces repeated per-server consent and centralizes administrative policy, but requires participating clients, authorization servers and resources. (blog.modelcontextprotocol.io)

Assessment: replacing repeated user consent with administrator policy can improve governance. It can also centralize an overly broad grant. Enterprises must still validate app-to-app scope mappings, tenant boundaries, target-side entitlements and the handling of already-issued tokens. A centralized grant decision is not the same as immediate distributed revocation. (datatracker.ietf.org)

3.8 Runtime monitoring and auditability: record the action, not just the login

Monitor actual tool calls and effects, including denied requests, suspicious data destinations, privilege changes, unexpected delegation, unusual volume and policy bypass attempts. Endpoint/process telemetry and network controls complement gateway visibility because agents can also act through shells, browsers and files. Anthropic's containment architecture explicitly separates model defenses from execution and network boundaries. (anthropic.com)

Recommended audit record: agent principal, owner, initiating user or service, task ID, parent/child relationship, tool/server version, action and resource, relevant argument digest, policy version and decision, approval reference, credential audience and expiry metadata, downstream request ID, outcome and containment events.

Do not log reusable secrets. Minimize sensitive prompt and response retention. Preserve execution evidence and resource-side outcomes rather than treating a model-written explanation as authoritative proof of intent. OpenID's agent-identity work emphasizes attribution, while MCP's security guidance explains how token misuse can corrupt the apparent identity in downstream logs. (openid.net)

Assessment: an IdP log proves an authentication or grant event; it is not automatically a complete record of what happened inside every downstream application. Require correlation across identity, gateway, runtime and resource logs.

3.9 Kill switches: stop effective authority, not merely new logins

A credible containment design needs several independently testable actions:

1. Stop new token issuance and renewal.
2. Deny use of existing credentials at gateways or resources.
3. Terminate relevant sessions and isolate execution/network access.
4. Stop child agents, scheduled jobs, queued actions and retries.
5. Preserve evidence and require controlled reauthorization before restart.

These are recommended response requirements, not a claim that one standardized API performs them all. OAuth revocation explicitly acknowledges propagation delays, and introspection caching trades freshness against performance. (rfc-editor.org)

OpenID Shared Signals and CAEP can communicate events such as session revocation across participating systems. They do not make every receiver enforce the event instantly, cancel an already-running business operation, or undo data already disclosed. (openid.net)

The practical distinction is visible in Okta's September announcement: the existing manual off switch blocks new sessions; the announced expansion targets active access at Agent Gateway. Enterprises should test these as separate capabilities. (okta.com)

Assessment: “instant and reversible containment” should describe control over further execution—not a promise that completed transactions or data disclosures are reversible.

4. Standards comparison: what each layer actually solves

Standards assessment: There is considerable convergence around existing identity primitives. The unsettled layer is the interoperable representation and enforcement of task authority, delegation constraints, workflow state and revocation across administrative boundaries. A protocol being open, or an implementation being available, does not establish that these properties survive a multi-vendor workflow. (datatracker.ietf.org)

5. Vendor approaches: complementary control points, not interchangeable solutions

The following compares documented mechanisms and announced scope. It is not an independent product effectiveness benchmark. Caveats in the final column are Revoqra assessments and procurement questions.

What the comparison implies

Revoqra synthesis: These approaches occupy different layers: identity issuance and lifecycle; credential brokerage; resource permissions; execution gateways; endpoint/network containment; and data or behavior analysis. A successful architecture composes them. Buying several overlapping dashboards without agreeing on identities, policy ownership, event semantics and enforcement paths does not establish end-to-end control. The OpenID Foundation's separation of primitives, enforcement and trust governance is a useful way to structure that integration. (openid.net)

Enterprises should prefer a small number of clearly authoritative policy and enforcement paths, while keeping resource systems responsible for their own permissions. This is a design recommendation—not an argument that one vendor should own every layer.

6. Unresolved security gaps

A. Valid credentials can authorize the wrong behavior

Prompt injection can redirect an otherwise legitimate agent through malicious documents, tool outputs or descriptions. Strong authentication does not remove this attack surface. Invariant's demonstrations and Anthropic's containment analysis support layered controls rather than reliance on model obedience. These are research and engineering observations, not estimates of enterprise incident prevalence. (invariantlabs.ai)

Remaining gap: natural-language intent cannot simply be converted into broad scopes and assumed preserved throughout execution. Use explicit transaction limits and approvals where the consequences matter.

B. Per-call authorization can miss harmful sequences

A series of individually permitted actions may exceed an aggregate budget, leak information assembled from several sources, or violate separation of duties. Current research identifies authorization propagation and temporal validity as workflow-level problems; AWS's session-aware policies show that vendors are beginning to address this layer. (arxiv.org)

Remaining gap: consistent workflow constraints across different vendors and independently issued credentials.

C. Identity and attestation do not establish behavioral trust

Attestation can establish that a workload meets configured identity conditions. It does not prove that its model, retrieved content or current plan is safe. Agent authentication and runtime containment solve different problems. (spiffe.io)

Remaining gap: tying approved code, configuration, tool changes and execution context to authorization without treating an agent's self-description as trustworthy evidence.

D. Credential brokers and gateways become high-value control points

Central brokerage can keep secrets out of agents, but it also concentrates authority to retrieve credentials or authorize requests. MCP's confused-deputy and token-passthrough analysis demonstrates why audience separation and caller validation matter at these boundaries. (modelcontextprotocol.io)

Remaining gap: proving that tenant isolation, administrative separation and bypass prevention remain correct across all connectors and failure modes.

E. Revocation does not compose automatically

Different applications can retain independent access tokens, refresh grants, sessions or queued work. Even standard revocation and introspection allow practical timing and caching trade-offs. (rfc-editor.org)

Remaining gap: a measurable, cross-provider guarantee that no descendant execution retains effective authority after containment.

F. Audit completeness is still an integration problem

Delegation history, identity events and tool traces do not necessarily prove which downstream data changed or which authorization decision covered it. RFC 8693 actor history is useful provenance, but not an automatically verified chain of business authority. (rfc-editor.org)

Remaining gap: trustworthy correlation and outcome evidence across applications, including browsers, legacy APIs and asynchronous jobs.

7. What enterprises actually need before production access

A minimum go/no-go baseline

The following is a recommended acceptance checklist, not a vendor certification or a universal compliance standard.

These recommendations combine established token-security and workload-identity practices with resource-level authorization and external containment. They do not require a proprietary agent identity protocol. (rfc-editor.org)

Risk-tier the autonomy, not just the model

Recommended deployment policy:

• Sensitive read access: permit only bounded retrieval and controlled destinations. Read-only access can still enable disclosure; test combinations of retrieval and outbound tools. (invariantlabs.ai)
• Reversible business writes: add constrained action schemas, transaction limits, idempotency, outcome verification and recovery procedures.
• Privileged or irreversible actions: retain independent approval, strict separation of duties and narrow execution windows until the entire enforcement and recovery path has been demonstrated.
• Unbounded administrative autonomy: do not approve on the basis of identity registration, a vendor alliance, or a model's measured refusal behavior.

The latter three bullets are Revoqra risk-management recommendations, not claims that a standards body mandates these exact categories.

Test failures, not only successful workflows

Before release, and after material changes, test:

• Malicious instructions in documents, tool results and tool descriptions.
• Wrong-audience, stolen, expired and replayed credentials.
• User departure, owner reassignment and task cancellation during execution.
• Child-agent privilege escalation and aggregate-limit evasion.
• Policy-engine, gateway and event-delivery outages.
• Attempts to bypass mediation through direct network or host access.
• A kill operation while downstream work is already running.

These tests follow the failure classes documented in MCP security guidance, OAuth security guidance and original agent-containment research. (modelcontextprotocol.io)

Measure: enforcement-path coverage, unexplained audit gaps, residual access after revocation, maximum observed containment delay, and the maximum irreversible effect possible before denial takes effect. These are proposed operational metrics, not research-derived industry benchmarks.

The practical approval rule

Do not grant production access unless the enterprise can both constrain the agent after it makes a bad decision and reconstruct what authority covered the action.

Bottom line: modern IAM supplies much of the necessary machinery. The Blueprint Alliance correctly broadens attention from identities and grants to execution and response. But the enterprise—not the alliance announcement—must demonstrate that every material production path is governed, attributable and stoppable. Where it cannot, reduce the agent's autonomy, narrow its access, or keep it outside production.

8. Evidence limitations and selected sources

This is a documentation and standards review, not a penetration test or a measured comparison of vendor effectiveness. Product documentation establishes described behavior and reported availability; it does not independently validate deployment quality, interoperability, detection accuracy or containment latency. No incident-prevalence estimates or comparative security-effectiveness percentages are inferred from vendor marketing or isolated demonstrations.

Selected primary sources; additional vendor-specific documentation is cited in the comparison table:

• Blueprint Alliance: September 22 announcement and the expanded Governing Agentic Execution reference architecture. (okta.com)
• NIST: August 2026 agent-identity analysis and September 2026 final token-protection guidance. (nist.gov)
• OpenID Foundation: agent-identity submission to NIST and final CAEP specification. (openid.net)
• OAuth foundations: RFC 9700, RFC 8693, RFC 9449 and RFC 9396. (rfc-editor.org)
• Revocation and freshness: RFC 7009 and RFC 7662. (rfc-editor.org)
• Emerging cross-domain standards: ID-JAG, identity chaining and Transaction Tokens drafts. (datatracker.ietf.org)
• MCP: July 28, 2026 authorization profile, security guidance and Enterprise-Managed Authorization release. (modelcontextprotocol.io)
• Workload and agent interoperability: SPIRE concepts and the A2A specification. (spiffe.io)
• Original security evidence: Invariant's tool-flow research and Anthropic's containment engineering analysis. (invariantlabs.ai)