You are the person who owns the MCP server your team shipped last spring. It worked because the connection worked: a client signed in, a session opened, and everything after that rode on the idea that the connection was fine. Now the 2026-07-28 revision of the Model Context Protocol is on your desk, and it has removed sessions. Every request carries its own token. As WorkOS puts it, a server "can't lean on 'this connection was fine a minute ago.'"
WorkOS has published a guide mapping NIST's seven Zero Trust tenets onto the MCP request path, and you read it to find out what that change asks of you. The argument reduces your job to five checks. Give every agent its own verifiable identity. Bind every token to one MCP server. Authorize each tool call rather than the connection. Never forward the token you received. Deny by default, and ask a human before anything irreversible.
One line lands close to home, because you have a shared service key sitting in a config file: "A key shared by many callers is not an identity." If three agents and a nightly job all use it, your logs cannot tell them apart, and neither can your policy.
You also want to know how much of this is a sales pitch. The post you are reading is candid about that. There are no vendor figures to discount here; it is an architecture guide, and most of it stands without WorkOS. The spec really does cover client identity, token binding and error signaling, and really does leave per-tool policy, upstream calls and audit to you, the implementer. The pitch shows up where the guide puts the answers: AuthKit Resource Indicators for audience binding, and FGA for the per-record half of what it calls the intersection rule, where an agent gets the overlap of its own permissions and the user's. That is fair positioning, and the advice holds whichever authorization server you run.
So you check the catalog to see whether WorkOS's own surface matches its advice. For the most part it does. WorkOS has 41 API pages, and the ones the guide walks are all there. The Authorization API and Permissions API cover per-tool decisions. The User Management session tokens API and the API Keys API cover credentials the guide says should be short-lived and per-caller. The WorkOS-connect API handles registering agents, and the Audit Logs API holds the fifth check's record of user, agent, tool, arguments and verdict. An agentic access profile is published too.
The measurements are mixed, and you take note of that. WorkOS holds a Kin Score of 58.7, rated strong, with discoverability at 68.3 and contract governance at 27.3. Agent Readiness is 59.4, agent-ready. The identity dimensions this post is about are lit: delegated identity, protected resource metadata, auth clarity. So is dynamic client registration, the mechanism the post says the new spec deprecates in favour of Client ID Metadata Documents.
Then comes the turn. The unlit dimensions are the ones that belong to the fifth check. Reversibility is not documented. Consent identity is unlit. There is no dry-run mode. WorkOS tells you to ask a human before an irreversible action, and its own contracts do not yet say which of its actions are irreversible. The guide is ahead of the surface it describes.
What you take from this is practical. The five checks are a sound way to read the new protocol, and you can apply them with the authorization server you already run. Retire the shared key, give each agent an identity, scope tokens to your server, and decide per tool call. But the last check is yours to define. If you want a human to approve irreversible actions, you will have to mark which of your operations are irreversible, because even the company making the argument has not yet written that down in its contracts. Do that before an agent finds out for you.
Read the original: https://apis.io/2026/10/29/workos-zero-trust-checks-every-mcp-tool-call/