The protocol you are probably already using

If your organisation uses any AI assistant connected to business data, Microsoft Copilot, Claude, a customer service bot that searches your knowledge base, a coding assistant that reads your repositories, there is a good chance it is connected via the Model Context Protocol.

MCP is the standard that determines how AI agents connect to enterprise systems. It is the plumbing. It is largely invisible when it works, and it is rarely discussed in boardrooms or risk committees. That is a governance problem.

Released by Anthropic in late 2024 and rapidly adopted as a cross-industry standard, MCP was designed to solve a real problem: rather than writing custom integration code for every tool an AI agent needs to use, developers can connect agents to databases, APIs, and internal systems through a standardised interface.

Adoption was fast. By 2025, tens of thousands of MCP servers had been deployed across enterprise environments. In December 2025, the protocol was donated to the Linux Foundation's Agentic AI Foundation, cementing its status as the de facto standard for agent-to-tool integration. Anthropic reports approximately 97 million monthly SDK downloads.

Your organisation is almost certainly already using MCP, or will be shortly. The question is whether you are governing it.

Why MCP creates a distinct governance gap

The governance challenge with MCP is not the protocol itself, it is the way it is typically deployed, and what that means for enterprise risk.

Ungoverned MCP implementations typically grant AI agents broad access to connected systems via over-privileged service accounts, with no per-user authorisation, no per-operation logging, and no sensitivity label enforcement.

This is a precise description of the problem. When an employee connects an AI assistant to their email, calendar, and documents, they are typically approving a scope of access, often without fully understanding what that scope includes or what the AI can do with it. The AI agent then operates with those permissions persistently, across sessions, often as a shared service account that is not attributed to any specific user action.

The least-privilege principle, giving any actor only the access required for their specific task, is fundamental to information security. In MCP deployments, it is routinely violated because agents are more useful with broader access, and the specific scope of access required for a given task is genuinely unclear in advance.

Over time, as additional agents are connected and scopes accumulate, the aggregate access any single MCP-connected system has to enterprise data can be substantial.

The three attack categories

A 2025 academic paper on MCP security, published on arXiv (ref: 2511.20920) and drawing on early incidents and proof-of-concept attacks, identified three categories of adversary specific to MCP environments:

1. Content-injection attackers. These attackers embed malicious instructions into data that the AI agent reads, documents, web pages, database records, email content. When the agent processes this content, the malicious instructions are executed using the agent's own permissions. This is a form of prompt injection that operates at the data layer, not the prompt layer.

2. Supply-chain attackers. MCP servers are distributed packages, and a compromised or malicious MCP server can execute arbitrary code with the permissions granted to the agent. CoSAI's January 2026 whitepaper on MCP security (approved by the CoSAI Project Governing Board) specifically identified shadow MCP servers, unauthorised, unmonitored, or hidden instances, as creating blind spots that increase the risk of undetected compromise and covert data exfiltration.

3. Agents as unintentional adversaries. MCP server developers sometimes implement overly permissive tools, assuming the AI model will invoke them correctly. But models can be manipulated through prompt injection, make errors in judgment, or be replaced with weaker versions that lack the same safeguards. The agent does not need to be malicious to cause harm, it simply needs to act within its permissions in ways that were not anticipated.

The 2026 MCP specification update introduced incremental scope consent, requesting only the minimum access needed for each operation rather than requesting all permissions upfront. This is a meaningful improvement. It does not address existing deployments or the governance practices of the organisations using MCP.

What APRA's AI letter says about this

APRA's 30 April 2026 letter to industry did not mention MCP by name. It did say something more significant: that identity and access management capabilities have not yet adjusted to nonhuman actors such as AI agents.

MCP-connected agents are the primary instance of this gap in enterprise environments today. They are nonhuman actors. They operate with credentials and access rights. They interact with sensitive systems. And in the vast majority of deployments, the governance processes designed for human employees, access reviews, least-privilege enforcement, attribution and logging, offboarding, have not been extended to cover them.

For APRA-regulated entities, this is not a theoretical future concern. It is a current gap in operational risk management, information security controls, and supplier risk management, all areas where CPS 230 and CPS 234 create explicit obligations.

What a governed MCP deployment looks like

The security research and enterprise governance literature is consistent on what sound MCP governance requires. The Veeam analysis of MCP security risks (April 2026) summarised the audit requirements: for every tool call, you need to capture who or what initiated the action, what happened (tool name, parameters, target system, success or failure), what data moved, and any behaviour anomalies including spikes in tool calls, new tools being used, unexpected sequences, or unusual egress.

In practice, governed MCP deployment has five components:

1. A complete inventory of MCP servers. You cannot govern what you cannot see. Every MCP server connected to enterprise systems, whether official, shadow, or vendor-supplied, must be catalogued. This includes who approved it, what systems it connects to, and what access scope it operates under.

2. Least-privilege access scopes. Each MCP server should be granted the minimum permissions required for its specific function. Read-only access where write access is not needed. Access to specific data sets, not entire repositories. Scopes that are reviewed and re-approved regularly, not granted once and left indefinitely.

3. Per-operation audit logging. MCP deployments must log at the operation level, not just the session level. This means recording each tool call, the parameters passed, the data accessed, and the response, with attribution to both the initiating user (if applicable) and the agent.

4. Named ownership. Every MCP server connected to enterprise systems should have a named human owner who is accountable for it. This includes responsibility for reviewing its access scope, monitoring its behaviour, and decommissioning it when it is no longer needed.

5. Vendor / supply-chain governance. Third-party MCP servers, tools provided by software vendors, AI assistants, and SaaS integrations, must be assessed with the same rigour as any other third-party integration. This includes understanding what data they access, where that data goes, and what the vendor's security practices are.

The shadow MCP problem

One of the most significant operational challenges in MCP governance is shadow deployment, MCP servers installed by individual employees or teams without going through any security review or approval process.

This is the AI equivalent of shadow IT, and it is accelerating. The barrier to deploying an MCP server is extremely low: many AI tools install MCP integrations as part of their standard configuration, often without the deploying user understanding that they are creating a persistent, credentialled connection between an AI agent and enterprise systems.

NudgeSecurity's analysis of MCP security (May 2026) noted that each OAuth grant adds another persistent access pathway, often broader than necessary, and that "as additional agents are connected, scope creep accumulates across systems." The aggregate effect of individual employees approving agent access to their email, calendar, shared drives, and project management tools can be a substantial unreviewed exposure.

Governance programs need to address shadow MCP explicitly, including: - Discovery tooling that identifies MCP servers running across the environment - Policies that require IT or security review before MCP server deployment - A review process for existing deployments where no governance record exists

Australian regulatory exposure

For Australian organisations in regulated sectors, MCP governance is not merely a security best practice, it intersects directly with existing compliance obligations.

CPS 230 (Operational Risk Management): Unreviewed MCP integrations create operational risk exposure. If an AI agent connected via MCP malfunctions, causes data loss, or is manipulated to take unintended actions, the resulting incident falls within CPS 230's scope. Adequate operational risk management requires that entities understand and control the systems and integrations that could cause operational disruption.

CPS 234 (Information Security): MCP servers create additional information security risk surface. Each server is a potential vector for data exfiltration, privilege escalation, or injection attack. CPS 234 requires entities to actively maintain their information security capability, which must now explicitly include AI integration points.

The AI inventory requirement: APRA's April 2026 letter requires, at minimum, an inventory of AI tooling and use cases. For any organisation using AI tools connected via MCP, that inventory is incomplete if it does not include the MCP servers those tools use and the access those servers have to enterprise systems.

Privacy Act obligations: AI agents with MCP access to personal information are a personal information handling system for the purposes of the Privacy Act. The Australian Privacy Principles apply, including APP 11 (security of personal information), which requires reasonable steps to protect information from misuse, interference, loss, and unauthorised access.

Getting started: what organisations should do now

Step 1: Discover. Before you can govern, you need to see. Conduct a discovery exercise to identify every MCP server currently deployed in your environment, whether formally deployed by IT, informally deployed by team members, or supplied by vendors as part of their products.

Step 2: Inventory and classify. For each MCP server identified, record: what systems it connects to, what access scope it operates under, who deployed it, and who is responsible for it. Classify each connection by the sensitivity of the data it can access.

Step 3: Review access scopes. Assess each server's access scope against least-privilege principles. Where agents have broader access than their function requires, reduce scope. Where access was granted without adequate review, conduct that review now.

Step 4: Implement logging. Ensure that operation-level logging is in place for all MCP connections, not just session-level logging, but tool-call-level logging that records what the agent did and what data it accessed.

Step 5: Establish governance. Assign named owners to each MCP server. Implement a process for reviewing and approving new MCP integrations before deployment. Include MCP server access in your regular access review cycle.

The alternative, allowing MCP deployments to accumulate without governance, creates the exact condition APRA identified in its April 2026 letter: access and identity management that has not adapted to nonhuman actors, and an AI inventory that does not reflect how AI is actually operating in your environment.

Sources: APRA Letter to Industry on Artificial Intelligence (AI), 30 April 2026 (apra.gov.au); "Securing the Model Context Protocol (MCP): Risks, Controls, and Governance," arXiv 2511.20920; CoSAI Workstream 4, Model Context Protocol Security whitepaper, approved 8 January 2026; TrueFoundry, "MCP Security Risks & Best Practices: Enterprise Guide" (May 2026); NudgeSecurity, "MCP Security Risks" (May 2026); Veeam, "Model Context Protocol Security Risks Explained" (April 2026). This article is general information and does not constitute legal or compliance advice.