Zero Trust for AI Systems: Why Authorization Can’t Live Inside the Model
September 16, 2026
September 2026
After we presented the Model Context Protocol (MCP) Security paper at RSAC 2026, we wrote about the questions we kept getting. Most reduced to identity and authorization, and specifically to delegation: when an agent acts on a user’s behalf across five hops instead of one, what does the fifth server know about who is asking?
Version 1.0 catalogued twelve threat categories and thirty-four individual threats, with controls and mitigations for each. It answered what can go wrong and why. The question security teams asked next was narrower: how much of this applies to my deployment, and how do I know when I have done enough?
Version 2.0, published August 12, 2026, addresses that question. It also updates the paper in sync with the latest protocol changes. The 2026-07-28 MCP release made several significant changes, such as removing protocol-level sessions entirely, so a good deal of what the industry has spent the past year calling “MCP session security” needs to be rethought rather than patched.
Security Assurance Profiles
The gap in v1 was proportionality. A flat list of controls says nothing about whether a local prototype and a production multi-tenant platform should be held to the same bar, and holding them to one bar fails in both directions: experiments stall under compliance overhead, and production systems under-invest because nothing in the document told them to do more.
Section 3.3 defines four assurance levels. The numbering follows the SLSA convention: higher is stronger, and each level is cumulative.
- Level 1 (Sandbox) — local development and single-user experiments. No production credentials, no live data, recoverable failures.
- Level 2 (Internal) — team-shared and staging environments with authenticated users and moderate blast radius.
- Level 3 (Production) — production workloads handling sensitive or business-critical data, with an active threat surface and full auditability expected.
- Level 4 (Regulated) — multi-tenant platforms and adversarial environments, assuming active adversaries and carrying regulatory audit obligations.
Each level is specified as concrete MUST/SHOULD requirements across eight security dimensions: identity and authentication, authorization and delegation, transport and network security, isolation and sandboxing, logging and observability, supply chain and lifecycle, tool/input/output integrity, and state and discovery security. Every row in every table maps back to the MCP-T1 through MCP-T12 threat categories and cross-references the OWASP MCP Top 10, so any control traces to the threat it closes.
Three edges catch people scoping a project against this:
- Token binding is a hard requirement at Level 3. Without sender-constrained tokens (DPoP or mTLS), a compromised agent context or task handle can be replayed against downstream services, which defeats the guarantee Level 3 is meant to carry.
- Level 1 means data isolation. It does not require container-grade sandboxing, but it does prohibit production credentials and live data. A prototype that touches real credentials is miscategorized.
- Deployment pattern does not set the level. A purely local, stdio-based deployment (Deployment Pattern 1) that processes regulated health data should target Level 3 regardless of its network topology. Level follows data sensitivity and blast radius, not where the server runs.
For Level 3 and Level 4, the paper recommends centralizing enforcement in a dedicated agent gateway (token validation, policy evaluation, workload identity exchange, audit logging) rather than distributing that logic across every individual MCP server. That matches where our Agentic Identity and Access Management paper landed on enforcement architecture; the two are best read together.
Sessions Are Gone
The 2026-07-28 release removes an assumption the ecosystem had been building on, v1 of our own paper included: that MCP connections are dedicated, stateful sessions. The initialize/initialized handshake and the Mcp-Session-Id header are removed for new implementations. Every request is self-contained, carrying protocol version, client identity, and client capabilities in _meta, and can route to any compatible server instance. Horizontal scaling gets easier. Anywhere your team was leaning on a hidden session state for security, even implicitly, that footing no longer exists.
State is now explicit, and the paper separates three kinds, because each takes a different control:
- Server-held references (task IDs, continuation handles). The server mints these and they carry no meaning to the client. They must be unguessable, tenant- and lifetime-scoped, revocable, and logged.
- Client-held sealed state (requestState and similar). Sealed by the server, carried by the client, opaque to it. It needs integrity protection (HMAC or AEAD) and must be rejected on verification failure, since the server keeps no copy to revoke.
- Named references (resource URIs, tool parameters). Stable and predictable by design, so unguessability does not work here. Authorization has to be checked on every read, because naming a resource is not entitlement to it.
The task handle is designed to function as context (a locator for durable state), and the spec’s Auth binding requirement presumes authorization is established independently of it. While not prohibited by the spec, the task handle should not be confused as an authorization bearer token.
Other changes that affect anyone operating or building against MCP today:
- server/discover replaces the initialization handshake as the discovery mechanism for protocol versions, server identity, and capabilities.
- Identity and capability claims arriving in _meta are self-reported by the caller, and therefore untrusted input. Servers must reconcile them against the principal established by the access token, mTLS certificate, or workload identity, and treat a mismatch as a security-relevant failure, failing closed.
- A formal Extensions Framework now governs optional protocol capabilities: reverse-DNS identifiers, independent versioning, a dedicated review track. Manage it like any other protocol dependency, with ownership, version pinning, security review, and explicit approval before a client or server advertises support.
- MCP Apps (server-rendered HTML UI) should be treated as untrusted content even from an approved server: sandboxed iframes, CSP, postMessage validation.
- Tasks formalizes what was an experimental async pattern, with tasks/get, tasks/update, and tasks/cancel replacing the old model. Task handles need the same tenant-scoping and TTL discipline as any other durable execution reference.
- Roots, Sampling, and protocol-level Logging are deprecated. They work during the transition window, but new systems should use tool parameters or server configuration in place of Roots, direct LLM provider integration in place of Sampling, and stderr or OpenTelemetry with a standard schema such as OCSF in place of protocol Logging.
If you run a gateway or proxy that has to serve both old and new clients through the migration window, Section 3.2.12 is the one to read. A server accepting both models runs two authorization paths at once, and the legacy path still needs per-request authorization, not only the check at initialize.
What Carried Over from v1
None of this replaces v1. The twelve threat categories and thirty-four threats remain the backbone of the paper, from identity spoofing and confused-deputy attacks through tool poisoning, resource content poisoning, and shadow MCP servers. They are still anchored in real incidents: the Asana tenant-isolation flaw, the WordPress AI Engine plugin CVE, and the Supabase prompt-injection research. v2.0 is a strict superset, so if you have not read the original threat model, start there.
The controls guidance carried over and in places got sharper: OAuth-based delegation with token exchange (RFC 8693) and DPoP (RFC 9449), TEE-backed remote attestation for high-assurance deployments, sandboxing for anything executing LLM-generated code or commands, and centralized logging via OpenTelemetry in place of bespoke per-component solutions.
New in v2.0: guidance on post-quantum migration for deployments handling long-lived sensitive data, pointing toward hybrid post-quantum TLS (e.g., X25519 combined with NIST FIPS 203 ML-KEM-768). Section 3.2.7 references the companion addendum, Post-Quantum Cryptography Considerations for MCP.
Where to Start
If you scoped controls off v1, go to Section 3.3 first. Map your deployment to a level, then diff your existing controls against that level’s requirements across the eight dimensions. That surfaces gaps faster than re-reading the whole document.
If you are planning a protocol version migration, run it as a security review rather than a compatibility checklist. Section 3.2.12 is short and written for that conversation.
If you are new to this work, read the threat model in Section 3, then use the assurance profiles in Section 3.3 to place your deployment before you implement anything. Level 4 is not the default target, and the paper says so: most teams do not need it.
Read the Paper
MCP Security, v2.0 — twelve threat categories, deployment pattern guidance, the full set of controls and mitigations, and the new Security Assurance Profiles: https://github.com/cosai-oasis/ws4-secure-design-agentic-systems/blob/main/whitepapers/model-context-protocol-security.pdf
Addendum: Post-Quantum Cryptography Considerations for MCP https://github.com/cosai-oasis/ws4-secure-design-agentic-systems/blob/main/whitepapers/Addendum-MCP-and-PQC.pdf
MCP Security, v1.0 — the original threat model and RSAC 2026 presentation, if you are catching up: https://www.coalitionforsecureai.org/wp-content/uploads/2026/03/model-context-protocol-security-1.pdf
Related reading: After RSAC™ 2026: The MCP Security Question Everyone Kept Asking and the Agentic Identity and Access Management paper, both referenced throughout this update.
This paper was produced by CoSAI Workstream 4 with contributors from Anthropic, Google, IBM, Intel, NVIDIA, Cisco, Dell, Red Hat, Amazon, PayPal, ServiceNow, TrendMicro, Wiz, and ProCap360, under the editorial leadership of NVIDIA, Anthropic, and Google, and workstream leadership from Sarah Novotny, Ian Molloy (IBM), Raghu Yeluri (Intel), and Alex Polyakov (Adversa AI).
If you are building, deploying, or securing MCP servers and want a hand shaping where this work goes next, including the open questions the paper flags around sub-levels, regulatory mapping, and extension risk taxonomy, CoSAI is an open project. Come work on it with us.
This post was written by the CoSAI Workstream 4 team: Secure Design Patterns for Agentic Systems. The views expressed are those of the authors.
