The Model Context Protocol (MCP) arrived from Anthropic in November 2024 as an open standard for connecting agents to tools and data. Fourteen months later its registry had grown from roughly 1,200 servers to more than 9,400, a seven-fold jump that outpaced the security model.
A protocol whose specs assume human consent now runs against autonomous workloads where no human is present to approve. Roughly 40% of internet-exposed servers accept requests with no credential check; of those that authenticate, 53% rely on static API keys and only 8.5% implement the OAuth 2.1 model the spec mandates.
GitGuardian found 24,008 secrets in public MCP config files, 2,117 still valid, and more than 30 CVEs against MCP servers and clients in early 2026 — prompt injection a delivery mechanism, not the vulnerability.
This page is a map, not a manual: each section summarises the what and the why and routes you to the article with the substance.
The series runs end to end — from why MCP’s authorization model assumed human consent through the attack classes and credential failures to how to contain MCP supply chain risk and the governance questions above it.
How did MCP’s authorization model come to assume human consent?
MCP shipped as a developer-first standard for connecting agents to tools, and its authorization specification inherited the interactive consent flows of desktop use. Deploy those flows against autonomous workloads — where no human is present to approve — and the assumption quietly breaks. Marking authorization optional lowered adoption friction, and that decision planted the gap you now have to close.
OAuth 2.1 was a hardened, deliberate choice, but client registration is still open. The spec leaned on Dynamic Client Registration, which asks servers to manage a database of self-asserted clients, while the community shifts toward Client ID Metadata Documents, a static file clients host for verification; server-side request forgery during that metadata discovery is your early failure point, with the official security best practices as your canonical reference.
Read how MCP’s authorization model came to be for the backgrounder.
What are the MCP-specific attack classes, and why do conventional scanners miss them?
Tool poisoning, rug pulls, cross-server tool shadowing and state handle hijacking attack the model’s reasoning about trusted tool definitions, not memory safety or dependencies. Conventional scanners inspect static artefacts, so they miss malicious instructions embedded in tool descriptions or schemas. Treat these as runtime trust failures that demand MCP-native detection, not the CVE classes your SAST and SCA tooling covers.
Traditional vulnerabilities live in code a scanner can inspect; MCP’s risk lives in tool descriptions, strings the agent reads as trusted instructions. Tool poisoning is a form of indirect prompt injection: as Check Point framed at Black Hat USA 2026, the instruction rides into context as guidance. Rug pulls redefine a tool after consent, shadowing lets one server steer a trusted one, and state handle hijacking abuses handles across stateless boundaries.
The full taxonomy lives in the MCP-specific attack classes.
Why do credential and consent failures dominate real MCP deployments?
The confused deputy problem and forbidden token passthrough both stem from credentials that cross trust boundaries, and static API keys remain the default in most deployments. Roughly 53% of authenticating servers rely on them, while only 8.5% implement the OAuth 2.1 model the spec mandates. Credential handling — audience binding and scope minimisation — is your highest-probability failure, well ahead of exotic AI attack.
A confused deputy is a proxy or consent handler induced to act for the wrong client; token passthrough forwards a token beyond its intended audience. Both trace back to the spec’s audience-binding and scope-minimisation expectations being ignored. Static keys win because they are easy; the cost is the secrets sprawl above, which feeds the state handle hijacking in the attack classes.
Read the full analysis in credential and consent failures in MCP.
Where does MCP supply-chain exposure come from, and does a gateway actually contain it?
MCP’s STDIO transport trusts local process execution: it launches each server as a subprocess and reads the command from a config file, turning every configured server into a supply-chain link. That is the pattern CVE-2025-6514 in mcp-remote exposed — “the mother of all AI supply chains“, as one researcher put it. Config files in Cursor, Windsurf and Claude Desktop accumulate secrets, so inventory is the precondition for control.
A gateway centralises authentication and egress control, shrinking blast radius and beating direct connections on visibility, but it concentrates risk into one point and adds friction. The honest question is where that single point of failure should live. The split: own inventory, policy and audit, buy scanner coverage and gateway infrastructure.
Work through the trade-off in MCP supply chain exposure and containment.
What should an MCP governance programme actually require?
A credible programme tiers your MCP servers by tool category, demanding authenticated, audience-bound access for sensitive tools and sandboxing or process isolation for those that touch private data. It treats the authentication gap as the prior probability of failure and converts it into inventory, audit trail and continuous monitoring. You are deciding which servers warrant continuous review, and whether any use creates regulatory exposure in FinTech or HealthTech.
Assess with a conformance lens. Test authentication posture against the spec’s mandatory authorization requirements, and route each server into continuous monitoring or one-time review by volatility, data sensitivity, blast radius and CVE history. Translate failures into regulatory language: data handling, consent, breach reporting and third-party risk. In Australia that means inheriting the Privacy Act and APRA/ASIC expectations, with no standalone AI law.
See what an MCP governance programme must cover and where regulatory exposure arises.
What evidence should you demand before an agent touches regulated data?
Demand audience-bound OAuth 2.1, scope minimisation, audit-trail guarantees and a verifiable incident and CVE history — and treat their absence as the default expectation, not a worst case. Before you grant an agent access to production financial or regulated data, weigh MCP’s ecosystem against the maturity of PyPI and NPM, and ask whether the vendor’s evidence survives independent verification or rests on marketing claims.
Zero-trust logic for agentic AI raises the bar above human-access evidence. PyPI and NPM reached their controls only after well-publicised incidents; MCP inherits some of that and lacks the rest, so newer and worse are different claims. Match any vendor assessment against your governance requirements and containment plan.
The evidence bar is in assessing MCP vendors and ecosystem risk.
Resource Hub: MCP Security Deep Dives
Understanding the Landscape
- How the Model Context Protocol Authorization Model Assumed Human Consent: how the protocol baked in human-consent assumptions.
- Tool Poisoning, Rug Pulls and the MCP Attack Classes Conventional Scanners Miss: the four attack classes and why scanners miss them.
- Confused Deputies, Token Passthrough and the Credential Failures in MCP Deployments: why credentials crossing trust boundaries dominate.
Containing the Risk
- MCP Supply Chain Exposure and the Gateway Layer That Contains Blast Radius: where supply-chain exposure comes from and whether a gateway contains it.
Governing and Assessing
- What an MCP Governance Programme Must Cover and Where Regulatory Exposure Arises: turning protocol risk into policy and assurance.
- Assessing MCP Server Security, Vendor Evidence and Ecosystem Risk: the evidence to demand before an agent touches regulated data.
Suggested reading order: start with the origin story, then the attack classes and credential failures, then containment, then governance and vendor evidence.
Frequently Asked Questions
Is MCP inherently insecure, or is the problem how organisations deploy it?
MCP is not inherently insecure; the gap sits between a spec written for human-supervised use and deployments that run unsupervised. The protocol marked authorisation optional to speed adoption, so the burden shifts to how you configure it. When 40% of exposed servers accept unauthenticated requests, that is an implementation choice, not a flaw in the standard itself.
What is prompt injection in MCP, and does it need a code vulnerability to work?
Prompt injection is malicious instruction text an agent reads as trusted, and it needs no code vulnerability to succeed. In MCP, the payload often hides in a tool description or schema, which the model treats as legitimate guidance. That is why Check Point called prompt injection the delivery mechanism rather than the vulnerability, a distinction conventional scanners struggle to act on.
How do I find out which MCP servers my organisation is already running?
Start with the config files, because that is where MCP servers are declared and launched. Cursor, Windsurf and Claude Desktop each hold configuration that lists every server, its command and often its credentials. Build that inventory first: you cannot tier, authenticate or monitor servers you do not know exist, and secrets sprawl makes the same files a liability.
What happens if a trusted MCP server turns malicious after I approve it?
That is a rug pull: the server behaves during consent, then redefines its tool definitions or behaviour afterwards. Approval is a snapshot, not a guarantee, so the risk persists for the life of the connection. MCP-native detection that watches for changed descriptions and unexpected tool behaviour closes the gap that one-off review leaves open.
Can my existing SAST, SCA or vulnerability scanners detect MCP threats?
No, not reliably. Conventional scanners inspect static artefacts such as code and dependencies, while MCP risk lives in tool descriptions, schemas and runtime trust decisions they were never built to read. You need MCP-native detection for poisoned semantics, and general-purpose analysis still misses it. Run both, because each catches what the other cannot see.
What is Dynamic Client Registration, and why should I care about it?
Dynamic Client Registration lets an MCP client register itself with a server automatically, trading manual setup for convenience. MCP pairs it with Client ID Metadata Documents, and server-side request forgery first surfaces during that metadata discovery step. If registration stays open, an attacker can enrol a client you never approved, so treat registration endpoints as security-critical.
Does MCP security only matter for internet-exposed servers?
No. Local servers launched over STDIO are a supply-chain link in their own right, because each one runs as a subprocess reading its command from a config file. CVE-2025-6514 proved that a local design decision carries real exposure. The 40% unauthenticated figure describes internet-facing servers, not the whole risk surface.
Are static API keys ever good enough for an MCP server?
Rarely, and never for anything touching sensitive tools or data. Static keys are long-lived, hard to scope and easy to leak, which is exactly why 24,008 secrets turned up in public MCP config files. The spec mandates OAuth 2.1 with audience binding and scope minimisation, so static keys should be a temporary crutch rather than the default.
Which MCP servers should I secure first if I cannot fix everything at once?
Tier them, then start with the highest-consequence. Rank servers by volatility, data sensitivity, blast radius and CVE history, and require authenticated, audience-bound access for anything touching sensitive tools. Servers that reach private data or run with broad permissions come first; low-risk, read-only tools can wait. Let exposure, not ease, set the order.
Can I run MCP servers safely by sandboxing or containerising them?
Sandboxing helps, but it is a containment control rather than a cure. Process isolation limits what a compromised server can reach, which matters because STDIO launches each server as a local subprocess. It does not stop a poisoned tool description from misleading the agent, so pair isolation with MCP-native detection and least-privilege credentials.
How do I brief a board or auditor on MCP risk without overclaiming?
Translate protocol failures into the language they already govern: data handling, consent, breach reporting and third-party risk. In Australia that means the Privacy Act plus expectations from APRA and ASIC, not a new regime. Lead with the authentication gap as a prior probability of failure and show the inventory, audit trail and monitoring you have in place.
Will today’s MCP security controls still be valid in a year?
Partly, and the fundamentals will outlast the specifics. The ecosystem is young and changing quickly, with more than 40 CVEs in early 2026 alone, so exact tooling will keep shifting. Controls built on inventory, audience-bound authentication, least privilege and audit trails survive the churn. Treat MCP security as a programme, not a one-time fix.
