Picture this. You have spent a few weeks getting an MCP server running inside your company. It works. Then your security lead asks one question: who exactly is connecting to this thing? You open the authorization spec, find dynamic client registration, and realize the honest answer is that anyone could register as a client. Your security lead is not impressed.
That is the situation Solo.io's Christian Posta and Louis Ryan describe in a post arguing that the MCP authorization spec is a non-starter for enterprise. They aim it at the June 2025 revision, which leaned on OAuth RFCs that are, in their words, "not widely used, not implemented consistently among established identity providers," above all anonymous dynamic client registration. Their line for your meeting with security: enterprises "don't allow anonymous DCR, they want to know exactly who/what's connecting to their MCP servers." In their reading, the spec was written for public SaaS servers that anyone on the internet might connect to, not for the inside of a company that already knows who its users are.
Before you carry that argument into the room, read the date. The spec has moved since. The 2026-07-28 revision made Client ID Metadata Documents the recommended registration path, with DCR kept for older clients. That removes some of the anonymity the post objects to, so you should not repeat the complaint as if nothing changed.
What survives intact is the alternative they propose, and it is something you can actually take to your identity team. Take the user's identity as a JWT from the identity provider you already run, such as Entra or Okta. Give each agent its own verifiable workload identity, with SPIFFE as the foundation. Then evaluate access in a policy engine such as OPA instead of inside bearer-token claims. Their example is the sharpest line in the piece: "the tax agent can call the calculate tax MCP server, but the reservations agent cannot, no matter who the user is." The point is that the decision depends on which agent is calling, not only on which person is behind it.
The heavy lifting in their design goes to a gateway, and the gateway they name is their own open-source agentgateway. Keep that in view. The design can be right and still come from a company with something to sell, so judge the architecture on its merits and treat the product pitch as a separate question.
Here is the part worth pausing on, because it is where the post turns on its own author. The APIs.io catalog looked at Solo.io's own published surface against this argument. It lists fifteen API pages, mostly Gloo Portal's Portal Server. The ones that touch identity are the Auth API, the OAuth Credentials API, the API Keys API and the Teams API. That is credentials and team membership managed per application, the conventional API-management shape, not the identity-first policy model the post recommends for MCP.
The scores tell a similar story. The Kin Score is 60.4, rated strong, led by developer ergonomics at 78.6 and discoverability at 76.7, with contract governance at 28.0. Agent Readiness is 34.8, rated agent-ready, with mcp_server and agent_skills lit. Four checks are unlit: dynamic_client_registration, protected_resource_metadata, delegated_identity and consent_identity.
For most providers, those four would simply be gaps. For Solo.io, the first is a position the company argued in public, and the record is consistent with it. The other three are the ones the post's own recommendation would need someone to publish. The catalog does not say Solo.io is wrong. It says the argument and the published surface have not met yet.
So what do you take away? Check the spec revision date before you quote any critique of it. Bring the identity-first pattern, user JWT plus workload identity plus policy engine, to the people who already own your identity provider. And when a vendor's argument is persuasive, look at what the vendor itself publishes, then hold your own MCP server to the same standard.
Read the original: https://apis.io/2026/11/11/solo-io-says-mcp-authorization-belongs-to-enterprise-identity/