A map of NIST’s seven Zero Trust tenets onto the MCP request path: what the spec gives you, what you build, and the five checks every AI agent call should pass.
Zero Trust means no request is trusted because of where it comes from. Every request proves who sent it and is checked against policy before it runs. AI agents calling MCP servers need exactly that, and the MCP spec now makes it easier.
The 2026-07-28 revision of the Model Context Protocol removed sessions. There's no initialize handshake and no Mcp-Session-Id, so every request stands on its own and carries its own token. A server can't lean on "this connection was fine a minute ago." It has to verify each call, which is the Zero Trust model.
The spec only covers part of the job, though. It tells clients how to get a token and servers how to check it. It leaves what an agent may do with a tool, and what happens when the server calls another API, to you.
This guide maps the Zero Trust principles onto the MCP request path: what the spec gives you, what you build, and where WorkOS fits. Each check gets a short summary and a link to a deeper guide. For Zero Trust itself, start with Understanding Zero Trust security.
Key takeaways:
- Give every agent its own verifiable identity. A key shared by many callers is not an identity.
- Bind every token to one MCP server, and reject tokens minted for anything else.
- Authorize each tool call, not just the connection, and check both the user and the agent.
- Never forward the token you received. Exchange it for a new, narrower one.
- Deny by default, log every decision, and ask a human before irreversible actions.
Why AI agents break perimeter trust #
Perimeter security assumes that whatever is already inside can be trusted. An AI agent turns that assumption into a liability, for three reasons.
- Agents run on borrowed credentials. The quickest way to connect an agent is to paste in a user's API key or a shared service account. The agent then has everything that key can reach, for as long as the key lives. A key shared across agents also says nothing about which one is calling, so you can't scope it per agent or revoke one agent without breaking the rest.****
- Agents try every door. A person ignores the admin button they don't need. An agent working toward a goal will call any tool it can see. If a credential allows more than the task needs, the agent will eventually use it.****
- Agents chain calls across systems. One prompt can make an agent read a ticket, query a database and post to Slack. Each hop is another system trusting the one before it. A single over-broad token at the start becomes access everywhere downstream.
None of these is new. Agents just expose the gaps faster than people do. Zero Trust closes them by removing the assumption: no caller is trusted for being inside, and no token is trusted beyond the one request it was issued for.
The seven Zero Trust tenets, mapped to MCP #
The MCP spec covers client identity, token binding and error signaling. Per-tool policy, upstream calls and audit are yours to build.
The table uses the seven tenets from NIST SP 800-207, the standard definition of Zero Trust architecture.
The last column is where most real incidents happen. Four ways MCP authorization breaks in production walks through four of them, from auth that fails open to tokens forwarded upstream.
Where the checks happen #
No hop trusts the one before it: the agent proves its identity, the server checks the token was minted for it, each tool call is authorized on its own, and upstream APIs get a new token. The five sections below take these checkpoints one at a time.
1. Give every agent its own identity #
Zero Trust starts with knowing exactly who is calling. The 2026-07-28 spec makes Client ID Metadata Documents (CIMD) the default way to register an MCP client, and deprecates Dynamic Client Registration. But a CIMD client ID identifies the client software: every Claude Code user shares the same one, so revoking it cuts everyone off. To identify and revoke one agent, give each agent its own registration. With AuthKit Agent Registration, the token's sub is the agent's registration ID, the act claim names the user it acts for, and each registration can be revoked on its own. Read more in The developer's guide to AI agent authentication and authorization.
2. Bind every token to one MCP server #
A token that works on any server is a skeleton key. The client names the target server in the resource parameter (RFC 8707), the authorization server writes it into the token's aud claim, and your server rejects any token whose audience isn't itself, even one signed by the right issuer. Every failure returns 401 with a pointer to your metadata, never a fallback identity. Because 2026-07-28 servers are stateless, this check runs on every request, which is exactly the per-request verification Zero Trust asks for. With AuthKit, add your MCP server's URL as a Resource Indicator: without it, aud falls back to the environment's client ID and the resource parameter is ignored. The step-by-step flow is in What is MCP authorization?, and the setup in the AuthKit MCP docs.
3. Authorize every tool call, not just the connection #
A valid token proves who is calling, not that they may call refund_invoice on invoice 4521. The spec leaves that decision to you. Map each tool to a permission, deny any tool you haven't mapped, and check the permission against the specific record in the tool's arguments. When an agent acts for a user, check both halves: the user's permission (for example a WorkOS FGA access check on the invoice as an FGA resource, for the membership you look up from the token's sub and org_id) and the agent's (the token's scope). The agent gets the overlap, never more than either; see Delegated access for AI agents: The intersection rule explained. If you filter tools/list per caller, mark the result cacheScope: "private" so a shared cache can't serve one caller's list to another. More patterns are in Per-tool scopes for MCP authorization and AI agent credentials.
4. Never pass a token through #
When your MCP server calls another API, don't forward the token the agent sent you: the MCP spec says servers MUST NOT. The upstream API can't tell the token wasn't meant for it, and your server becomes a confused deputy. Get a separate token issued for that API alone, with only the scope the call needs. OAuth Token Exchange (RFC 8693) is the standard for this, though AuthKit doesn't offer it today. For third-party APIs, Pipes holds each user's own OAuth connection, so your server calls the API with that user's token instead of forwarding the agent's. For delegation chains, see OAuth's On-Behalf-Of flow for AI agents and AI agents and the multi-hop delegation problem.
5. Deny by default, log everything, and step up for risky actions #
Every error path returns 401 or 403, never a guest identity or a passthrough mode, and unknown tools, unmapped permissions and failed lookups are all denials. When a tool needs more than the token carries, return 403 with error="insufficient_scope" and the missing scope, so the client asks the user to approve it. For irreversible actions such as payments, deletions or anything sent outside the company, ask a person to confirm even when the token allows it, as the WorkOS Dashboard MCP server does for destructive changes. Log every decision, denials included, with the user, the agent, the tool and the verdict. The failure modes are in Four ways MCP authorization breaks in production, and the two kinds of step-up in Step-up authentication for AI agents and Scope step-up vs. authentication step-up.
Zero Trust checklist for MCP servers #
Use this list to review a server before it goes to production. Identity
- Clients register with CIMD (DCR only for older authorization servers), and each agent has its own identity, such as an Agent Registration
- No key shared across callers grants tool access; any API key belongs to one agent and can be revoked on its own
- You can revoke one agent without affecting the others
Tokens
- The server publishes Protected Resource Metadata at
/.well-known/oauth-protected-resource - Every request is checked for issuer, signature, expiry and audience (with AuthKit, your server is configured as a Resource Indicator)
- Access tokens are short-lived
- Inbound tokens are never forwarded upstream; upstream calls use a separate token issued for that API
Authorization
- Every tool maps to a permission, and unmapped tools are denied
- Checks use the specific resource in the tool's arguments
- Delegated calls check both the user's permission and the agent's scope
tools/listonly shows tools the caller may use, and filtered lists are marked private for caching
Enforcement and evidence
- Every failure path returns
401or403, with no fallback identity - Higher-risk tools require step-up, and irreversible ones require human confirmation
- Every allow and deny is logged with user, client, tool and verdict
How WorkOS helps #
WorkOS covers each checkpoint so you don't have to run an authorization server yourself:
- AuthKit for MCP acts as the OAuth 2.1 authorization server for your MCP server. It supports CIMD (off by default) and keeps DCR for older clients. Once you add your server as a Resource Indicator, its tokens are bound to your server and carry
org_idandclient_id. - AuthKit Agent Registration gives each agent its own identity: its registration ID as
sub, the user it acts for inact, and revocation per agent. - FGA runs the per-tool, per-resource permission checks from check 3.
- Pipes holds each user's OAuth connection to third-party APIs, so your server never has to forward the agent's token upstream.
- Enterprise-Managed Authorization , in early access, lets a customer's admin grant an agent access once, through their identity provider.
- Airlock , in early access, lets IT teams govern their employees' agents, checking each action against the task's intent: allow, deny or ask a human. SeeMCP authorization beyond OAuth .
- Audit Logs gives you somewhere to send each decision as an event, which your customers' security teams can view or stream to their own tools.
FAQ #
Is MCP Zero Trust by default? No. Authorization is optional in the spec, and it only applies to HTTP transports. When you do use it, the 2026-07-28 revision gives you per-request, audience-bound tokens. Per-tool policy, upstream calls and audit logging are left to you.
Does the MCP spec decide which tools an agent may call? No. The spec covers how a client gets a token and how a server validates it. Which tools and records a token holder may use is your server's decision.
Can an AI agent use an API key to call an MCP server? Only if that key belongs to one agent and can be revoked on its own. A key shared by many callers fails Zero Trust: it can't tell callers apart, can't be scoped per agent, and revoking it cuts everyone off. For third-party clients, use OAuth with short-lived, audience-bound tokens.
What is token passthrough, and why is it dangerous? It's when an MCP server forwards the token it received to another API, which the MCP spec forbids. The other API can't tell the token wasn't meant for it, and your server ends up using the caller's authority where it wasn't granted. Use a separate token issued for that API instead.
How should an AI agent access user data on behalf of a user? Through delegated access, explained in Delegated access for AI agents: The intersection rule. The user approves specific scopes in an OAuth flow, and the agent gets only the overlap of the user's and the agent's permissions, checked on every call. It never gets the user's own session or credentials.