Model Context Protocol is the specification most AI agents now use to reach your files, databases, and internal systems. It stopped being controlled by a single AI vendor in December 2025, and it picked up a significant security overhaul in July 2026. If your team connects any AI tool to real business data, both of those changes affect what you should demand from a vendor before you let that connection happen.
Here is the short version. MCP now sits under multi-vendor, foundation-level governance instead of one company's roadmap, and its own maintainers admit that enterprise-grade audit trails and access control are still being built. That shifts the burden to you. Ask who manages identity, logging, and access for every MCP connection your AI tools make before you sign.
On December 9, 2025, Anthropic donated Model Context Protocol to the newly formed Agentic AI Foundation, a directed fund under the Linux Foundation. Anthropic, the payments company Block, and OpenAI founded it, and Google, Microsoft, Amazon Web Services, Cloudflare, and Bloomberg joined as members. The official announcement framed the move as putting MCP under the same kind of neutral, multi-vendor stewardship that already governs projects like Kubernetes and PyTorch.
That stewardship is not symbolic. MCP's published governance model now runs through a formal Steering Group of Lead Maintainers, Core Maintainers, and Maintainers, with proposals reviewed on a two week cadence and decisions recorded publicly on the project's own channels rather than settled behind one company's closed doors. For a specification your business is increasingly building vendor integrations around, that structural detail is not trivia. It is the difference between a roadmap one company can redirect on its own and one a coalition of competitors has to agree on together.
The donation mattered because of scale, not sentiment. By the time of the announcement, MCP had crossed 97 million monthly SDK downloads and more than 10,000 active public servers, with adoption already built into ChatGPT, Gemini, Microsoft Copilot, and Visual Studio Code. A protocol used at that scale is infrastructure whether anyone planned it that way or not, and infrastructure that important is safer sitting under a foundation with competing vendors at the table than under any single company's control.
Because an agent that calls an unmanaged, self-hosted MCP server is an agent with an unmanaged, self-hosted path into your data, and the major cloud vendors are moving to close that gap themselves before it becomes a breach report. Google Cloud announced fully managed, remote MCP servers for Google Maps, BigQuery, Compute Engine, and Google Kubernetes Engine in December 2025, then expanded to more than fifty managed servers across its portfolio by the following spring. Other major cloud platforms are building toward the same pattern.
The features Google attached to those servers tell you what enterprise buyers were actually asking for. Cloud IAM handles access control, audit logging tracks every agent action, a Cloud API Registry lets administrators see which MCP tools are actually trusted, and Model Armor specifically defends against indirect prompt injection, one of the more common ways an attacker manipulates an agent through content it reads rather than a command a person types. That is the governance stack a vendor should be able to describe to you in plain terms, not a slide with a checkmark next to "MCP support."
The specific vendor matters less than the pattern behind it. Every major cloud and AI platform is converging on the same logic, because the alternative, individual teams standing up ungoverned MCP servers on a laptop or a stray virtual machine, creates exactly the shadow AI footprint your security team cannot see or audit. Whatever platform you run on, stop asking a vendor whether it supports MCP. Ask who manages identity, logging, and access control for the MCP connections your agents actually make.
If you cannot answer that question about your own current AI stack, that is worth finding out now rather than during an incident review. A cybersecurity assessment is the fastest way to surface which tools are already making these connections without anyone having signed off on how.
The clearest warning here does not come from a vendor at all. In May 2026, the National Security Agency published a joint Cybersecurity Information sheet on MCP security, produced with Carnegie Mellon University's Software Engineering Institute, and it does not read like a product endorsement. It flags that MCP components can be configured to access or process data with no required access control at all, that unvalidated message deserialization opens the door to injection attacks, and that most current implementations skip the audit logging an incident response team would actually need after something goes wrong.
Those are not edge cases. They describe the default behavior of an unconfigured MCP deployment, and the agency's recommendations read like a checklist for anyone letting an AI tool touch production data: define explicit trust boundaries between MCP components, validate every parameter against a schema, sandbox tool execution at the operating system level, and feed logging into your existing security monitoring rather than trusting a tool's own internal record. If a vendor cannot speak to those specific controls, you are the one absorbing that gap.
The protocol's maintainers are candid about what is unfinished, which is genuinely useful information for anyone deciding how much to depend on MCP today. The 2026 roadmap names four priorities for the year.
That last point deserves attention. The specification a growing share of your AI tooling now depends on still treats enterprise audit and single sign-on requirements as an open problem the community has not finished solving, not a solved one you can take for granted. Your vendor contracts and internal policies should reflect that reality instead of assuming it is already handled somewhere upstream.
The July 28, 2026 specification update moved part of that forward. It replaced the old session handshake with a stateless core, where each request carries its own protocol version and client identity so it can reach any server instance behind a load balancer without shared session storage. It also made issuer validation mandatory under RFC 9207 and began retiring open client registration in favor of credentials bound to a specific issuing authority, both aimed at stopping a stolen token from being replayed against a server it was never meant for. Details like that surface in a security review, not a sales deck, and they matter more to your actual risk than any feature list a vendor hands you.
| What you ask a vendor | What a governed answer sounds like | What an ungoverned answer sounds like |
|---|---|---|
| Who authenticates this MCP connection | A named identity provider or single sign-on integration you control | "The credential lives in a config file on the server" |
| Where does the audit log live | Exportable to your own security monitoring, with retention you set | "We don't currently log individual agent actions" |
| Who approved this specific server | Reviewed against a registry or allowlist before it went live | "A developer stood it up to solve one problem" |
Treat "we support MCP" as a starting question, not an answer. Two products can both make that claim while one hands an agent unmanaged, unaudited access to a data source and the other routes every call through identity checks, logging, and a defined policy. The difference rarely shows up in a demo. It shows up when you ask for the authentication method, the audit log retention period, and a record of exactly what an agent touched and when.
Vendor due diligence for AI tools is not a one time checklist you clear before signing. It is an ongoing part of how you manage risk as your AI footprint keeps growing, which is the gap our AI services team works with clients to close, especially when new tools are arriving faster than a security review can keep pace.
Start with an inventory rather than a new policy document. Find out which of your current AI tools already make MCP connections, who manages the identity and logging layer for each one, and whether any were stood up by an individual team without security or IT ever being looped in. That inventory alone will tell you more about your actual AI exposure than any vendor's marketing page. If you want a broader framework for that kind of review before your next renewal cycle, our Cybersecurity Buyer's Guide walks through the same due diligence questions across your entire vendor stack, not just AI tools.
MCP is not going away, and the pace of change around it is not slowing down. The organizations that come through this fine are the ones that already know who is watching every AI connection, not the ones scrambling to find out after an agent touches something it should not have.
If your team is moving faster with AI than your guardrails are, start with structured training rather than another tool. Securafy AI University gives your people role-based AI training with security built into the material, not bolted on afterward.
If you would rather talk through your specific environment first, book a strategy call with Securafy and we will walk your current AI usage, exposure, and the fastest path to safe adoption.