MCP Enterprise-Managed Authorization, the Claude Apps Gateway, and ARD All Stop at the Same Line
Three agent governance layers went stable or shipped in the last month. Every one of them authorizes connections. None of them authorizes actions, and each spec admits it in writing.
Section 7.2 of a stable web specification is not where you expect to find the most important sentence in AI infrastructure this month. Read it anyway:
"The visibility the IdP has between the MCP Client and MCP Server is limited to the process of issuing the access token, but does not extend to the actual MCP traffic between the MCP Client and Server."
That is the Enterprise-Managed Authorization extension to the Model Context Protocol, describing its own limits under the heading "Security Considerations." The extension went stable on June 18. Your identity provider decides whether an agent may open the door. After that, the identity provider is blind.
Three governance layers shipped or stabilized inside about a month, and all three draw the same boundary in the same place. Almost nobody is reading the part where they say so.
The stakes: you are buying a lock for the front door and calling it a security system
Here is my position. The industry has converged, fast and correctly, on how to control which agent connects to which system. That problem is close to solved. The problem of controlling what the agent does after it connects is not solved, is not being solved by anything that shipped this month, and is being obscured by procurement language that treats "governance" as one undifferentiated thing.
If you are the person signing off on an agent rollout, this distinction decides whether your controls actually cover the failure you are worried about. Most of the scary agent failures are not unauthorized connections. They are authorized connections doing authorized things at the wrong scale, to the wrong record, for the wrong amount.
What the three layers actually do
MCP Enterprise-Managed Authorization replaces per-server consent prompts with one corporate sign-in. The mechanism is an Identity Assertion JWT Authorization Grant, or ID-JAG: the client gets a short-lived JWT from the enterprise identity provider during SSO, then exchanges it for an access token from the MCP server's authorization server. The user never sees a per-server consent screen. Okta is the first supported identity provider, Anthropic implemented it across Claude, Claude Code, and Cowork, VS Code added IDE support, and Asana, Atlassian, Canva, Figma, Granola, Linear, and Supabase are live on the server side (MCP blog).
Read the example the spec itself gives for what policy can express: users in the "engineering" group get read-only access from an AI code editor to the source control server, users in "marketing" get read and write on internal documentation. That is group-to-server-to-scope. It is genuinely useful. It also says nothing about which repository, which document, or which customer record.
The Claude apps gateway is a self-hosted control plane for Claude Code and Claude Desktop, shipped for AWS on July 15 after Anthropic introduced it a week earlier, with Google Cloud publishing its own walkthrough. It runs as a stateless container, acts as an OpenID Connect relying party against any compliant provider, and centralizes policy, telemetry, routing, and spend. Its policy vocabulary covers allowed models, tool permissions, restrictions like blocking file writes or web access, and daily, weekly, and monthly spend caps scoped per organization, group, or user (AWS, Anthropic).
Notice the granularity again. "May this group use web access" is a real control. "May this agent send this particular customer's data to this particular external endpoint" is not in the vocabulary.
Agentic Resource Discovery, announced by Google on July 14 with Microsoft, GitHub, Hugging Face, NVIDIA, Salesforce, Snowflake and others, sits a stage earlier still. Organizations publish a machine-readable ai-catalog.json describing their tools and agent endpoints, registries aggregate those catalogs, and agents search by task intent instead of hardcoded endpoints. Domain-based verification lets an agent confirm a resource is authentic before connecting. The contributors have been unusually direct that ARD returns ranked matches and verifiable identity and then gets out of the way, and that it does not replace authentication, authorization, governance, or organizational trust decisions.
Discovery, then connection authorization, then model and tool policy. Three layers, one gap, and every author flagged it.
The gap, stated plainly
An agent authenticates through your corporate identity provider. Your IdP checks the policy and issues an ID-JAG. The MCP server's authorization server validates it and issues an access token scoped to crm.read crm.write. The gateway confirms the model is allowed and the tool is permitted, logs the request, and decrements the spend cap.
Every control fired correctly. Now the agent calls crm.write forty thousand times and overwrites the account owner on the entire book of business, because a prompt injection in a support ticket told it to clean up stale records. No layer that shipped this month sees anything wrong. The connection was authorized. The tool was permitted. The scope matched. The spend cap was nowhere near a per-request ceiling.
That is the shape of the risk, and it is why Anthropic's CISO guide, published July 17, asks about blast radius as a separate question from access. Blast radius is what you get when connection authorization is your only authorization.
Put this into practice
You cannot buy per-action enforcement off the shelf right now. You can build a serviceable version this week, at the two layers you already control.
Start by writing down the granularity of every control you have. Take one agent in production or pilot. For each control, write the sentence it can actually express. "This group may reach this server with these scopes." "This group may use these models and these tools." Then write the sentence you wish it expressed: "This agent may modify at most fifty records per hour, never the billing table, never a record it did not read this session." The gap between those two lists is your real exposure, and most teams have never written it down.
Push enforcement into the MCP server, because that is the only component that sees the actual call. The spec is explicit that the identity provider does not see MCP traffic. Your server does. Concretely: give the agent a database role rather than the application's role, with row-level security tied to the sub claim in the token; add rate limits per tool per session, not just per user; make destructive operations require a distinct scope that your IdP grants to almost nobody; and log the arguments, not just the tool name, so an audit can reconstruct what happened rather than that something happened.
Make scopes narrow enough that connection-level policy does useful work. EMA's usefulness scales directly with how finely your server defines OAuth scopes. A server that offers read and write hands your IdP a blunt instrument. A server that offers invoice.read, invoice.void, and customer.pii.read lets the same IdP policy express something meaningful. This is the single change with the best return available to you, and it lives entirely in code you own.
Then run the four questions on that agent. What does it ingest and how trustworthy is that content, what actions can it take, what is the blast radius of a failure, and does its behavior stay observable after deployment. It takes an afternoon and produces a document a security team can sign.
Honest limitations
My argument has real weak points and you should know them.
The gap is a design decision, not an oversight. Putting per-action policy in the identity provider would mean routing every MCP call through the IdP, which is a latency and availability disaster and hands one vendor visibility into all agent traffic. The layered design is defensible. My complaint is about how it gets sold downstream, not about the architecture.
Enterprise-Managed Authorization is also newer than most coverage suggests, and coverage has been sloppy about dates. The stable announcement is dated June 18, 2026, not early July as several roundups have it. Extensions are opt-in and never active by default, and support varies by client, so "MCP supports this" and "your deployment has this" are different claims.
The advice to push enforcement into the MCP server assumes you wrote the server. If you are consuming Atlassian's or Figma's hosted server, you get the scopes they defined and nothing more. Your only real lever there is scope selection and vendor pressure, which is slower and less satisfying than anything I suggested above.
I have not tested any per-action enforcement product. Alterion's Draco launched July 17 claiming exactly this capability, and I am not endorsing it, because the coverage I could find rests on aggregators rather than a primary vendor post, and the vendor-agnostic and on-premises claims need testing before anyone routes regulated traffic through them.
And the four-question audit is a framework, not a control. Answering it well still leaves you needing enforcement mechanisms that nobody has fully shipped.
What to do with this
The next time a vendor calls something an agent control plane, ask one question: does it govern connections or actions? The answer is almost always connections, and there is nothing wrong with that as long as everyone in the room knows it.
Go read Section 7.2 of the EMA spec yourself. It is four sentences. Then go look at what your own MCP servers accept as a token scope, and ask whether that scope would have stopped the worst thing your agent could plausibly do on a bad day. If the honest answer is no, you have found this quarter's work, and it is in your code rather than in a purchase order.
Sources: MCP Enterprise-Managed Authorization specification (stable), MCP blog announcement, MCP EMA documentation, AWS Claude apps gateway, Anthropic Claude apps gateway, Anthropic CISO guide, Agentic Resource Discovery specification.