A Practitioner's Risk Framework for the Enterprise
Mar 24th, 2026
Chief Technology Officer
Key Takeaways
- Traditional service accounts and API keys are insufficient for AI agents; use cryptographically verifiable workload identities such as SPIFFE/SPIRE.
- OAuth 2.1 On-Behalf-Of (OBO) flows are the correct delegation model, never allowing agents to impersonate users directly.
- Secure MCP deployments by decoupling the Policy Decision Point from the Policy Enforcement Point, and disabling open Dynamic Client Registration.
- Align governance with ISO/IEC 42001 and enforce real-time guardrails including PII masking and Human-in-the-Loop (HITL) via CIBA.
- Recursive delegation chains require scope attenuation via OAuth 2.0 Token Exchange or Macaroon-style capability tokens.
This guide is for enterprise security architects, IAM engineers, and CISOs who are deploying or evaluating agentic AI systems and need a structured, standards-aligned risk framework — not a vendor pitch.
The rapid rise of agentic AI is forcing a structural phase shift in how enterprises govern access, identity, and authorization. Unlike traditional software that executes deterministic logic against structured inputs, AI agents exhibit flexible, goal-directed behavior — autonomously invoking APIs, querying data stores, spawning sub-agents, and persisting state across sessions.
According to Hype Cycle for Artificial Intelligence, 2024, more than 15% of day-to-day work decisions will be made autonomously by AI agents by 2028. Existing Identity and Access Management (IAM) architectures were not designed for this operating model, and the gap is exploitable.
The framework below spans four pillars: machine identity, connectivity architecture, operational governance, and recursive delegation
Why Traditional IAM Breaks Under Agentic AI
Classic IAM assumes a human at one end of every access chain. Service accounts and API keys were designed as static, long-lived credentials for predictable, bounded workloads. AI agents violate every one of those assumptions.
An agent acts on behalf of a human principal but executes at machine speed — potentially invoking hundreds of API calls in a single session. A compromised service account tied to a human user creates a blast radius proportional to that user’s permissions, multiplied by the agent’s execution velocity. IBM’s 2024 Cost of a Data Breach Report found that credentials were the most common initial attack vector, responsible for 16% of breaches at an average cost of $4.81 million per incident. In an agentic context, a single stolen credential can trigger cascading downstream actions before any human detects the anomaly.
The problem is structural, not operational. Patching service account hygiene is insufficient; the identity model itself must evolve.
Machine Identity: Beyond Service Accounts
Verifiable Workload Identities with SPIFFE/SPIRE
Agents require identities that encode what they are, not just who issued the credential. The https://spiffe.io/ standard, a graduated CNCF project, provides cryptographically verifiable workload identities via short-lived X.509 SVIDs (SPIFFE Verifiable Identity Documents). Critically, a SPIFFE identity can be enriched with metadata: the underlying model name, version, capability scope, and the human principal on whose behalf the agent is operating. This metadata enables policy engines to make fine-grained authorization decisions that static API keys cannot support. Other standards and technologies can provide similar capabilities; both Cloud Vendors and IAM vendors offer Workload Identities that may be suitable for your needs, SPIFFE is mentioned because it can be deployed everywhere and provide a clean reference implementation.
From Impersonation to Delegation via OAuth 2.1
The most dangerous anti-pattern in agentic deployments is user impersonation: giving an agent a cloned user token and allowing it to act as that user. This destroys the audit trail; log records that will show the human user taking actions the human never performed.
The correct pattern is On-Behalf-Of (OBO) delegation, standardized in https://oauth.net/2.1/ (which consolidates RFC 6749, RFC 6750, and the Security BCP). An OBO flow issues a derived access token that carries two identifiers: the originating human principal and the specific agent instance. Every downstream system sees both actors in every request, preserving a complete, non-repudiable audit trail.
Automated Lifecycle Management via SCIM
In enterprises with hundreds of deployed agents, manual credential rotation is not operationally viable. Organizations should extend https://www.rfc-editor.org/rfc/rfc7644 to provision and de-provision agent identities alongside human identities.
This provides two critical capabilities:
- Automated provisioning: New agent deployments receive scoped credentials without human intervention.
- Instant kill switch: A single SCIM DELETE operation immediately de-provisions a compromised agent and purges its delegated access across all integrated systems; equivalent to disabling a user account in seconds rather than hours.
Once again, Identity Security vendors offer Agent Lifecycle to achieve the same results, leveraging open protocols like SCIM makes implementation faster and more flexible.
Architecture: Securing the Model Context Protocol
The MCP Protocol, introduced by Anthropic in late 2024, is rapidly becoming the standard interface for connecting AI models to external tools and data sources. Analogous to USB-C for hardware, MCP provides a uniform protocol layer; which also means a uniform attack surface if misconfigured.
Decouple the PDP from the PEP
The most common architectural mistake is embedding authorization logic directly inside the MCP server. This creates brittle, duplicated policy logic that is difficult to audit and impossible to enforce consistently across multiple servers.
The correct architecture decouples the Policy Decision Point (PDP) which evaluates access rules — from the Policy Enforcement Point (PEP) — which intercepts requests. An API gateway, a security middleware layer or the MCP Server itself acts as the PEP, intercepting every agent request. The PEP calls out to a centralized PDP for an authorization decision. This pattern is consistent with Zero Trust Architecture principles.
Eliminate Token Passthrough
A critical and underappreciated vulnerability is Token Passthrough: an MCP server receives a user’s access token and forwards it unmodified to a downstream API. This creates a Confused Deputy vulnerability — the downstream API cannot distinguish whether the request originates from the user directly or from an agent acting on their behalf.
MCP servers must never forward a client-issued token; they must either use a token explicitly scoped to the server’s own service identity, or initiate a distinct OBO exchange to obtain a narrowly scoped derived token
Disable Open Dynamic Client Registration
Oauth Dynamic Client Registration allows clients to register themselves programmatically. In consumer contexts this is useful; in enterprise environments it is dangerous. Open DCR creates unapproved “anonymous clients”; agents or integrations that bypass the organization’s review and approval process, creating ungoverned shadow IT with full OAuth credentials.
Enterprise deployments must disable open DCR and adopt Enterprise Managed Authorization: administrators pre-configure and approve all trusted agent connections within the Identity Provider before any agent may request tokens.
Alternatively, to minimize operation overhead, clients may leverage “Software Statements” anchored to a Workload identity solution such as SPIFFE to create a trust between the IDP and the Workload Identity Solution.
Secure Local MCP Connections
Local MCP servers run as operating system processes under the host user’s security context, meaning they inherit full filesystem and network access of the logged-in user.
Developers must prefer STDIO or Unix domain sockets for local IPC over TCP/IP network sockets; the latter expose the server to all processes on the local network segment, including other containers and virtual machines. For production deployments, local MCP servers should run inside isolated execution environments (e.g., containers with restricted seccomp profiles).
Governance and AI Guardrails
Aligning with ISO/IEC 42001
ISO/IEC 42001, published in November 2023, is the first international management system standard specifically for AI. It requires organizations to establish documented processes for assessing the impact of AI systems on individuals, groups, and broader society; throughout the entire lifecycle, from design through decommissioning.
Practitioners should map their agentic AI risk assessments directly to ISO/IEC 42001 Clause 6 (Planning) and Clause 8 (Operation) requirements, ensuring that fairness, transparency, safety, and security are formally evaluated and recorded before any agent is deployed to production.
Real-Time Guardrails at the PEP
Governance cannot be purely procedural; it must be enforced programmatically at runtime.
The Policy Enforcement Point described in Section 3 is the correct location for real-time guardrails:
-
PII maskingIntercept and redact personally identifiable information before it is forwarded to any LLM invocation, preventing inadvertent model training on sensitive data.
-
Rate and budget limitsEnforce per-agent API rate limits and token budgets to contain costs and detect anomalous usage patterns.
-
Output filteringScreen agent responses for sensitive data exfiltration before results are returned to the requesting user or downstream system.
Alternatively, the guardrails can be implemented when invoking the LLMs, as it may be acceptable for PII to reach the MCP server, but not the AI Models.
Human-in-the-Loop via CIBA
For high-risk or irreversible actions (wire transfers, bulk data deletions, external communications) autonomous agent execution must be interrupted for human approval.
CIBA provides a standardized mechanism: the agent submits a backchannel authentication request to the authorization server, which pushes an out-of-band approval prompt to the user’s registered trusted device (mobile push notification, SMS, authenticator app).
The agent’s action is blocked until an explicit approval signal is received. MCP’s “URL mode” elicitation mechanism offers a complementary in-band pattern for interactive approvals within the agent session itself.
Recursive Delegation at Scale
The Sub-Agent Orchestration Problem
Production agentic systems rarely consist of a single agent. A planning agent will decompose a complex task and delegate sub-tasks to specialized agents — a research agent, a writing agent, a data retrieval agent — each of which may in turn spawn further sub-agents. This creates a recursive delegation chain where authority flows downstream through multiple hops.
The security risk is privilege escalation through delegation: if each sub-agent inherits the full permissions of its parent, a vulnerability anywhere in the chain can yield the orchestrator’s maximum permissions.
Scope Attenuation via Token Exchange
The solution is scope attenuation: each delegation hop must reduce, never expand, the permission scope. https://www.rfc-editor.org/rfc/rfc8693 provides the mechanism — a parent agent requests a derived token scoped to exactly the permissions the sub-agent requires for its specific sub-task, and no more.
The authorization server enforces the constraint that derived tokens cannot exceed the scope of the presenting token. No sub-agent can elevate its own authority.
For offline or asynchronous scenarios where the authorization server is not reachable at delegation time, Macaroon-style capability tokens offer an alternative: bearer tokens with embedded, unforgeable attenuation caveats that can be added locally without a network round-trip, while remaining cryptographically verifiable by any relying party.
Implementation Checklist
Machine Identity
-
Deploy SPIFFE/SPIRE or equivalent for workload identity; enrich SVIDs with model metadata
-
Replace user-impersonation patterns with OAuth 2.1 OBO flows
-
Extend SCIM to cover agent identity lifecycle (provision, rotate, deprovision)
-
Document kill-switch procedure: SCIM DELETE → access revocation SLA < 60 seconds
MCP Architecture
-
Place an API gateway/PEP in front of all MCP server endpoints or have MCP Server act as PEP
-
Centralize policy in OPA or equivalent PDP; remove inline authorization from MCP servers
-
Audit all MCP servers for Token Passthrough — eliminate any direct client token forwarding
-
Disable open DCR in all OAuth Authorization Servers; switch to pre-registered clients
-
Restrict local MCP servers to STDIO/Unix sockets; containerize with minimal privileges
Governance
-
Complete ISO/IEC 42001 Clause 6/8 impact assessment for each agent deployment
-
Implement PII masking at the PEP before any LLM invocation
-
Define per-agent rate limits, token budgets, and alert thresholds
-
Configure CIBA or MCP elicitation for all irreversible agent actions
-
Schedule quarterly agent identity and permission audits
Delegation
-
Adopt RFC 8693 Token Exchange for all sub-agent delegation chains
-
Enforce scope attenuation: derived token scope ⊆ parent token scope (enforced at AS)
-
Evaluate Macaroon-based capability tokens for offline or edge delegation scenarios
FAQs
The framework provided above addresses the structural and architectural changes required for agentic AI security. To provide quick clarity on common concerns and best-practice rationales, the following section answers frequently asked questions from practitioners in the field.
What is the difference between agentic AI security and traditional IAM?
Answer: Traditional IAM governs human users and static service accounts with predictable, bounded access patterns. Agentic AI security extends IAM to non-deterministic, goal-directed machine actors that can invoke thousands of API calls per session, spawn sub-agents, and act across multiple trust boundaries simultaneously; requiring verifiable workload identities, delegation chains, and real-time behavioral guardrails that classical IAM tooling does not provide.
Why can't AI agents simply use existing service accounts?
Answer: Service accounts use static, long-lived credentials that cannot encode the agent’s model version, capability scope, or the human principal being represented. This eliminates auditability — you cannot tell from an access log which human authorized the agent action, which model version executed it, or whether the scope was appropriate for the task. Static credentials also cannot be attenuated across delegation chains, creating privilege escalation risks.
What is Token Passthrough and why is it dangerous?
Answer:Token Passthrough occurs when an MCP server receives a user’s access token and forwards it unmodified to a downstream API. The downstream API sees the user’s full identity and permissions, creating a Confused Deputy vulnerability where the agent can act with the user’s maximum authority rather than a narrowly scoped delegated authority. Downstream systems also lose visibility into which agent intermediary was involved in the request.
How does CIBA enable Human-in-the-Loop for AI agents?
Answer: CIBA (Client Initiated Backchannel Authentication) allows an agent to trigger an out-of-band authentication or approval request to the user’s trusted device — a mobile push notification, for example — without interrupting the user’s current browser or application session. The agent’s action is blocked until the user explicitly approves or denies it via their trusted device, ensuring irreversible actions receive human confirmation before execution.
Is OAuth 2.1 production-ready for enterprise deployment?
Answer: OAuth 2.1 consolidates the security best current practices from RFC 6749, RFC 6750, RFC 7636 (PKCE), and the OAuth Security BCP (RFC 9700). It is not a new protocol but a rationalization of existing standards. Major IdPs including Microsoft Entra ID, Okta, PingOne and Auth0 have implemented its key requirements. Enterprises can adopt OAuth 2.1 patterns incrementally alongside existing OAuth 2.0 deployments.
Conclusion: Extend, Don’t Replace
The shift to agentic AI does not require discarding a decade of enterprise IAM investment. The same Identity Providers, OAuth authorization servers, SCIM directories, and policy engines that govern human access today are the right foundation — extended with workload identity standards (SPIFFE/SPIRE or similar), delegation protocols (OAuth 2.1 OBO, RFC 8693 Token Exchange), MCP-aware policy enforcement, and ISO/IEC 42001 governance processes.
Organizations that treat agentic AI security as a greenfield problem will build fragmented, unmaintainable controls. Those that extend their existing IAM infrastructure with the four pillars above will reach production-ready, compliant agentic deployments faster and with a defensible audit trail.