Threat model · 16 risks
MCP Security Risks: The Complete Threat Model
Threat models fail by being either exhaustive and unusable or short and reassuring. This one is ranked by how often each risk causes real damage, which puts two non-attacks at the top.
The short answer
MCP security risks span five surfaces: the credential a server holds, the tool surface it exposes, the parameters a model supplies, the content a tool returns, and the supply chain the server came from. Sixteen named risks sit across those surfaces. The two most damaging in practice — excessive credential scope and runaway execution — are not attacks at all, and three risks, all injection-derived, have no clean mitigation at the model layer today. Ranked by observed frequency, with the mitigation that actually holds against each.
Five surfaces
Enumerating risks without a structure produces a list nobody can act on. Every MCP risk we have encountered belongs to one of five surfaces, and knowing the surface tells you which team can fix it.
The credential
What the server can do on its backing system. Determines blast radius for everything else. Owned by whoever owns the backing system, not by the MCP team — which is why it is the slowest surface to fix and the most valuable.
The tool surface
What the server advertises, and to whom. Every exposed tool is capability a persuaded model can attempt. Owned by the server owner.
The parameters
Values the model supplies. The gap between a permitted tool and an unacceptable call. Owned by whoever writes the schema and the policy.
Returned content
What flows back into the model’s context, where it competes with your instructions. Owned jointly, and usually by nobody.
The supply chain
Where the server came from, what it depends on, and what changes when it updates. Owned by whoever ran intake — frequently nobody.
Sixteen risks, ranked
Ranked by observed frequency of real damage rather than by severity in the abstract. Blast radius is the worst case for a typical enterprise deployment; likelihood is our own estimate from what we see.
| Risk | Surface | Likelihood | Blast radius |
|---|---|---|---|
| Excessive credential scope | Credential | Very high | Total: whatever the credential permits |
| Runaway execution / retry loop | Parameters | Very high | Cost, upstream rate limits, repeated side effects |
| Unbounded parameter on a permitted tool | Parameters | High | One call, maximum magnitude |
| Indirect prompt injection | Returned content | High | Any entitled tool, at the attacker’s direction |
| Over-broad tool entitlement | Tool surface | High | Composition of every tool the agent can see |
| Data exfiltration via legitimate tool pairs | Tool surface | High | Everything one tool can read, sent where another can write |
| Shared static credential across callers | Credential | High | Unattributable; no individual revocation |
| Confused deputy | Credential | Medium | Privilege escalation to the service account’s level |
| Tool poisoning via description | Supply chain | Medium | Whatever the described tool can do |
| Tool shadowing / name collision | Supply chain | Medium | Silent redirection to an unintended implementation |
| Schema poisoning | Supply chain | Medium | Parameter coercion; injection through a widened field |
| Unpinned third-party server | Supply chain | Medium | Capability change without review |
| Injection into a downstream interpreter (SQL, shell, path) | Parameters | Medium | Whatever the interpreter can reach |
| SSRF via a URL parameter | Parameters | Medium | Internal network reachability from the server |
| Secret leakage into logs or responses | Returned content | Medium | Credential compromise, often discovered late |
| Replay or duplicate execution | Parameters | Low–medium | Duplicated side effects: double payment, double send |
Two observations from this table. The top two rows are not attacks — they are configuration and operational failures, and they cause more damage than everything below them combined. And five of sixteen sit on the supply-chain surface, which in most estates has no owner at all.
What actually mitigates each
Grouped by the control that does the work, because the same control usually covers several risks — which is what makes prioritisation possible.
Credential scoping
Mitigates excessive credential scope, and reduces the blast radius of every other risk on the list. This is the only control that makes the worst case smaller rather than less likely.
If you do one thing, do this. It is also the slowest, because it needs agreement from whoever owns the backing system rather than engineering time.
Per-identity ceilings
Mitigates runaway execution, and limits the damage rate of injection and over-entitlement. Per identity, never per server, or one runaway agent consumes everyone else’s headroom.
Parameter policy at call time
Mitigates unbounded parameters, downstream injection, SSRF, and replay when combined with an idempotency key. The single largest gap in most estates, because tool-level permission feels sufficient.
Reject rather than clamp. The attempt is the signal, and a clamp deletes it.
Entitlement plus filtered discovery
Mitigates over-broad entitlement, exfiltration via tool pairs, and much of the practical impact of injection. A tool the model never learns exists cannot be talked into existence.
Review entitlement as a set, not tool by tool. Read-customer-records plus send-email is a risk that neither tool has individually.
Per-agent identity with short-lived tokens
Mitigates shared credentials and confused deputy, and makes every other control attributable. Preserve the original caller’s authority rather than collapsing to a service account.
Supply-chain intake
Mitigates tool poisoning, shadowing, schema poisoning and unpinned servers — four of the five supply-chain risks — through version pinning plus description and schema diffing on upgrade.
This is one automated diff covering four risks, which makes it the best effort-to-coverage ratio on the page.
Result handling and write-time redaction
Mitigates secret leakage, and reduces the cheapest forms of injection. Cap response size, neutralise control markup, redact at write time.
Three risks with no clean mitigation
Honest labelling matters more here than anywhere else on the page, because a threat model that implies full coverage is worse than one that admits gaps.
Indirect prompt injection itself. There is currently no reliable way to prevent a model from following an instruction it finds in retrieved content. Detection catches naive cases; nothing catches the general case. What works is containment: the resulting call is refused by entitlement and parameter policy regardless of why it was made. The manipulation succeeds; the consequence does not.
Tool poisoning in a server you cannot audit. If the description is malicious on the day you review it rather than changed later, diffing finds nothing. Reading descriptions adversarially at intake helps; it is a human control with human coverage.
Bad decisions that stay within policy. An agent that issues a refund it should not have, for an amount inside the ceiling, to a legitimate recipient, is a correctness failure and no security control will catch it. This belongs to process quality — see measuring agentic process quality — and conflating it with security produces controls that block legitimate work while missing the actual problem.
The pattern across all three: bound the consequence rather than trying to guarantee the decision. That is the whole strategy, and it is the reason enforcement has to sit outside the model.
Built on this thinking
Six of the seven controls are one enforcement point
BarzelVault holds parameter policy, entitlement, result handling and per-identity ceilings with four deterministic outcomes and hash-chained audit; Barzel Central Gateway holds identity, filtered discovery, routing and supply-chain intake. Both are on the marketplace, and the Gateway has a free tier.
Prioritising in one afternoon
The table above is a menu, not a plan. Four questions turn it into a plan, and all four are answerable from a registry entry.
- 01Which credential is broadest relative to its task? That is your worst case, and it is where to start regardless of what the rest of the table says.
- 02Which tools have unbounded parameters? Sort by mutating tools with no schema ceiling. That list is usually short and alarming.
- 03Which agent can read sensitive data and also write externally? The exfiltration pair. Check every agent, not every tool.
- 04Which third-party servers are unpinned? Pinning is hours of work and closes four risks at once.
Four ways threat models fail
Ranking by severity rather than frequency
Everything looks catastrophic, so nothing gets prioritised, and the two boring configuration risks that cause most damage stay open.
Omitting the supply chain
Five of sixteen risks live there, and it is the surface with no owner. Absence from the model guarantees absence of an owner.
Claiming injection is mitigated
It is contained, not prevented. Overclaiming here is how a control programme loses credibility with the security team.
Treating wrong decisions as security
A correct-but-unwise action is a quality problem. Filing it under security produces controls that block legitimate work.
Frequently asked questions
What are the main MCP security risks?
Sixteen across five surfaces. The most damaging in practice are excessive credential scope and runaway retry loops — neither of which is an attack. Then unbounded parameters on permitted tools, indirect prompt injection, over-broad tool entitlement, exfiltration through legitimate tool pairs, shared static credentials, confused deputy, tool poisoning, shadowing, schema poisoning, unpinned servers, downstream injection, SSRF, secret leakage and replay.
What are the five MCP attack surfaces?
The credential a server holds on its backing system, the tool surface it advertises and to whom, the parameters a model supplies, the content a tool returns into the model’s context, and the supply chain the server and its dependencies came from.
Which MCP risk causes the most real damage?
Excessive credential scope, followed by runaway execution. Neither involves an adversary. A credential broader than its task makes one wrong decision disproportionate, and a retry loop can make hundreds of calls in seconds with real side effects on each.
Can indirect prompt injection be prevented?
Not at the model layer, currently. Detection catches naive cases and nothing catches the general case. What works is containment: the resulting call is refused by entitlement and parameter policy regardless of why it was made, so the manipulation succeeds and the consequence does not.
Which MCP risks have no clean mitigation?
Three. Indirect prompt injection itself, which is contained rather than prevented. Tool poisoning in a server you cannot audit where the description was malicious from the start, since diffing finds no change. And wrong-but-in-policy decisions, which are a process-quality problem no security control will catch.
What single control covers the most MCP risks?
Supply-chain intake — version pinning plus tool description and schema diffing on upgrade — closes four of the five supply-chain risks with one automated diff. Credential scoping has more impact but takes longer because it needs the backing system’s owner to agree.
Why does entitlement need reviewing as a set rather than tool by tool?
Because exfiltration usually needs no exploit. An agent entitled to read customer records and to send email can combine them. Each capability was approved individually; the composition never was, and per-tool review cannot see it.
Is a wrong decision by an agent a security risk?
No, if it stays within policy. An agent issuing an unwise refund inside its ceiling to a legitimate recipient is a correctness failure, and filing it under security produces controls that block legitimate work while missing the actual problem.
Sources and further reading
Risk names are aligned to OWASP’s GenAI and agentic AI taxonomies and to CWE where an equivalent weakness class exists. The ranking, the blast-radius judgements and the honest labelling of unmitigated risks are our own, from operating five MCP servers.
- 01 · OWASP GenAI Security ProjectOWASP GenAI LLM Top 10 (2026) ↗Consensus risk list; excessive agency and prompt injection are the entries governance exists to bound.
- 02 · OWASP GenAI Security ProjectOWASP Agentic AI — Threats and Mitigations ↗Threat taxonomy specific to tool-using agents rather than to chat completions.
- 03 · MITREMITRE ATLAS ↗Adversary technique knowledge base for AI systems, useful for naming what a risk score is scoring.
- 04 · MCP projectModel Context Protocol — specification ↗Normative source for tool schemas, capability negotiation and the authorization model.
- 05 · Simon WillisonPrompt injection — ongoing series ↗The most consistently updated practitioner record of the attack class.
- 06 · MITRECWE — Common Weakness Enumeration ↗Named weakness classes — injection, path traversal, SSRF — that reappear when a model supplies the parameters.
- 07 · NISTNIST SP 800-53 Rev. 5 ↗Access control and audit control families that MCP-layer controls have to satisfy.
- 08 · OpenSSFSLSA — Supply-chain Levels for Software Artifacts ↗Provenance and reproducibility framing for third-party server intake.
- 09 · OWASPOWASP Application Security Verification Standard ↗Input-validation, authorization and logging requirements restated here in MCP terms.
Last reviewed 24 August 2026. External links open in a new tab; we do not control their content.
Try the mechanics on a live server
To watch a real tools/list response before you point a client at anything that governs production — Barzel Scripture Intelligence is free and public at scripture-intelligence-server.mcpize.run: no signup, no key, 54 tools. Setup is in the reference.
Buy it on the marketplace
BarzelVault is the pre-execution decision point, sold as a running product
Nine tools, 12 static resources, 3 resource templates and 9 prompts. Four deterministic policy outcomes — allow, deny, dry-run, require approval — with approval workflow, hash-chained audit and guardrail data protection. Streamable HTTP, JSON-RPC 2.0.
Sold on the MCPize marketplace · prices as listed 2 Sep 2026 · the listing is authoritative
Written by
Mark Alex
Founder of Real Biz Digital and architect of the Barzel ecosystem — five MCP servers published and callable in public. Software developer, technology entrepreneur and mechatronics engineer, working across AI agent governance, MCP security, AI infrastructure, FinOps and intelligent operations.