Every tool call in your buyer's AI stack travels over a wire protocol called MCP. Model Context Protocol. It defines how an AI application discovers what tools are available on a remote server and calls them using JSON-RPC 2.0. A protocol for connecting things — and only connecting things.
The model never touches the connection. Everything about who's authorized to do what, and how credentials get handled, falls to the infrastructure around the model. That gap is where the interesting problems live.
The architecture in sixty seconds
Three roles. The host is the AI application the user sits in front of: Claude Desktop, ChatGPT, Cursor, Copilot. The client is a protocol-level construct the host creates to manage a single connection to a single server. One client per server, always. The server exposes tools, resources, and prompts that the client can discover and invoke.
The flow: the model proposes a tool call. The host's harness logic decides whether to execute it. The client sends the request to the server over one of two transports. STDIO for local servers running as subprocesses on the user's machine. Streamable HTTP for remote servers across the network. The server executes the tool and returns results. The client hands them back to the harness, which feeds them into the model's context.
The model never holds a credential. Never opens a socket. It asks. The harness and client do.
If you've spent years explaining to buyers why the IdP doesn't talk directly to the application, why there's a protocol layer mediating that relationship, the shape will feel familiar. Hold that instinct. It's useful for about the next four sections, and then I'll tell you where it stops.
Adoption is real
The Linux Foundation stood up the Agentic AI Foundation in December 2025 with Anthropic contributing MCP as a founding project. Platinum members: AWS, Anthropic, Google, Microsoft, OpenAI, Cloudflare, Bloomberg, Block. Over 16,000 MCP servers are indexed across registries. Claude, ChatGPT, Gemini, Cursor, VS Code, and Copilot all support MCP as clients. Monthly SDK downloads across Python and TypeScript are reported at 97 million, though package registry counters are inflated by CI/CD pipelines, so treat that as a ceiling, not a headcount.
The practitioner signal corroborates the direction regardless. At the April 2026 MCP Dev Summit, MCP co-creator David Soria Parra described teams quietly wiring MCP connections to CRMs, ticketing systems, data warehouses, and HR platforms behind corporate firewalls, at scale.
Your buyer's AI stack probably runs on MCP already, or will soon. The more useful question for your conversation is what MCP leaves uncovered.
The authorization gap
The original November 2024 spec was explicit:
"Authentication and authorization are not currently part of the core MCP specification."
Clients and servers could negotiate their own auth strategies. In practice, most community-built servers shipped with no auth at all, or with static API keys passed as environment variables. Anthropic's own early sample servers used personal access tokens. The pattern calcified across thousands of implementations before anyone corrected it.
The spec has moved fast since then. The March 2025 revision made OAuth 2.1 mandatory for remote servers, enforced PKCE and HTTPS, and added dynamic client registration. June 2025 classified MCP servers as OAuth Resource Servers and required Resource Indicators (RFC 8707) to prevent token misuse. The November 2025 revision introduced Client ID Metadata Documents to replace dynamic client registration as the default identity mechanism, added client credentials for machine-to-machine flows, and specified step-up authorization. That November 2025 revision remains the current stable spec as of this writing.
Four revisions in thirteen months, each tightening the auth story. The trajectory is genuinely encouraging.
The gap between the spec and what's deployed is not.
An Astrix Security analysis of over 5,200 MCP server implementations found that 88% require credentials to operate, yet 53% rely on static API keys or personal access tokens. Only 8.5% use OAuth. These numbers come from a security vendor with market interest in the problem being bad, so calibrate accordingly. But the pattern is consistent with practitioner reports: the spec says OAuth 2.1, the field says environment variables.
Three hard problems that remain
STDIO transport has no auth framework at all. STDIO servers run as local subprocesses inheriting the user's exact access level: files, commands, credentials, everything. The spec directs STDIO implementations to pull credentials from the environment. Fine for a developer running a local tool. Considerably less fine for anything touching production data. And the transition from STDIO to HTTP isn't incremental. You go from zero security surface to needing OAuth, token management, CORS, TLS, redirect validation, and audit logging, all at once.
Discovering a tool doesn't mean you're authorized to use it. OAuth governs which tools the client can call. It says nothing about what the server does once called. A token with read scope on a CRM can still trigger server-side logic that reads broadly. The spec governs the client-to-server connection. What happens when the server calls a downstream API is the builder's problem, and the spec says so explicitly.
Consent-once-act-many. When an agent gets permission at session start, those permissions persist for the session's lifetime. The spec's security best practices warn that if an agent's role changes mid-session, all prior permissions continue to apply. In a human-interactive OAuth flow, the user re-consents when scopes change. In an agentic session that runs for hours, the original consent covers actions the user never anticipated. The spec calls this "delegation," which is a generous word for what's actually happening.
None of this is theoretical. CVE-2025-6514 hit the mcp-remote library, downloaded over 500,000 times. Authorization endpoint URLs from untrusted MCP servers were passed directly to the system shell without sanitization. Arbitrary command execution on developer machines. Cloudflare, Hugging Face, and Auth0 had all pointed to mcp-remote in their integration documentation.
Credentials the agent can't reach
Anthropic's managed agents architecture, published April 2026, addresses the credential problem structurally: the agent's sandbox never contains credentials at all.
Two patterns. For Git access, the repository token clones the repo during sandbox initialization and gets wired into the local git remote. Push and pull work without the agent ever handling the token. For MCP tools and OAuth-protected services, tokens are stored in a credential vault at session creation time. The agent calls tools through a dedicated proxy holding only a session-scoped token. When a tool is called, the proxy fetches the real credential from the vault and makes the API call. The harness never sees the real credential. Neither does the sandbox.
Even if a prompt injection convinces the agent to try exfiltrating secrets, the secrets aren't there. The secrets simply aren't in the sandbox. No amount of prompt injection changes that.
The vault maps one credential per MCP server per user. Credentials re-resolve during a running session, so token rotations take effect without restarting. Per-user mapping means each user's agent operates with that user's permissions, not a shared service account.
The honest caveat: this works for Anthropic's hosted infrastructure. For self-hosted deployments, the full OAuth lifecycle (acquisition, refresh, storage, scoping per user per provider) remains open infrastructure work. (Arcade is a tool-use platform, so they have their own market interest in this gap being hard to close. But the architectural point stands independently.) The vault pattern is the right architecture. Building it yourself is a substantially harder conversation.
How far your OAuth intuition carries you
The MCP spec's OAuth 2.1 alignment is real and substantive. If your buyer asks how an MCP client authenticates to an MCP server, the answer involves PKCE, bearer tokens, resource indicators, and protected resource metadata. Your mental model of how an OAuth client gets a token and presents it to a resource server applies cleanly here.
Your mental model runs out of road at the trust boundary.
In federation, you know who registered the client. There's a pre-existing trust relationship. Someone configured it. MCP's original dynamic client registration model let anyone register as a client with any authorization server, automatically. The November 2025 spec acknowledged this: no client identity verification, registration spam, enterprise incompatibility. Client ID Metadata Documents improve the situation by making the client ID a verifiable HTTPS URL, but they don't solve localhost impersonation or unverified domains. The trust bootstrapping problem that federation solved with manual configuration is still partially open.
The break goes deeper than trust bootstrapping. OAuth governs the connection between client and server. Once connected, what the tool does is entirely outside OAuth's scope. In your OIDC world, when a user authenticates and gets access to an application, the application's internal authorization model controls what they can do inside it. That model exists because someone built it. In MCP, the equivalent question — what should this tool be allowed to do on behalf of this user, given this specific request, in this specific context — is the builder's responsibility. MCP gets the tool connected. Everything after that, whether the tool should act and how broadly, is a judgment problem that lives in the harness, the skills layer, and whatever governance model the organization wraps around them.
MCP is a genuinely useful connectivity solution with real adoption and a rapidly maturing auth story. The early "connect everything" enthusiasm is giving way to more disciplined patterns where MCP handles the wire and other layers handle the judgment. When your buyer's CAIO mentions they're connecting their agent framework to internal systems via MCP, the question worth asking is whether that connection is governed, and by what. Now you know enough to ask it.
Things to follow up on...
- Obsidian's confused deputy research: Security researchers found MCP proxy servers using static client IDs could be exploited to steal authorization codes without user consent, a vulnerability pattern now explicitly addressed in the November 2025 spec update.
- The AAIF governance shift: MCP spec changes now go through Linux Foundation working groups rather than Anthropic's internal roadmap, a move covered in detail at the April 2026 MCP Dev Summit that has implications for how fast enterprise-critical auth features land.
- Prompt injection via tool results: The MCP spec's security best practices page documents an attack path where crafted content returned in tool results can convince an agent to exfiltrate access tokens through the output stream, which is the credential vault pattern's strongest justification.
- Agent Vault as open-source pattern: The Infisical team released Agent Vault, an open-source credential proxy implementing the same separation-of-concerns architecture Anthropic described, suggesting the vault pattern is becoming a general infrastructure category rather than a single vendor's solution.