Why Google, Microsoft, Salesforce, Snowflake, and ServiceNow all back one AI agent protocol

Google and Microsoft are platinum members of the Linux Foundation’s Agentic AI Foundation (AAIF). Salesforce and Snowflake have held gold membership since the foundation launched. ServiceNow joined as a gold member in a wave of 97 new members announced in February 2026. The project the foundation was built to steward is Anthropic’s Model Context Protocol — the specification for how an AI agent discovers and calls tools in outside systems, donated to AAIF alongside Block’s Goose and OpenAI’s AGENTS.md when the foundation launched in December 2025.

That’s five direct competitors — companies that compete for the same enterprise software budget — sitting on the governance board of one shared plumbing layer for AI agents. It’s worth asking why, and what it actually changes for anyone building on top of it.

One protocol, five competing vendors

A year ago, “connecting an AI agent to your CRM” meant writing a bespoke integration for whichever agent framework you’d picked, then doing it again for the next one. MCP’s pitch was narrower and more useful: one shape for exposing tools, resources, and prompts to any compliant client, so a server you write once works with Claude, ChatGPT, Copilot, Gemini, or anything else that speaks the protocol.

That pitch only pays off if enough of the ecosystem actually agrees to speak it. By early 2026, MCP’s adoption numbers had made the standardization case for it — tens of thousands of public MCP servers and integration into Copilot, Gemini, Cursor, and VS Code, among others. Moving MCP under a vendor-neutral foundation, rather than leaving it as a single company’s open-source project, is what let Google and Microsoft put their names on it as platinum members without ceding anything to a competitor.

The part where they didn’t fully converge

Six months after the foundation launched, the same cluster of companies — Google, Microsoft, Salesforce, Snowflake, ServiceNow, plus Cisco, Databricks, GitHub, Hugging Face, and Nvidia — published a second specification called Agentic Resource Discovery (ARD). Anthropic and OpenAI weren’t in that room.

ARD isn’t a replacement for MCP. It’s a discovery layer that sits above it: a manifest format and a registry API so an agent can find and verify the right tool — which can be an MCP server — before connecting to it. Read that as the actual shape of the détente: everyone agreed on the wire protocol for calling tools, then immediately went and built the next layer up without the protocol’s own author in the loop. Standardization happened where duplicating the work was pure cost with no differentiation. Competition moved to the layer above it, where “whose registry indexes more of the ecosystem” is a business question again.

What one protocol buys you as a builder

For anyone integrating AI agents with SaaS tools, the practical upside is real: a client written against MCP’s tool-calling shape doesn’t need a rewrite every time you add a new vendor to the stack, and a server you expose doesn’t need a different adapter for every agent product a customer happens to use. That’s fewer bespoke integrations per new agent your team adopts, and it’s the same reason connecting Claude, Cursor, and Windsurf to Norbelys’s MCP server can be one afternoon of work instead of three separate integration projects — Norbelys only had to build that server once, against the standard, rather than once per agent vendor.

The other side: one flaw, many places it recurs

Standardizing the interface also standardizes the failure modes. In July 2026, security researchers at Manifold Security disclosed a flaw in Microsoft’s official Azure DevOps MCP server: one of its tools returned pull-request content — including HTML comments invisible in the web UI — without the prompt-injection guardrail Microsoft had already applied elsewhere in the same server. An attacker could hide instructions in a comment nobody would ever see, and a reviewer’s own AI agent would execute them with the reviewer’s own permissions: approving the PR, triggering pipelines in unrelated projects, pulling confidential wiki pages the attacker had no access to directly. A classic confused-deputy bug, wearing an AI agent as the deputy.

That’s the actual trade in “the industry agreed on one protocol”: fewer integrations to build, and a failure pattern that, once found in one implementation, is worth checking for in every other one you rely on — because the shape of the vulnerability travels with the shape of the standard.

A few things worth clarifying

Does joining the same foundation mean these vendors' MCP implementations are interchangeable?+

No. The foundation governs the wire protocol — the shape of how a client asks a server what tools exist and calls them — not how any individual vendor implements or hardens their own server. Two MCP servers can both be fully protocol-compliant while differing enormously in how carefully they sanitize untrusted content, scope permissions, or log what an agent actually did. Compliance with the standard is a floor, not a guarantee of implementation quality.

Why would a company as security-conscious as Microsoft ship a server with this kind of flaw?+

The Manifold Security writeup doesn't describe a novel attack technique — prompt injection via hidden content is a known class of problem. What it describes is inconsistent application of a guardrail Microsoft had already built and used elsewhere in the same server. That's a familiar failure mode in any large engineering organization shipping many integrations quickly: the fix exists, but it wasn't applied uniformly everywhere the same input type shows up. It's an argument for treating every MCP server's actual behavior as something to verify, not for assuming any one vendor is immune because of its size or resources.

What this means for anyone connecting an agent to your tools

Treat every MCP connection the way you’d treat any other third-party integration with write access to something that matters, not as safer by default because it rides on a standard with major vendors’ names attached to it. That means credentials scoped to what the specific task needs rather than a broad key reused everywhere, and reviewing what a tool actually returns to the agent before assuming it’s been sanitized upstream — scoping API keys to least privilege is the same discipline this incident argues for, regardless of which vendor’s server you’re pointed at.

Norbelys is one small node in this same ecosystem: an MCP server at mcp.norbelys.com that lets an agent work with your sending program the same way it would with any other MCP-compatible tool, through the platform’s public API rather than a bespoke integration. The interesting story here isn’t any one vendor’s server — it’s that the industry converged on a shared shape for this problem at all, and is now finding out, one disclosure at a time, what that shape’s actual failure modes look like.