You had your MCP tools working. Slack, GitHub, Jira, a database — all connected through MCP, the universal plug standard for AI tools. You pasted API keys into a JSON config, ran it locally, and felt like a wizard. Everything talked to everything.

Then your security team walked in. Where are those credentials stored? How do they rotate? Who else can read them? The answer to all three: nobody knows. And that quiet panic you felt? Multiply it by every company trying to move AI agents from demo to production.

In April 2026, all three major AI platforms shipped their credential solutions for MCP — and none of them agree on how it should work.

One Protocol, Three Lockboxes

On April 9, Anthropic launched Managed Agents with Credential Vault — an encrypted proxy that fetches your secrets so your agent's code never touches actual credentials. OAuth with auto-refresh, static bearer tokens, the works. Capped at 20 credentials per vault, because apparently enterprise security comes with a punch card.

On April 15, OpenAI updated its Agents SDK. Their pitch: pass a bearer token in the header, handle refresh yourself. Need OAuth? Build it. But here's the comedy: ChatGPT Apps require OAuth 2.1 — bearer tokens rejected at the door. One company shipping an SDK that says "tokens are fine" and a product that says "absolutely not." OpenAI is having a public argument with itself about authentication, and developers get to pick a side.

On April 17, Google released ADK 1.0 — later showcased at Cloud Next on April 22. Five credential types including service accounts, Application Default Credentials, and a pause-and-resume OAuth flow. Works beautifully — if you've already pledged allegiance to GCP. For everyone else, it's a full auth rewrite with a Google accent.

Three smart approaches. Three incompatible systems. MCP was supposed to be USB for AI. Turns out every port needs a different power brick.

The Spec Nobody Follows

The MCP specification (version 2026-03-15) mandates OAuth 2.1 with resource indicators — properly scoped tokens, proper security, all of it. On paper, this is solved.

In practice, the ecosystem hasn't gotten the memo. As we covered in last week's supply chain analysis, MCP servers have a fundamental hygiene problem — the majority of community servers still rely on static API keys sitting in config files. AgentSeal's April 10 audit of 1,808 servers found two-thirds riddled with vulnerabilities from auth bypasses to command injection. None of that has improved in two weeks.

But the auth-specific angle matters more here: of the three platforms' launch partners, almost none implement OAuth 2.1 per the actual spec. Anthropic's Credential Vault debuted with Notion, Asana, and Sentry — three managed integrations out of hundreds of servers developers actually use. Google's ADK docs showcase five auth patterns but default their examples to API keys. OpenAI's SDK punts entirely — "bring your own auth" means most developers bring the path of least resistance: a static token pasted from a dashboard.

Why the gap? OAuth 2.1 requires server-side infrastructure. A solo developer maintaining an open-source MCP connector on weekends doesn't have a token endpoint, a redirect server, or a refresh flow. As one frustrated maintainer put it in community threads: "I just hate that the clients don't all support OAuth or API key so I have to support both!" The spec demands what the ecosystem's workforce can't deliver.

The Real Cost: Write Once, Lock In Everywhere

Each platform's auth model makes internal sense. Anthropic plays corporate parent — locking the medicine cabinet so the kids can't poison themselves. Google leverages its cloud identity stack — efficient if you've already moved into the GCP house. OpenAI maximizes developer freedom — which is a diplomatic way of saying they didn't want to build auth infrastructure and called it a feature.

The collective cost is lock-in at the credential layer. A tool wired to Anthropic's Credential Vault doesn't work in Google ADK without rewriting its auth. A tool relying on GCP service accounts is useless in OpenAI's SDK. MCP promised "write once, connect anywhere." Auth turned it into "write once, then write the authentication again for each platform." Same tool, three integration tax bills.

The Futurum Group's MCP Security Report put it cleanly: "The question enterprises are actually asking isn't whether MCP works. It's whether they can govern what it does."

Your Security Team Is Still Waiting

Remember them? Still standing in your doorway. Except now instead of one uncomfortable answer, you owe them three — each locking you into a different platform's theology about how credentials should work.

If you're evaluating MCP tools for production, functionality checks aren't enough. That Slack connector humming along in Claude's Managed Agents? Budget a full auth rewrite for Google ADK. Your team picked OpenAI's SDK for the "flexibility"? Enjoy building OAuth from scratch while ChatGPT Apps refuse to use what you built.

MCP has one protocol and three credential religions. The protocol works. The "universal" part shattered at the authentication layer — exactly where demos become deployments. Whoever makes standards-based auth frictionless for the people who actually build MCP servers, not just the people who consume them, captures the production market. Right now, nobody has. Pull up more chairs for your security team — this meeting's going to be a long one.