Addressing what’s next in securing enterprise AI
April 20, 2026
April 2026
Last week at RSAC Conference 2026, Jason Clinton and I presented “Securing MCP: Mitigating New Threats in Agentic AI Deployments” to a packed room in Moscone West. We walked through twelve threat categories, nearly forty individual threats, and a set of controls spanning the full MCP stack — from transport-layer hygiene to supply chain governance.
But the slides weren’t the interesting part. The Q&A was.
When we opened the floor, the room didn’t ask about novel attack vectors, supply chain poisoning, or TEE-backed attestation. The questions converged — fast and repeatedly — on identity and authorization. Who is making this request? How do I know? What happens when an agent acts on behalf of a user across multiple hops?
That convergence told us something we’d suspected but hadn’t seen confirmed so viscerally: identity is the load-bearing wall of MCP security, and most production deployments haven’t poured the foundation yet.
The Architecture Makes the Problem
In a conventional application, a user authenticates and a request gets made. The identity of the caller is clear — boringly, blessedly clear. In an MCP-based agentic system, a user’s request may pass through an orchestrating agent, traverse one or more intermediate MCP servers, and finally reach a downstream tool or API. Each hop makes decisions on behalf of the original caller. Each hop is a potential confused deputy.
Traditional authentication answers “who are you?” MCP deployments need to answer a harder question: who authorized this action, through what chain, and with what scope?
Our Model Context Protocol (MCP) Security paper identifies this under MCP-T1: Improper Authentication and Identity Management. The architectural impact is not subtle: without proper identity tracing, MCP servers and endpoints cannot determine the provenance of a request. That opens the door to impersonation, replay attacks, and the confused deputy problem — which deserves its own section, because it came up so often.
The Confused Deputy: Not an Edge Case
The confused deputy attack happens when an MCP server acting as an OAuth proxy fails to properly validate authorization context. An attacker doesn’t steal credentials directly. Instead, they exploit the server’s intermediary role — manipulating it into using another user’s credentials to perform privileged operations.
This matters acutely in MCP because MCP servers are designed to be intermediaries. That’s the whole point. They sit between the AI client and the downstream resource, brokering access. If that server holds tokens and doesn’t enforce per-request authorization validation, the confused deputy isn’t an exotic attack — it’s a natural consequence of the architecture operating without adequate controls.
The MCP specification addresses this directly in its security best practices. Our paper’s recommendation is unambiguous: perform token exchange at every trust boundary. Never pass through tokens received from upstream callers. The Asana incident from May 2025 — where a tenant isolation flaw allowed cross-organization data contamination affecting up to 1,000 enterprises — was, at its root, this class of failure. The WordPress plugin CVE that same period was privilege escalation through improper authorization in an MCP implementation. These aren’t sophisticated attacks. They’re the predictable consequences of deploying MCP without rigorously applying identity and access control principles that the security industry has understood for decades.
What the Paper Recommends — and Where CoSAI Is Going Next
The full recommendations on identity live in Section 3.2.1 (Agent Identity) and Section 3.2.2 (Secure Delegation and Access Control) of the MCP Security paper. Here are the specifics that generated the most discussion at RSA, now updated with a pointer to where we’re taking this work.
Make every request traceable
All requests should be traceable across the entire execution chain — the end user or initiating agent, any intermediate MCP servers, and the tools or services that performed the resulting actions. Right now, most deployments have no equivalent of a call stack for authorization.
The emerging standard for workload-level identity is SPIFFE/SPIRE, which provides cryptographic workload identities. A SPIFFE ID can be carried through the execution chain as the subject or actor in token exchange flows, producing an auditable record of every hop. In our new Agentic Identity and Access Management paper (more on this below), we formalize this as the principle of treating agents as first-class identities — distinct from both human users and traditional service accounts, each receiving a unique identity bound to verifiable claims about their code, model, and runtime environment.
Never pass through OAuth tokens
This is the single most common mistake we’re seeing in production MCP deployments, and it came up directly in the post-talk Q&A.
When an MCP server receives a user’s OAuth token from an upstream client and passes it directly to a downstream service, that token can be used by anything in the chain to impersonate the original user. The downstream service has no way to distinguish a passed-through token from one legitimately obtained.
The CoSAI advice is unambiguous: do not pass through OAuth tokens provided by the user. Instead, perform token exchange with the authorization server using RFC 8693. This produces a new token scoped to the specific operation, with an auditable exchange record, and without exposing the original user token to downstream services. Our Agentic IAM paper takes this further: it specifies that delegation tokens should carry explicit actor and subject claims so the chain of custody remains visible, and that scope must narrow at each hop — never expand beyond the delegating principal’s effective permissions.
Reduce scope to the minimum required
MCP servers commonly request and receive overly broad permission scopes to maximize flexibility. This is understandable from an engineering convenience standpoint. It is also the kind of shortcut that turns a minor misconfiguration into a breach.
The paper recommends scoping tokens to exactly the operations required. The June 2025 MCP specification revision (via SEP-835) adds native support for defining scopes at the tool level. Use it. Remove write scopes when only read access is required. Use Rich Authorization Requests (RFC 9396) to limit tokens to specific resources or tool parameters, not just broad capability categories.
The Agentic IAM paper introduces a capability–risk classification matrix that maps the strength of required controls to the intersection of agent capability and resource sensitivity. A low-capability agent querying a public FAQ might need only a narrowly scoped service account. A high-capability agent processing invoices and triggering payments needs the full apparatus: ephemeral identities, OBO delegation, token exchange, ABAC/PBAC policies, continuous evaluation, and human-in-the-loop for irreversible actions. The controls scale with the stakes — which is how security should work, but rarely does when teams bolt on agents as an afterthought.
Use short-lived tokens with proof-of-possession
Long-lived tokens in multi-agent systems are a compounding risk. A stolen token in a conventional application has a bounded blast radius. In an agentic system where that token may traverse multiple servers and authorize a chain of operations, the exposure is geometrically wider.
The paper recommends short-lived tokens combined with DPoP (Demonstrating Proof of Possession, RFC 9449). DPoP cryptographically binds a token to the client that requested it, preventing replay attacks even if the token is intercepted. The Agentic IAM paper codifies this as the principle of Zero Standing Privilege: no long-lived credentials should exist. All access is provisioned just-in-time, task-scoped, and revocable.
Use your existing identity infrastructure
You do not need to build a new identity system for MCP.
The paper’s recommendation is to leverage existing identity providers and authenticate users using standards such as OIDC. Register MCP servers as OAuth clients with your IAM provider. If registration can’t happen statically, use Dynamic Client Registration. The goal is to make MCP servers first-class participants in your existing identity architecture — not to build a parallel stack.
The Agentic IAM paper makes this a core principle: reuse existing IAM as the control plane. Identity stores become agent registries by adding schemas for non-human principals. PKI issues certificates bound to agents and execution environments. OAuth/OIDC servers gain token exchange and OBO flows. RBAC is augmented with ABAC/PBAC policies that evaluate intent, context, and risk signals. The structural foundations remain; the work is enriching them with agent-specific semantics. If you’re starting from scratch, something has gone wrong.
On Access Control: Policy Languages That Aren’t Your Application Code
Identity tells you who is asking. Access control tells you what they’re allowed to do. Both came up at RSA, and they are related but distinct.
MCP-T2: Missing or Improper Access Control covers the absence of authorization mechanisms and the failure to enforce object-level permissions. The protocol lacks native support for fine-grained authorization checks — this is an implementation responsibility, not something the spec handles for you.
The paper recommends implementing robust access control models — role-based (RBAC) or attribute-based (ABAC) — and evaluating those models against claims made by the identity provider. Generic “authenticated” checks are insufficient for agentic systems that may be executing consequential operations on behalf of users.
For organizations that need flexible, auditable policy evaluation, the paper points to Open Policy Agent (OPA), Cedar, and OpenFGA as policy languages designed for exactly this use case. These provide external, auditable, version-controlled authorization logic rather than embedding access control decisions in application code — where they inevitably become invisible, untestable, and unreviewable.
The Agentic IAM paper formalizes the enforcement model: policy must be evaluated at every hop and at the last mile, not only at the perimeter gateway. MCP servers, API gateways, and service meshes should terminate agent tokens, evaluate policies per request, and forward only scoped OBO credentials downstream. Decisions must be recorded in immutable logs. For high-capability agents, enforcement gateways must fail closed — with a defined degradation path, such as reverting to human-in-the-loop mode or halting agent execution entirely.
The Agentic IAM Paper: What It Is and Why It Matters
The questions at RSA confirmed what our workstream had already concluded: identity and access control for agents deserves its own dedicated treatment. The MCP Security paper covers it in two sections. The new work gives the problem of identity a dedicated treatment.
Agentic Identity and Access Management was approved by the CoSAI Technical Steering Committee on March 20, 2026. It defines how to represent, authenticate, authorize, and govern AI agents as verifiable, auditable identities — with lifecycle management, context-aware controls, and risk-based enforcement comparable to what we apply to human and service identities.
The paper starts from a blunt premise: traditional IAM was built for long-lived human principals with coarse roles and “authenticate once, trust for the session” semantics. None of that holds for composable, autonomous agents whose behavior and security context change rapidly. Agents are ephemeral, task-bounded, and non-deterministic. They may be fully non-interactive for authentication and are often embedded in multi-hop delegation chains. Treating them as slightly unusual service accounts is an invitation to the failure scenarios we documented — over-privileged financial agents, data-exfiltrating support agents, shadow devops helpers operating under shared credentials with ambiguous logs.
The paper lays out nine core principles (what we’re calling the agentic identity imperatives), a phased adoption model that starts with visibility and progresses to full continuous evaluation, and an end-to-end example — an invoice-processing agent — that shows what “good” looks like across identity assignment, delegation, authorization, logging, and incident response. The appendices include reference patterns for token structures, attestation flows, policy rules, logging schemas, and gateway enforcement.
It’s designed to be immediately actionable against your existing IAM infrastructure. Phase 1 is: discover and register all agents as identities, eliminate shared accounts, and establish immutable action logging. If you’re deploying agents today and haven’t done that, start there.
Read the Papers
MCP Security paper — twelve threat categories, deployment pattern guidance, and the full set of controls and mitigations:
Agentic Identity and Access Management paper — dedicated treatment of identity, delegation, access control, lifecycle, and governance for autonomous agents:
Both were produced by CoSAI Workstream 4 with contributions from security practitioners at Anthropic, Google, IBM, Intel, NVIDIA, Cisco, Dell, Red Hat, Amazon, PayPal, ServiceNow, Wiz, Palo Alto Networks, Meta, Trend Micro, EQTY Lab, and Adversa AI.
If you’re working on MCP security — whether you’ve hit incidents, built defenses, or are working on tooling — CoSAI is the right place to bring that work. This is an open project and we welcome contributors. The threat landscape is evolving at least as fast as the protocol itself.
This post was written by the CoSAI Workstream 4 team: Secure Design Patterns for Agentic Systems. The views expressed are those of the authors.
