Threat model
MCP security
MCP security is the problem of connecting Model Context Protocol servers to agents without handing an untrusted third party a seat inside your trust boundary. The protocol is a transport; the risk is that tool definitions are themselves model-visible text, and that an installed server usually inherits the agent's full context. Threat model and vetting checklist below.
Why MCP is a distinct security problem
Installing an MCP server feels like installing a package. The comparison is misleading in one specific way, and the whole threat model follows from it:
A library exposes functions to your code. An MCP server exposes tool descriptions to your model — and those descriptions are natural language that the model reads and acts on, arriving from a party you do not control.
Three consequences that have no equivalent in conventional dependency management:
- The attack surface includes prose. A tool's name, description and parameter documentation all enter the model's context. They can contain instructions. Static analysis of the server's code does not inspect the thing that reaches the model.
- Installation grants context, not just capability. In most client implementations, an installed server can see what is in the conversation — including content and credentials that arrived from other tools.
- The definition can change after review. A server that was benign when you approved it can serve different tool descriptions later, with no version bump and no reinstall. Package pinning does not address this, because the definition is fetched at connection time.
The threat model
Eight failure modes. The first three are specific to how MCP works; the rest are general agent risks that MCP makes materially easier to reach.
| Threat | How it works | What blunts it |
|---|---|---|
| Tool poisoning | Instructions embedded in a tool description, parameter doc or error message, read by the model as guidance | Review the rendered definitions, not the repo; diff them on every connection |
| Rug pull | Definitions change after approval; the reviewed version is not the running one | Pin and hash definitions; alert on change; re-approve |
| Tool shadowing | A malicious server defines a tool whose name or description causes the model to prefer it over a legitimate one | Namespace tools per server; surface which server served a call |
| Cross-server context leakage | Server A sees data that arrived via server B because both share the conversation | Separate agents per trust domain rather than one agent with many servers |
| Token passthrough | A server is handed a token scoped more broadly than the task, or one issued for a different audience | Per-server credentials at minimum scope; never reuse a user's primary token |
| Confused deputy | Server acts with the agent's privilege on behalf of a caller holding less | Delegated identity; authorise against the caller's rights |
| Unbounded action | A tool marked read-only performs writes, or accepts a parameter that widens its scope | Enforce outside the server — its own claims are not a control |
| Supply chain | Server is a thin wrapper over a remote service; the real dependency is invisible | Ask where it runs and what it calls; treat as a fourth party |
Cross-server context leakage is the one that surprises people. A finance server and a web-fetch server connected to the same agent are not isolated from each other in any meaningful sense — content fetched by one can influence the model's use of the other, and data retrieved by one is present in the context the other sees. The isolation boundary is the agent, not the server. If two tool sets should not see each other's data, they need two agents.
The 22-point pre-install checklist
Written to be worked through by a reviewer in about forty minutes. Anything failing a bolded item should not be installed against production credentials.
Provenance (5)
- Who publishes it, and are they identifiable as a legal entity?
- Is the source available, and does the published artefact build from it?
- How long has it existed, and how many independent contributors?
- Is there a security contact and a disclosure policy?
- Is the install source the publisher's own, rather than a mirror or a similarly-named package?
Tool surface (5)
- List every tool it exposes, and read every description as rendered to the model — not as documented in the README.
- Does any description contain imperative language aimed at the model ("always", "before responding", "do not tell the user")?
- Are read and write tools clearly separated, and does each write tool state its scope?
- Do any parameters accept free-form input that reaches a shell, a query, or a URL?
- Are error messages returned to the model constrained, or can a remote service put arbitrary text there?
Credentials and identity (4)
- What credentials does it require, and at what scope? Can it work with less?
- Is a dedicated identity possible, or does it want a user's primary token?
- Where are credentials stored, and are they logged anywhere?
- If it uses OAuth, does it request only the scopes its tools need?
Execution and network (4)
- Does it run locally or is it a wrapper over a remote service? Which endpoints?
- What data leaves your environment, to whom, and under what terms?
- Does it execute code, spawn processes, or touch the filesystem outside a defined directory?
- Is it pinned to a version, and is the definition hashed and checked on connection?
Operational (4)
- Can its calls be logged with arguments, and are those logs retained?
- Can it be rate-limited independently of the agent?
- Is there an enforcement point between the agent and the server, or does the server self-police?
- Which other servers share the agent's context, and is that acceptable?
The two items that catch the most in practice are reading the rendered tool descriptions and asking which other servers share the context. Both take minutes; neither is in most review processes.
Deployment patterns, from safest
Most of the risk is decided by topology rather than by which servers you chose. Four patterns, in order:
| Pattern | Isolation | Use when |
|---|---|---|
| One agent, one trust domain | Strong — nothing untrusted shares context with anything privileged | Default. Separate agents for external content and for privileged systems |
| Gateway in front of servers | Enforcement independent of the server's claims; central logging and rate limits | More than a handful of servers, or any production credential |
| Local-only servers | No third-party egress, but no isolation from the agent's context | Filesystem and local tooling. Does not address tool poisoning |
| Everything on one agent | None | Prototyping, with no production credentials and no confidential data |
The split that matters most: an agent that reads untrusted external content should not also hold write access to a system of record. That single separation removes the most common end-to-end path, and it costs one extra agent.
Monitoring an installed server
Review is point-in-time and the rug-pull threat is specifically about what happens afterwards. Four things worth watching, all cheap once the gateway exists:
- Definition hash on every connection. Hash the full tool list — names, descriptions, schemas — and alert on any change. This is the single control that addresses rug pulls, and nothing else does.
- Calls against declared surface. A server making calls no tool description accounts for is either misdocumented or doing something else.
- Argument content. Log what is passed. Data classes you did not expect to reach a third-party server show up here first.
- Rate and timing. A server that is quiet during review and active at 3am is worth a look.
The first one is the one to implement if you implement one. A reviewed-then- changed server defeats every part of the checklist above, and a hash comparison is a few lines in the connection path.
Where each control has to live, and how Agent Trust Cloud does it
A pattern runs through the whole threat model above: almost every control fails if it is implemented inside the thing it is meant to constrain. A server that says its tool is read-only is making a claim, not offering a guarantee. A definition hash computed by the server whose definitions you are checking is worthless. These controls have to sit between the agent and the server.
That position is what Agent Trust Cloud occupies — a decision point in the tool-call path. Mapping the eight threats onto it, so it is visible which parts are product and which are still your process:
| Threat | What has to enforce it | In Agent Trust Cloud |
|---|---|---|
| Tool poisoning | Something reading the rendered definitions, not the repo | An approval path from discovery through publisher verification, tool inventory, permission analysis and risk score sits in MCP Security; prompt injection defence covers instructions arriving through tool responses |
| Rug pull | A hash of the full definition set, compared on every connection | MCP Security does permission drift detection — a server that quietly adds a capability it did not ship with surfaces as an event. Worth confirming with them whether that covers description text as well as tool grants |
| Tool shadowing | Per-server namespacing and visibility of which server served a call | MCP Security keeps a server registry with publisher, version and per-tool risk classification — search_files and run_shell are not scored as the same grant |
| Cross-server context leakage | Topology: separate agents per trust domain | Your architecture, not a product feature. The registry shows which servers share an agent, which is usually the first time anyone notices — splitting them is still your call |
| Token passthrough | Per-server credentials at minimum scope | Secrets vault and agent identity — the server gets its own credential rather than a user's |
| Confused deputy | Authorising against the caller's rights, not the agent's | Delegation carries the caller's identity through the chain |
| Unbounded action | A policy check outside the server, at the moment of the call | Runtime gateway with the policy engine — scope, rate and value conditions applied per call |
| Supply chain | Knowing what the server calls downstream | Supply chain records the fourth-party dependency; the audit ledger keeps the evidence |
The row worth reading twice is cross-server context leakage, because no product solves it. Splitting one agent into two is an architectural decision, and a vendor implying otherwise is selling you something. What tooling can do is show you that a web-fetch server and a finance server are sharing one agent's context.
On sequencing: none of this should be switched to blocking on day one. Agent Trust Cloud runs in monitor mode first, so you see which calls would have been refused across a fortnight of real traffic before anything is enforced. That matters more here than elsewhere, because declared and observed tool surfaces diverge more often than teams expect, and finding that out by breaking production is an expensive way to learn it.
What MCP security does not cover
Worth being clear about the boundary, because "we vetted our MCP servers" is sometimes offered as a broader assurance than it supports.
Vetting servers addresses what the agent can reach. It does not address what the agent is permitted to do with what it reaches, which is a permission question, nor what the organisation is accountable for, which is a governance question. An agent connected only to thoroughly-reviewed servers can still refund every customer in the database if nothing caps the action.
The three layers, and they are separate pieces of work:
- Tool surface — which servers, which tools. This page.
- Permission — which actions, under which conditions, enforced where the action happens.
- Governance — who approved the agent existing, against what criteria, with what evidence retained.
Common questions about MCP security
What is MCP security?
MCP security is the practice of connecting Model Context Protocol servers to AI agents without granting untrusted parties influence over the agent or access to data they should not see. Its distinctive feature is that tool definitions are natural-language text the model reads, so the attack surface includes prose, not only code.
What is MCP tool poisoning?
Tool poisoning is embedding instructions in a tool's name, description, parameter documentation or error messages, which the model reads as part of its context and may act on. It is not detected by reviewing the server's source, because the text that reaches the model is what the server serves at connection time.
What is an MCP rug pull?
A rug pull is when a server serves different tool definitions after approval than it did during review, with no version change or reinstall. The defence is to hash the full tool definition set on every connection and alert on any change, since package pinning does not cover text fetched at connect time.
Are MCP servers isolated from each other?
Generally not. Servers connected to the same agent share that agent's context, so data retrieved by one is visible in the context the other operates in. The isolation boundary is the agent, not the server — which means tool sets that should not see each other's data need separate agents.
What should you check before installing an MCP server?
Publisher identity and install source, every tool description as rendered to the model rather than as documented, the credential scope it requires, whether it is a wrapper over a remote service and what data leaves, whether an enforcement point exists between agent and server, and which other servers share the same agent's context.
Does vetting MCP servers make an agent safe?
No. Vetting constrains what an agent can reach. It says nothing about what the agent may do with it, which is a permission question enforced at the point of action, or about who approved the agent and what evidence is retained, which is governance. All three layers are separate work.