Solo.io Says MCP Authorization Belongs to Enterprise Identity

Solo.io Says MCP Authorization Belongs to Enterprise Identity

Solo.io’s Christian Posta and Louis Ryan argue that the MCP authorization spec is a non-starter for enterprise. Their case is aimed at the June 2025 revision, which leaned on OAuth RFCs that are “not widely used, not implemented consistently among established identity providers,” above all anonymous dynamic client registration. Enterprises, they write, “don’t allow anonymous DCR, they want to know exactly who/what’s connecting to their MCP servers.” The spec, in their reading, 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.

Read the date before the argument. 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, which removes some of the anonymity the post objects to. What survives intact is the alternative they propose. Take the user’s identity as a JWT from the existing identity provider, Entra or Okta; give each agent its own verifiable workload identity, with SPIFFE as the foundation; and evaluate access in a policy engine such as OPA instead of in 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 heavy lifting goes to a gateway, and the gateway they name is their own open-source agentgateway, which is the commercial interest to keep in view while agreeing with the design.

The Solo.io record shows where the company’s own catalogued surface sits relative to that argument. The fifteen API pages are mostly Gloo Portal’s Portal Server, and the ones that speak to identity are the Solo.io Auth API, the Solo.io OAUTH Credentials API, the Solo.io API Keys API and the Solo.io 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 Kin Score is 60.4, strong, led by developer ergonomics (78.6) and discoverability (76.7), with contract governance at 28.0. Agent Readiness is 34.8, agent-ready, with mcp_server and agent_skills lit. Unlit: dynamic_client_registration, protected_resource_metadata, delegated_identity and consent_identity. For most providers those four are 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.

← Screenshotline Routes Every MCP Call Back Through Its Own API