The Model Context Protocol turns 18 months old this week, and the Agentic AI Foundation (AAIF) marked the occasion with the MCP Dev Summit North America — 95+ sessions across two days in New York City, April 2–3, with AWS, Docker, Workato, and WorkOS as diamond sponsors.
The event is a milestone signal: MCP is no longer a clever Anthropic experiment. It is Linux Foundation infrastructure with dedicated working groups, a conformance testing suite, and corporate backers who have shipped it to production. That graduation is worth celebrating.
But the summit also made one uncomfortable fact impossible to ignore: the dominant unsolved problem in the MCP ecosystem is authentication, and the security posture of the average MCP deployment is not good.
OpenAI Is No Longer Just an Adopter#
The headlining arc of the summit is that OpenAI is now a co-steward of the protocol it once resisted. Nick Cooper, an OpenAI engineer and AAIF Governing Board member, is keynoting Day 2 with a session titled “MCP x MCP” — a deliberate framing that positions OpenAI as a peer contributor, not a follower.
The substance behind the branding: OpenAI’s openai-agents SDK added list_resources() and read_resource() for MCP Resources in the days before the summit. A parallel implementation was simultaneously pending in the Anthropic Python SDK. The goal is cross-ecosystem MCP Resource interoperability — an Anthropic-built agent querying context from an openai-agents-designed server, and vice versa.
This matters architecturally. MCP Resources are how servers expose structured context (files, database records, API responses) to agents without forcing a tool call. When both major agentic SDKs implement the same Resources spec from the same governance body, the protocol stops being “the thing Anthropic made” and starts being the thing that actually wins.
MCP at 18 months already has 97 million cumulative downloads (covered previously). OpenAI’s full buy-in — complete with a board seat and keynote slot — is the political seal on an already technical fait accompli.
SDK V2 Is Coming. It Will Break Things.#
Max Isbey of Anthropic presented “Path to V2 for MCP SDKs” — described as the first public statement of intent for an MCP Python SDK v2.
The Python SDK (mcp on PyPI) has been at v1.26.0 since January. The TypeScript SDK shipped steadily. Python users have been in a holding pattern waiting for guidance on where the spec was going. Now they have it, and the answer includes breaking changes.
The most significant: mcp.server.auth is getting a compatibility-breaking rewrite in V2. Anyone using the auth module in production should treat this as a migration gate. The good news is that six dedicated summit sessions on authentication suggest Anthropic and the community have diagnosed exactly what is wrong and are fixing it at the spec level rather than papering over it.
Paul Carleton (Anthropic) is separately presenting “One Spec, Ten SDKs, Zero Excuses: Conformance Testing MCP” — which signals that cross-SDK consistency (TypeScript, Python, Go, Java, Kotlin, C#, Swift, and others) is being enforced via automated conformance suites rather than hoping implementations converge on their own. That is the right call for a protocol at this scale.
The Authentication Crisis#
Six of the 95 sessions are dedicated to MCP authentication. That concentration is not an accident — it reflects a genuine ecosystem-wide problem.
The statistics from Docker’s analysis of the MCP ecosystem are damning: 43% of MCP servers have OAuth authentication flaws. Emily Lauber of Microsoft is presenting the specific attack class at the summit: OAuth mix-up attacks, where multi-issuer confusion allows attackers to leak authorization codes to attacker-controlled redirect URIs.
The mechanics are worth understanding:
- MCP servers act simultaneously as an authorization server for MCP clients AND as a single OAuth client to upstream providers — creating one shared
client_idacross all users - Because OAuth state isn’t bound to user sessions, a malicious link can redirect an authorization code to an attacker’s endpoint
- Compromised servers can take tokens issued for one service and present them to another (audience confusion)
- The
WWW-Authenticatediscovery mechanism can be abused to trigger SSRF against cloud metadata endpoints
This is not theoretical. CVE-2025-6514 (CVSS 9.6) — in the widely-installed mcp-remote npm package — demonstrated RCE via OS commands embedded in OAuth discovery fields, affecting hundreds of thousands of installs.
The mitigations are in the spec: Resource Indicators (RFC 8707) have been mandated since June 2025, and the Sponsored Enhancement Proposals SEP-1932 (DPoP) and SEP-1933 (Workload Identity Federation) are under active development. Aaron Parecki, author of the OAuth 2.1 draft spec, is attending — suggesting the fixes are being designed by people who understand the attack surface rather than just adding flags.
Production at Scale: What Enterprise Deployments Look Like#
Beyond the spec and security tracks, the summit’s keynote roster is a useful window into what serious MCP production looks like.
Uber (Meghana Somasundara and Rush Tehrani) is presenting on operating MCPs at enterprise scale — not a proof of concept, but operational lessons from an organization that cannot afford 3 a.m. page-outs from an agent that misconfigured a payment system.
Duolingo (Aaron Wang) built an internal AI Slackbot with 180+ MCP tools — an interesting data point on the composition problem. At 180 tools, you are no longer thinking about individual tool calls; you are thinking about tool namespacing, permission scoping, and how the model navigates a context that could theoretically call anything.
Datadog’s Diamond Bishop presented “The First 100 Agents: Scaling With MCP From Prototype to Platform” — a title that implicitly admits there is a cliff between building one agent and running a fleet of them. The session covers tooling gaps that don’t appear until you’re at 50+ agents in production.
What This Means for Developers Building on MCP#
The summit is a snapshot of where the ecosystem stands in April 2026. Three takeaways for developers shipping MCP integrations today:
1. Audit your auth module usage now. If your MCP server uses mcp.server.auth, treat V2 as a near-term migration. The old implementation has known structural flaws and the V2 rewrite is coming. Start reading the break notes.
2. Implement Resource Indicators. RFC 8707 has been required since June 2025 but compliance is uneven. If your server handles tokens meant for multiple upstream services, binding tokens to explicit resource URIs is the concrete fix for audience confusion attacks.
3. MCP Resources are about to matter more. With both Anthropic and OpenAI shipping list_resources() / read_resource() in their agent SDKs, MCP Resources go from a niche feature to a compatibility surface you have to support if you want agents from different ecosystems to consume your server.
The Bigger Picture#
The Linux Foundation governance, the sponsored security work, the conformance test suite, the OpenAI board seat — these are the institutional markers of a protocol that won. The question was never whether MCP would be adopted; the 97 million download figure settled that. The question now is whether the security and interoperability foundations can be hardened fast enough to keep pace with the deployment rate.
Six authentication sessions, a V2 auth rewrite, and a CVE with a 9.6 CVSS score at 18 months suggest the ecosystem is running to catch up with itself. That’s not unusual for infrastructure at this velocity. It does mean that “we’re using MCP” and “we’re using MCP securely” are still two different statements.
The summit’s session recordings are available on-demand on AAIF’s YouTube channel. If you’re building agents in 2026, the auth track is required watching.
Sources: AAIF MCP Dev Summit Schedule, Linux Foundation Event Page, DEV.to Python Developer Analysis, Obsidian Security: MCP OAuth Account Takeover, MCP Protocol Roadmap