Model Context Protocol is the connection layer making AI assistants useful across enterprise systems. It is also the fastest-growing ungoverned attack surface in enterprise AI. Three critical CVEs in 2026, 38% of MCP servers lacking authentication and a documented breach timeline confirm this is a live governance problem, not a future one.
If your organisation is deploying AI agents and assistants, there is a good chance it is also deploying Model Context Protocol. And there is an equally good chance nobody in your governance function knows it is there.
MCP, Anthropic's open standard for connecting AI assistants and agents to external data sources and tools, has moved from developer experiment to enterprise infrastructure in less than eighteen months. Microsoft, Google, OpenAI and Block all back it. Every major AI coding assistant uses it. Microsoft Copilot uses it. And since the beginning of 2026, a series of real CVEs, documented breaches and a patch for a critical Azure MCP Server vulnerability have confirmed what security researchers have been warning: the speed of MCP adoption is outpacing the development of governance controls, and the attack surface is growing with every new integration that goes live without security review.
RSAC 2026 was dominated by MCP. One session demonstrated a vulnerability that enabled remote code execution and full takeover of an Azure tenant through an MCP integration. Adversa AI scanned more than 500 MCP servers and found that nearly 38% lack authentication. Noma Security found that more than 90% of organisations deploy MCP servers with default configurations that allow all tools to be used, including potentially destructive ones. These are not edge-case findings. They are the baseline state of most enterprise MCP deployments right now.
MCP defines how AI assistants and agents connect to external systems: file repositories, knowledge bases, databases, APIs and business applications. It is, as CIO magazine put it in February, the plumbing that makes AI useful in an enterprise context. And like most plumbing, it is invisible when it works correctly and catastrophic when it does not.
The governance challenge is structural. MCP defines how AI tools communicate with systems. It does not define what security controls govern those communications. The governance is not in the protocol. It is in the implementation. And most MCP implementations currently in enterprise environments were designed for developer convenience, not enterprise security. They typically use over-privileged service accounts, lack per-user authorisation, provide minimal audit logging and store credentials in ways that create prompt injection vulnerabilities.
What makes MCP categorically different from traditional API integrations is that MCP moves influence, not just data. When context becomes the vehicle for intent, memory and authority signals in an AI system, any weakness in context governance becomes a systemic vulnerability. A malicious instruction embedded in a document that an AI agent retrieves through an MCP integration can redirect the agent's entire subsequent behaviour, including actions across every other system the agent has access to.
The MCP security risk is not theoretical. There is a documented incident timeline.
In September 2025, the first malicious MCP package appeared on public registries, operating undetected for two weeks while exfiltrating email data. In January 2026, a critical vulnerability in an MCP integration was disclosed. In March 2026, Microsoft released a patch for CVE-2026-26118, a server-side request forgery vulnerability in the Azure MCP Server that allowed an authorised attacker to increase network privileges by capturing the MCP server's managed identity token. In April 2026, a design flaw in Anthropic's core MCP specification was found to have affected multiple platforms including LettaAI, LangFlow and Windsurf. CVE-2026-33032, with a CVSS score of 9.8, was discovered in nginx-ui, where an MCP message endpoint failed to perform authentication for command execution requests, allowing attackers to achieve complete service takeover. And CVE-2025-49596, with a CVSS score of 9.4, allowed arbitrary command execution through unauthenticated MCP Inspector instances.
Three things stand out from this timeline. First, the vulnerabilities are real and current, not historical. Second, the CVSS scores are high, indicating critical severity. Third, the common thread across incidents is not sophisticated attack technique. It is the absence of the basic governance controls that enterprise security teams apply to every other system they manage: authentication, authorised access scope, audit logging and inventory visibility.
Based on the research and incident data, most enterprise MCP deployments have at least several of the following governance gaps. Each represents both a security risk and a compliance exposure under Australian privacy and governance obligations.
No MCP server inventory. If your security and governance teams cannot provide a list of every MCP server in the environment, the identities those servers use and the tools they expose, there is an unmanaged attack surface that grows every time a developer spins up a new agent integration. This is the governance equivalent of not knowing what software is installed on enterprise endpoints.
Default authentication configuration. Nearly 38% of MCP servers scanned by Adversa AI lack authentication. Most are deployed with default configurations that allow all tools, including destructive ones. OAuth 2.1 with PKCE is the current security standard for MCP authentication. Most implementations do not use it.
Over-permissioned service accounts. MCP servers typically inherit the permissions of the developer or service account that created them, which is often far broader than the specific task the agent is performing. An AI agent summarising customer correspondence should not have write access to customer records. An agent processing invoices should not have access to HR systems. Least-privilege access design at the agent and MCP layer is the governance control that most implementations skip.
No per-operation audit logging. An AI agent that takes a chain of actions through MCP integrations, including accessing databases, calling APIs and modifying records, creates an accountability gap if those actions are not logged with sufficient detail to reconstruct the sequence post-incident. In financial services, healthcare and any organisation subject to Privacy Act obligations, this logging is not optional governance practice. It is a regulatory requirement for demonstrating that AI systems operated within their authorised scope.
No governance process for new MCP integrations. MCP integrations can be created by any developer experimenting with AI tooling. Without a structured intake process that requires security review before an MCP server goes live, the MCP attack surface expands continuously outside the visibility of governance and security teams. This is the shadow AI problem applied specifically to AI connection infrastructure.
Supply chain exposure. MCP servers composed of third-party packages carry supply chain risk. Typosquatting, dependency injection and fake official servers are documented attack patterns. Without a validation pipeline for MCP components, enterprises are inheriting vulnerabilities from packages that were never assessed against enterprise security standards.
The governance required for MCP is not a new framework. It is the application of existing enterprise security and governance disciplines to a new layer of the AI stack. The organisations that manage this well are those that extend their existing AI governance infrastructure to explicitly cover MCP as a governed component of agent architecture, rather than treating it as a developer tool that sits outside the governance perimeter.
The minimum viable governance programme for MCP has four components.
An inventory of every MCP server in the enterprise environment, with the identity it uses, the tools it exposes, who created it, who owns it and what its authorised scope is. This inventory needs to be maintained continuously, not produced on request after an incident.
Authentication and least-privilege access enforced at the MCP server level. OAuth 2.1 with defined scope constraints. Per-operation authorisation rather than broad standing access. Access requests treated under the same zero-trust principles applied to other enterprise systems. Trusenta's Risk Management module provides the AI-specific risk taxonomy to assess and document MCP-level access risks with treatment plans linked to specific controls.
Immutable per-operation audit logging that captures every trigger, input, decision and action taken through MCP integrations. In regulated environments, this logging is the foundation of both incident investigation and regulatory compliance demonstration.
A structured intake and review process for new MCP integrations before they go live. The intake process that stops shadow AI at the source, built into Trusenta's AI Governance platform, applies directly to MCP: every new integration registered, assessed against the governance framework and approved before deployment rather than discovered after an incident.
MCP governance has specific Australian regulatory implications that risk teams in financial services, healthcare and government need to understand explicitly.
When an AI agent retrieves a customer record through an MCP integration, that is a Privacy Act data access event. When that agent takes action on the record, it may constitute a substantially automated decision affecting an individual, bringing it within the scope of the Privacy Act ADM obligations arriving in December 2026. The compliance infrastructure for those obligations, the AI system inventory, the data access documentation and the accountability structures, must extend to MCP integrations.
For APRA regulated entities, the accountability expectation is clear: the regulated entity cannot contract accountability for AI-driven outcomes to a vendor's MCP implementation. If a third-party MCP server is compromised and customer data is exfiltrated, or if an AI agent operating through MCP makes an unauthorised decision, the accountability stays with the licence holder.
AI Governance: Trusenta's AI Governance platform provides the use-case intake and registry infrastructure that brings MCP integrations under systematic governance before deployment, creating the inventory and accountability documentation that is the foundation of enterprise MCP security.
Risk Management: Trusenta's Risk Management module provides the AI-specific risk taxonomy and treatment plan documentation to assess MCP-level risks, including prompt injection, privilege escalation, supply chain exposure and audit logging gaps, with controls linked to specific treatment actions.
AI Governance Maturity Uplift: For organisations that have foundational AI governance in place but have not yet extended it explicitly to cover MCP and agent connection infrastructure, this engagement designs and implements the governance framework extension before an MCP security gap becomes a regulatory or operational incident.
MCP is not going away. The standard is becoming the universal connection layer for enterprise AI, and the organisations that govern it well will deploy AI faster and more safely than those that treat it as a developer tool outside the governance perimeter. The governance required is not complex: inventory, authentication, least-privilege, audit logging and a structured intake process. These are disciplines every enterprise already applies to other critical infrastructure. Extending them to MCP is the decision that separates organisations that get ahead of this risk from those that manage the consequences of it.
