The MCP specification has a well-specified answer to authorisation: the OAuth 2.1 flow with PKCE, plus five mandatory patterns (per-client consent, token audience validation, rejection of token passthrough, exact redirect URI matching, and OAuth state validation). Deployed reality diverges from it. Scans of thousands of live servers keep landing on the same picture: around 40% run with no authentication, 53% sit on static keys that never expire, and 8.5% use OAuth. If your team has stood up MCP servers, the odds are they fail the spec’s mandatory requirements, and a policy document won’t tell you.
That gap is what an MCP governance programme exists to close: the organisational wrapper of policy, roles, controls and evidence sitting on top of your server inventory, applying zero-trust thinking to a principal your existing controls were never built for. That principal is an autonomous model making stateful tool calls whose risk lives in tool descriptions and reasoning chains, above the HTTP layer where your WAF and gateway operate. Three lenses follow. Each answers a different governance question, and together they sit inside the MCP security overview that runs from adoption to containment.
How do I assess whether our MCP servers meet the spec’s mandatory authorisation requirements?
Treat conformance as a probability you have to evidence. The MCP Authentication Gap is your prior: unless your inventory proves otherwise, assume your failure rate tracks the ecosystem average of 40% unauthenticated, 53% on static keys, and 8.5% on OAuth. The spec lists five authorisation patterns that must hold: per-client consent, token audience validation, rejection of token passthrough, exact redirect URI matching, and OAuth state validation. Your job is to find evidence each one actually holds across your estate.
So what counts as proof? An observed OAuth flow with PKCE, aud claims bound to your server’s identifier, a live per-client consent registry, and no long-lived static keys. A general user login does not authorise a specific client to act on their behalf, and consent has to be validated server-side because malicious clients bypass client-side checks. A server that skips these controls becomes a confused deputy: a stolen token turns it into a proxy for exfiltration, since one session inherits every tool granted at start. Default to non-conformance until the evidence says otherwise.
What should an MCP governance programme require: which tool categories, under what authentication and sandboxing rules?
Once you accept that most of your estate is non-conformant, the question becomes what to require of each server, which is where tiering earns its keep. The value of a programme is tiering: sorting servers by blast radius and volatility, then matching each to a control tier sized to its risk — the practical core of securing MCP across an organisation.
Which tool categories belong in which tier
Tier 1 is safe by default: read-only lookups over public or low-sensitivity data (public documentation lookups, for instance), still authenticated and audience-bound. Tier 2 covers internal data, needing OAuth 2.1, per-client consent and scope minimisation. Tier 3 covers write access or arbitrary code execution, demanding sandboxing and process isolation: containers, gVisor or Kata, read-only filesystems, an egress allowlist, and human-in-the-loop approval for high-impact actions. A central gateway is the single enforcement point for authentication, provenance and policy, and the layer where you contain blast radius.
Continuous monitoring versus one-time review
Route each server by four signals: volatility, data sensitivity, blast radius and CVE/NVD history. A read-only internal lookup that rarely changes can pass a one-time review. Anything with write access to sensitive data, or a recent CVE, defaults to continuous monitoring. The CVE record makes this concrete: more than 30 CVEs hit MCP servers and clients in early 2026, and 43% of them were shell injection. A server can change its risk profile between review cycles, so pin third-party servers to a verified version and watch for rug pulls.
The audit trail you should expect
Every tool call should be logged with identity, full parameters, the policy decision, and a correlation ID tying the call back to its session. The native MCP log format lacks identity, correlation IDs and policy decisions, so you detect absence by testing a known call end to end. If you cannot reconstruct who called which tool, under what consent, the logs have gaps that will also hide every other control failure. Shadow servers you never registered cannot be tiered or monitored, which is why continuous discovery is the evidence base everything else leans on. Missing logs and unregistered servers are what regulatory exposure is made of.
How do I tell whether MCP use creates a regulatory exposure in a FinTech or HealthTech context?
If you operate in a regulated sector, exposure arises the moment your FinTech and HealthTech obligations meet a principal whose tool calls conventional controls cannot see. The mapping is straightforward: the authentication gap becomes access control and least privilege, tool poisoning becomes data handling and integrity, a missing audit trail becomes breach reporting, and an unvetted server becomes third-party risk.
In Australia, the test question to keep in front of your leadership is simple: can you evidence who or what accessed regulated data, under what consent, and report a breach within the statutory window? That means the Australian Privacy Principles and the Notifiable Data Breaches scheme, which gives you 30 days to assess a suspected breach. For APRA-regulated entities, CPS 234 and CPS 230 extend information-security and third-party expectations to AI, and APRA expects boards to hold AI literacy and will pursue enforcement where AI risk goes unmanaged.
HealthTech sharpens this further: health data carries consent and secondary-use restrictions, and audit obligations apply whether the access was human or agentic. Frame all of this strictly as exposure identification, which is distinct from legal advice. Your job is to name the obligations at risk and the evidence you cannot currently produce.
Wrapping up
The three lenses are one system: conformance, tiering and regulatory exposure are the same accountability problem viewed at three levels of zoom. What binds them together is Zero Trust for Agentic AI: never trust the non-human principal, verify every call. That is the principle that turns a technical gap into something you can prove to a board — and the thread running through governing MCP across the stack.
Frequently Asked Questions
Why does a well-designed MCP authorisation model still leave us with regulatory exposure?
Because the exposure does not come from the specification; it comes from the distance between what the spec mandates and what your deployed servers actually do. The MCP Authentication Gap shows most servers run unauthenticated or on static keys, so mandatory patterns like OAuth 2.1 with PKCE and token audience validation are simply not enforced. That gap is what a regulator sees.
Do we really need an MCP governance programme, or is our existing API gateway and WAF enough?
An MCP governance programme is a wrapper, not a replacement, so keep the gateway and WAF. They cannot inspect what makes MCP risky: tool descriptions, schemas and reasoning chains above the HTTP layer. A gateway sees a request; it cannot tell whether a tool was poisoned or whether an agent acted under valid consent. Governance supplies the policy, roles and evidence those controls cannot.
Is the MCP Authentication Gap just an ecosystem statistic, or should I assume it applies to us?
Treat it as your prior probability of failure. The ecosystem figures (40% unauthenticated, 53% on static keys, 8.5% on OAuth 2.1) describe an average, and unless your MCP Server Inventory proves otherwise, the defensible assumption is that you sit near it. Conformance is a probability problem, so the burden sits on evidence, not on vendor assurance.
How should I decide which MCP servers warrant continuous monitoring versus one-time review?
Route each server by four signals: volatility, data sensitivity, blast radius and CVE/NVD history. A read-only internal lookup that changes rarely can pass a one-time review. Anything with write access to sensitive data, recent CVEs or a history of urgent patches defaults to continuous monitoring, because its risk profile can change between review cycles.
What audit trail should I expect from an MCP deployment, and how do I detect when it’s missing?
Every tool call should be logged with identity, parameters, the policy decision and a correlation ID that ties the call back to the originating session. You detect absence by testing a known call and following it end to end; if you cannot reconstruct who called which tool, under what consent, the native MCP logs have gaps that will also hide every other control failure.
What actually happens when an MCP server is compromised?
The realistic outcome is a confused deputy: an attacker leverages the server’s trusted position to hand authorisation to the wrong principal, or a poisoned tool description quietly redirects a legitimate agent. Because the call arrives with valid credentials and a plausible schema, conventional controls rarely flag it. The damage lands in regulated data actions, not in an obvious intrusion alert.
How do I vet a third-party MCP server before we adopt it?
Demand evidence, not marketing. Look for a demonstrated OAuth 2.1 flow with PKCE, audience-bound tokens and per-client consent; a maintained CVE/NVD record; clear data-handling and retention terms; and contractual audit and incident-notification rights. An unvetted server is third-party risk with write access, so treat it as you would any critical supplier.
Is token passthrough a real governance problem or just a protocol design choice?
It is a governance problem. The specification mandates rejecting token passthrough precisely because a server that accepts a token minted for another service breaks the audience binding that makes authorisation meaningful. From a governance view, passthrough erases the audit trail of who authorised what, leaving you unable to prove least privilege or reconstruct an incident.
How much MCP governance does a 100-person company actually need?
Less ceremony, but the same controls. A smaller estate still needs an inventory, tiering by blast radius, authentication against the mandatory patterns and an audit trail; what scales down is the review cadence and the number of approvers. The minimum defensible programme is the one that can evidence who accessed regulated data and under what consent, sized to your risk.
Which Australian obligations should a FinTech or HealthTech CTO map MCP risk to?
Map protocol failures onto obligations you already carry, not a new MCP law. The Australian Privacy Principles and the Notifiable Data Breaches scheme govern consent and breach reporting; APRA’s prudential framework, including CPS 234 and CPS 230, extends information-security and third-party expectations to AI, and SOCI reporting applies to critical infrastructure. Name the obligations at risk and the evidence you cannot produce.
How do I discover MCP servers we didn’t stand up deliberately?
Shadow MCP servers appear when teams connect tools without a register, so discovery has to be continuous. Watch egress traffic for MCP protocol patterns, scan for exposed endpoints and static keys, and reconcile against your sanctioned inventory. An MCP Server Inventory and Discovery process is the evidence base every other control depends on, and unregistered servers are the ones you cannot tier or monitor.
Does MCP need its own identity system, or can we extend our existing IAM?
Extend what you have, but confront what it was not built for. Existing IAM governs human and service principals; MCP introduces an autonomous, non-human principal making stateful tool calls, so extend it with short-lived scoped tokens, per-client consent and per-tool authorisation. Zero Trust for Agentic AI means you never trust that principal and verify every call.
