Most APRA-regulated entities that have deployed AI agents with MCP connectivity have not assessed those connections under CPS 230.
That is not a security observation. It is a governance one.
The service-provider catch-up deadline is 1 July 2026.
In early 2026, the Model Context Protocol supply chain became a board-level conversation for security teams.
The numbers are uncomfortable: approximately 200,000 vulnerable MCP instances identified by OX Security in April 2026, a 60–72% tool-poisoning success rate on the MCPTox benchmark, and ASI04 — Agentic Supply Chain Vulnerabilities — named in the OWASP Top 10 for Agentic Applications 2026.
Most of the commentary has focused on the security risk.
That is the right first instinct.
But for APRA-regulated entities, there is a second problem that has received almost no attention.
When you wire an AI agent to an MCP server — internally built or third-party — and that agent interacts with a critical operation, you may have just added a service provider to your CPS 230 register without realising it.
Disclaimer: This article is for general information and commentary only. It is not legal advice, regulatory advice, or a recommendation to act in any particular way. Regulatory interpretation depends on your entity type, licence, and circumstances. Engage qualified legal and regulatory advisers for compliance decisions.
What CPS 230 says about service providers
Under CPS 230, a service provider is any third party that provides services to a regulated entity. A material service provider is one whose failure or disruption could have a material impact on the entity’s ability to maintain a critical operation or manage operational risks effectively.
The obligations for material service providers are specific:
- Contractual controls — service levels that map to the entity’s tolerance levels, APRA access rights, audit rights, and subcontracting restrictions
- Concentration risk — identifying where multiple critical operations depend on a single provider, and managing the exposure
- Exit and contingency arrangements — credible plans for what happens if the provider becomes unavailable or must be replaced
- Ongoing oversight — not a one-time assessment but a continuing view of whether the provider relationship remains within tolerable risk
Most CPS 230 programs have mapped traditional service providers: cloud infrastructure, payment platforms, core banking systems, custody services.
Most have not mapped MCP servers.
Why MCP servers are a service provider question
The Model Context Protocol is how an AI agent finds and calls tools — databases, file systems, APIs, internal services, SaaS platforms.
In a simple deployment, the topology looks like this:
Agent ──► MCP Server ──► Tool / API / DataIf the MCP server is hosted externally — by a vendor, a platform provider, or a public registry — it is a third-party service that the agent depends on to function.
If that agent is embedded in a critical operation — a fraud detection workflow, a customer hardship assessment, a payments exception handler, an onboarding process — then the MCP server is a service provider in the CPS 230 sense.
Whether it is a material service provider depends on the same test as any other: could its failure or disruption materially impact the entity’s ability to maintain the critical operation?
For an agent that handles operational decisions at scale, the answer is often yes.
The three specific gaps
Gap 1: The service map does not include MCP connections
Most critical operations registers and service maps were built before AI agents were deployed in production.
MCP connections were added later — sometimes by engineering teams during development, sometimes when a third-party AI platform was onboarded, sometimes when a developer tool acquired AI features that were not originally there.
The result is that many service maps show the AI platform as a service provider, but do not show the MCP servers that platform connects to, or the tools and APIs those servers expose.
That is the same topology gap the industry discovered with SaaS supply chains in 2018–2020.
The answer then was to build software bill of materials discipline into procurement. The answer now is to build MCP connection inventories into the critical operations register.
Gap 2: The MCP trust model has no gate
Anthropic has declined to patch the root-cause trust problem at the protocol level. The MCP trust model is “by design” open: tool descriptions are instructions the agent uses to decide what to do, and there is no protocol-level validation that a tool description is accurate or safe.
For a security team, this is an attack surface problem.
For a CPS 230 team, it is a different question: if the entity cannot validate what an MCP server says it does, how does it assess the operational risk of connecting an agent to that server in a critical workflow?
APRA expects entities to understand the risks created by service providers, including concentration risk and failure modes. An MCP server whose behaviour cannot be independently validated creates a risk that is hard to quantify and harder to attest.
This is not theoretical. The OWASP Top 10 for Agentic Applications has named agentic supply chain vulnerabilities specifically because the risk of malicious or misconfigured MCP servers is now measurable.
Gap 3: Concentration risk is invisible
Most AI agent deployments in regulated financial services run through a small number of foundation model providers and AI platforms. Those platforms often act as MCP hubs — they host or proxy connections to multiple MCP servers.
The result is that a single AI platform relationship may carry concentration risk across many critical operations simultaneously.
CPS 230 requires entities to identify and manage concentration risk. For most teams, the concentration risk view stops at the AI platform level. It does not extend to the MCP server layer underneath.
That means the full concentration risk profile is not visible.
What a compliant MCP deployment looks like for CPS 230
The answer is not to avoid MCP. It is to govern it with the same discipline applied to any other service provider in a critical operation.
| CPS 230 requirement | What it means for MCP |
|---|---|
| Service provider identification | Every MCP server that an agent uses in a critical operation is catalogued, with provider, hosting, version, and update cadence |
| Materiality assessment | Each MCP connection assessed: could loss of this server materially affect the critical operation? |
| Contractual controls | For third-party MCP servers: service levels, APRA access rights, audit rights, subcontracting visibility |
| Concentration risk | Cross-critical-operation view of which MCP servers are shared dependencies |
| Exit and contingency | What does the agent do if the MCP server is unavailable? Fallback tested, not just documented |
| Ongoing oversight | Version changes, provider changes, and server configuration changes treated as operational change events |
For internally built MCP servers, the obligations shift from vendor management to internal governance: the server needs to be owned, versioned, change-controlled, and included in recovery planning.
The catch-up deadline is the pressure point
The CPS 230 service-provider catch-up deadline is 1 July 2026.
Pre-existing service-provider relationships — including AI platform relationships that include MCP connectivity — need to be within scope by that date.
For most entities, the question is not “do we have MCP servers we haven’t disclosed to APRA.” It is “have we assessed our AI agent deployments against the material service-provider obligations, and do we have the evidence CPS 230 requires?”
The honest answer for most programs is no.
Not because the teams are negligent. Because MCP became production-grade faster than governance frameworks anticipated.
The gap is closable. But it requires treating AI agent architecture as an operational risk question, not just an engineering one.
The practical checklist
If you are an engineering or operational risk leader at an APRA-regulated entity with AI agents in production:
- Inventory every MCP server your agents connect to — internally built, vendor-hosted, and public registry.
- For each one, identify whether it is used in a process that touches a critical operation.
- Assess materiality: could loss of this server affect the critical operation?
- For material third-party MCP servers: review contracts for CPS 230 obligations — service levels, APRA access, audit rights, subcontracting.
- Map cross-operation concentration: how many critical operations share the same MCP server or hosting provider?
- Document fallback: what does the agent do without the server? Is manual fallback tested at realistic volume?
- Add MCP connections to the operational change management process: version updates, configuration changes, and provider changes require review.
This is not a separate compliance project. It is the CPS 230 service-map update that AI agent deployments require.
The point
MCP is not a security problem that is separate from regulatory compliance.
For APRA-regulated entities, it is a compliance problem with a security dimension.
The service-provider catch-up deadline, the APRA AI governance letter, and the growing MCP attack surface are arriving at the same time.
That is not coincidence. It is what happens when a new protocol class — AI agent tool connectivity — grows faster than the governance frameworks built to manage it.
The firms that close this gap will not just satisfy a compliance checklist.
They will build the governance infrastructure for AI agent deployment that the next decade of regulatory scrutiny will be built on top of.