AI
Why Local MCP Servers Break at Enterprise Scale
Early MCP deployments ran servers locally alongside agents, which worked for pilots. At scale, every server that calls a remote API or database needs credentials. That means API keys, personal access tokens, and long-lived bearer tokens spread across developer desktops. They are coarse-grained, hard to track, and reusable by anyone who finds them. Enterprises also had no visibility into what data was being sent where, and no audit trail to show for compliance reviews.
Registry and Gateway: The First Production Step
Moving MCP servers to remote HTTP endpoints is necessary but not sufficient. Posta demos Solo’s agent registry, donated to the CNCF that morning, to show the full onboarding path. An operator registers the “server everything” sample MCP server in the catalog, attaches OpenSSF scores and GitHub metadata, then generates Kubernetes manifests. A kubectl apply exposes the server through the agent gateway. From that point, all traffic flows through a controlled proxy instead of direct client connections, and GitOps or CI/CD manages the configuration.
Why the MCP OAuth Spec Does Not Fit Enterprises
The MCP spec’s authentication section landed in June 2025 and was an improvement over earlier versions. Two problems remain. First, anonymous dynamic client registration is a requirement the spec inherited from public-internet OAuth flows. Azure does not support it at all. Second, the three-legged authorization code flow assumes a user delegating access to their own data. Inside an enterprise, the organization owns the data and already knows its employees. What enterprises need is enforcement of who can access what, enforced through Okta or Entra, not public OAuth flows.
Tool-Level Authorization Through the Gateway
Posta demos authentication tied to an internal identity provider. A user connects a VS Code MCP client to agent gateway, receives a 401 with the correct WWW-Authenticate metadata, then signs into the enterprise Okta instance rather than GitHub or any external provider. After the OIDC exchange returns an access token, the gateway shows all tools from server everything. From there, policies can filter which tools appear for which users based on token claims, group membership, or entitlements. The GitHub Copilot MCP server exposes many tools; this is how you restrict them per employee.
Calling SaaS MCP Servers Across Identity Domains
Atlassian, GitLab, ServiceNow, and Databricks all offer hosted MCP servers. Enterprises want to use them without letting agents call them directly. The problem is that by the time a request reaches the gateway, the user’s browser session is gone. The gateway must obtain a scoped delegated token for the upstream provider. Federated SSO only handles authentication, not authorization, and not every SaaS provider can map enterprise identities to scoped access tokens. An emerging OAuth cross-app token exchange standard would solve this cleanly, but production support from providers like Databricks, GitHub, and Atlassian does not exist today.
Token Vault: A Working Alternative for Today
The practical approach is a token vault built into the gateway. When a user authenticates via SSO, the gateway checks policy, then simultaneously orchestrates sign-in to the allowed upstream SaaS provider and stores that token internally. The client only receives the SSO token. On every subsequent call, the gateway injects the correct upstream credential automatically. The client never sees SaaS tokens directly. Auth0 has a similar token vault, and agent-core includes comparable functionality. The same pattern can also be built on the open-source agent gateway.
Notable Quotes
jamming API keys into everyone’s desktop and and and the proliferation of this across desktops is not what the enterprises want Christian Posta · ▶ 07:24
it’s almost like MCP trying to build an airplane and saying that “Uh we’ll figure out the doors later. You know, as you’re boarding, bring your favorite door. We’ll figure it out before we take off.” Christian Posta · ▶ 04:43
anonymous DCR is not used in the enterprise and won’t be used in the enterprise Christian Posta · ▶ 16:49
the last part here taking the jag doing the token exchange with the you know the Data Bricks identity provider GitHub Atlassian any of these Google whatever that doesn’t exist today. Christian Posta · ▶ 28:14
Key Takeaways
- Anonymous dynamic client registration is not used in enterprises and Azure does not support it.
- MCP auth must tie to Okta or Entra, not public OAuth authorization code flows.
- A token vault at the gateway lets agents call SaaS MCP servers without exposing upstream credentials to clients.
About the Speaker(s)
Christian Posta is Global Field CTO at Solo.io, creators of Istio. He is the author of “AI Gateways in the Enterprise”, “Istio in Action”, and other books on cloud-native and AI architecture. His current focus is production deployments of LLM applications, AI agents, and MCP, with emphasis on security and identity.