The Model Context Protocol just shipped an extension called Enterprise-Managed Authorization. It is a big deal, and it validates a thesis we have been building on for a while.
Here is the problem it solves. Today, when an employee wires an MCP client like Claude Code into a set of MCP servers, each connection is authorized one server at a time, by the individual. Someone hand-provisions a credential per server, per person. Onboarding means manually authorizing a dozen services. Offboarding means hunting down and revoking a dozen credentials and hoping you got them all. Security teams have no single place to say “engineers may use the GitHub MCP server, but not the production-database one.” It is API-key sprawl with a compliance problem attached.
Enterprise-Managed Authorization fixes the admission step. The employee logs in once with their corporate identity (the same SSO they use for email and Slack), and the company’s identity provider, Okta or Entra or whatever you already run, decides which MCP servers that agent is allowed to reach. Authorized servers connect with no per-server prompts. Unauthorized ones never hand back a token at all. Revoke the person in the IdP and their access dies everywhere, immediately.
How It Works: SSO In, a Short-Lived Token Out
The mechanism is a new grant type. After the user signs in, the MCP client exchanges that login for an Identity Assertion JWT Authorization Grant, or ID-JAG, from the corporate IdP. Crucially, the IdP evaluates policy at that moment: group membership, role, conditional-access rules. If the agent is allowed to reach a given server, the IdP returns an ID-JAG. The client then exchanges the ID-JAG for an access token from that server’s authorization server, and uses that token to make calls.
Agent -> corporate SSO login -> ID-JAG (IdP evaluates policy here)
-> exchange ID-JAG for an access token -> call the MCP serverThat is what enterprises have been asking for: control access from one place, turn a whole team’s access to a server on or off at once, and cut someone off everywhere the instant they leave, with a clear record of who was let into what. It is the model Highflame is built around, and the market is now standardizing on it.
What the Standard Covers, and Where It Stops
Read the spec carefully and one thing stands out: it is about admission only. It answers a single question (which MCP servers may this agent connect to?) and it answers it well. It does not address two other questions that decide whether an agentic deployment is actually safe:
- How does the server get the downstream credential it needs to act on the user’s behalf, the GitHub token, the Slack token, the database credential?
- What is the agent allowed to do once it is inside? Which specific tools, with which arguments, under which conditions?
There are three distinct layers here, and the standard owns exactly one of them:
| Layer | The question it answers | Who owns it |
|---|---|---|
| Admission | Which servers may this agent connect to? | The standard, via your IdP |
| Downstream credentials | How does the server act for the user? | The gateway |
| Runtime authorization | What can each tool call actually do? | Wide open. This is the hard part. |
The ID-JAG gets the agent through the door. It says nothing about what happens after. And “after” is where the incidents live.
A Valid Token Is Not a Safe Action
We have written before that authentication tells you who made a request, never whether the request should be allowed. Enterprise-Managed Authorization is a big upgrade to the who: it ties that identity to corporate SSO, governs it from one place, and lets you revoke it everywhere at once. But it is still answering who, not what.
An agent that is legitimately admitted to a database MCP server with a perfectly valid token can still be steered into running DROP TABLE, exfiltrating another tenant’s rows, or chaining a sequence of innocent-looking tool calls into something harmful, whether by a prompt injection buried in a document it read, a confused plan, or a compromised upstream. Admission is necessary. It is nowhere near sufficient. The damage happens at the tool call, long after the token was issued.
Highflame: Speak the Standard at the Door, Govern Everything Inside
This is exactly how Highflame is architected, and the new standard slots into it cleanly.
At the identity layer, we already speak the standard. Highflame’s open-source identity engine, ZeroID, is the MCP Authorization Server in this flow, and it runs today. It validates an ID-JAG against your corporate IdP, maps the identity to a governed Highflame principal (failing closed if it can’t), and mints the audience-restricted access token the agent actually uses. Its authorization-server metadata advertises the ID-JAG grant profile, so any compliant client discovers the flow on its own. You can run Highflame as the enterprise IdP for agents, or sit it behind Okta or Entra and add what their tokens don’t carry: how far the action is delegated from a human, and how much the agent should be trusted. Either way the token an agent presents is a first-class, governed Highflame identity, not an opaque pass.
At the runtime layer, we own what the standard leaves open. Every tool call an admitted agent makes flows through the Highflame gateway and is checked at the moment of the call: not just “is this agent allowed in,” but “should this specific call, with these arguments, be allowed for this principal right now.” The gateway reads what actually moves through each request and response, and it notices when an agent starts drifting from the task it was admitted to do. This is the layer that is hard to get right, and it is where agentic security is actually won or lost.
One Identity, End to End
Because admission and runtime share a single identity model, the chain holds together. The corporate login feeds the ID-JAG. The ID-JAG resolves to a Highflame principal carrying the account, project, role, and trust attributes our policy engine keys on. Every downstream tool call is authorized against those attributes. Revoke the user at the IdP and the whole chain, admission and runtime alike, goes dark. It is one identity, governed from SSO all the way to the individual tool call, with an audit trail that covers the whole path.
That is the difference between knowing an agent was allowed in and knowing exactly what it did once it was.
A Tailwind, Not a Finish Line
We are glad to see Enterprise-Managed Authorization land. It went stable in mid-2026 with Okta as the first identity provider, and Anthropic’s Claude connectors already provision through it. The market is standardizing on exactly the admission model we build for. Highflame supports it today and keeps it interoperable: it validates an Okta-minted ID-JAG the same way it validates its own, for any compliant MCP client and any corporate IdP.
But adopting the standard is where an enterprise’s agent-security story starts, not where it ends. Letting the agent in was never the hard part. It is everything the agent does once it is through the door, and that is the part we own.
Building agentic systems and trying to figure out where authorization actually has to live? Talk to us.
