The short answer
Security research on the Model Context Protocol has converged on a few findings. Models can be talked into using legitimate MCP tools against the developer who installed them, including running code, opening remote access and stealing credentials, as the MCP Safety Audit paper showed in April 2025.1 Threats span a server’s whole life, from how it’s built to how it’s maintained: one taxonomy lists 16 threat scenarios across four lifecycle phases and four kinds of attacker.2 And public disclosures showed the attacks in practice: instructions hidden in tool descriptions, and a public issue that leaked private repositories.34
The controls that follow are consistent: vet servers before installing, pin and watch their definitions, scope their credentials, and put rules on the calls they make.
Deedglass
A tool call meets your rules before it runs
Asks to run
DELETE FROM visits;
Deletes every row in visits
Deedglass checks your rules
- Reading dataAllowed
- Deleting a whole table (DROP, TRUNCATE)Never
- Changing or deleting rows without saying which (WHERE)This one
- Other changesWait for a person
The MCP Safety Audit
Brandon Radosevich and John Halloran argued that MCP’s design, as then deployed, poses a range of risks to end users. Their central demonstration: industry-leading models could be coerced into using MCP tools to compromise the developer’s own system, through malicious code execution, remote access control and credential theft.1
They also released MCPSafetyScanner, described as an agentic tool that audits an arbitrary MCP server: it generates adversarial samples, searches for related vulnerabilities and fixes, and writes a security report.1 Automated scanning of servers before installation is one of the more practical ideas to come out of this line of work.
A lifecycle threat taxonomy
Xinyi Hou and colleagues took a wider view. They describe an MCP server’s life in four phases, creation, deployment, operation and maintenance, broken into 16 activities, and a threat taxonomy with four attacker types: malicious developers, external attackers, malicious users and plain security flaws. Together these give 16 threat scenarios, illustrated with case studies, and the authors propose safeguards for each phase and category.2
The useful part of this framing is that it separates who can hurt you from when. A malicious developer acts at creation; an external attacker acts during operation, often through data the agent reads; a flawed update arrives at maintenance. Each needs a different control.
Disclosures that shaped practice
Two industry disclosures did as much as the papers to change how people deploy MCP:
| Disclosure | What it showed | Lifecycle phase |
|---|---|---|
| Tool poisoning (Invariant Labs, April 2025) | Instructions hidden in tool descriptions, read by the model and not shown to users; descriptions changed after approval (“rug pull”); one server’s description redirecting another server’s tools3 | Creation and maintenance |
| GitHub MCP (Invariant Labs, May 2025) | A public issue steered an agent into copying private repository data into a public pull request; no bug in the server’s code4 | Operation |
The same research group, with ETH Zurich, also built AgentDojo, which measures prompt injection against tool-using agents by checking the environment’s state afterwards.5 Benchmarks like it are how defences for MCP-style tools get measured.
Why MCP attracted so much research
MCP standardised something that used to be bespoke: how a model discovers and calls tools. That’s good for builders, and it also gives attackers one common surface to study instead of many custom integrations. Three properties made it especially interesting to security researchers.
First, servers are often installed by individual developers from public packages, with the developer’s own credentials, which puts the supply chain and the user’s privileges in the same place. Second, tool descriptions are text the model reads, so the protocol’s own metadata is a channel for instructions. Third, a single agent session often combines several servers, so a weakness in one can be used to misuse another, which is exactly what the shadowing variant of tool poisoning showed.3 Each property maps onto a phase in the lifecycle taxonomy, which is why that framing is a useful way to organise defences.
A map from lifecycle to controls
Combining the taxonomy’s phases with the disclosed attacks gives a practical map:
| Phase | Typical threat | Control |
|---|---|---|
| Creation | A malicious or careless server author | Install from known sources; read the code or tool list; run a scanner1 |
| Deployment | Over-broad credentials; exposed local servers | Scoped tokens; bind local servers to localhost and validate Origin6 |
| Operation | Injected instructions in data the agent reads | Rules on tool arguments; approval for writes that leave the system |
| Maintenance | A changed tool definition after approval | Pin versions; hash definitions and alert on change3 |
The operation row deserves emphasis. The GitHub case had no flawed component to patch: every call was legitimate for the token used.4 That’s why the strongest operational controls limit what calls can do, not what text the model sees.
What research hasn’t settled
- How often real deployments are attacked. Papers and disclosures show what’s possible; there’s little public data on frequency.
- Whether scanners catch reworded attacks. Heuristic detection of hidden instructions can be evaded, as the tool-poisoning disclosure’s own mitigations implicitly accept by recommending pinning and dataflow controls too.3
- How protocol changes shift the picture. The 2026-07-28 revision removed sessions and added headers that mirror the body, with new validation rules; our spec changes post covers them. Research mostly predates it.
Where to start
- Inventory the MCP servers each machine and agent runs.
- Vet new servers before installing: source, code, tool descriptions.
- Pin versions and hash definitions; alert on changes.
- Scope credentials to what each server’s tasks need.
- Put rules and approvals on calls that write or send data out.
- Log every tool call so you can reconstruct an incident.
Our MCP server security basics post goes deeper on items 1 to 4; tool poisoning and the GitHub MCP case cover the two disclosures; an MCP gateway is where items 5 and 6 usually live. To see rules decide calls on a real database in your browser, try the playground; to list the MCP servers your machine is set up to run and grade them, use npx deedglass scan (the grade, explained).
Written with AI assistance and checked against our claims register.