Skip to content

AI security

AI agents and MCP: securing the tools your models can call

Agents turn text into actions. The Model Context Protocol makes connecting tools easy, which moves the real attack surface to tool permissions, tokens and the servers you install.

Resilient Privacy Research · · 11 min read

Simulated environment, real workflow.

Why agents change the question

A chat assistant that only answers questions can embarrass you. An agent that can call tools can act for you: read a mailbox, query a database, open a pull request, issue a refund. The model is the same; what changed is what its output is wired to. Security review has to follow that wiring.

The Model Context Protocol (MCP) is an open protocol that standardizes how AI applications connect to tools and data. A host application (an IDE, a desktop assistant, an internal agent platform) runs MCP clients, and each client talks to an MCP server that exposes tools, resources and prompts. That standardization is the point: one server can plug into many hosts. It also means one badly scoped server can plug into many hosts.

The MCP specification says this plainly. Its security principles state that tools represent arbitrary code execution and must be treated with caution, that descriptions of tool behavior should be considered untrusted unless they come from a trusted server, and that hosts must obtain explicit user consent before invoking any tool. It also notes that MCP cannot enforce these principles at the protocol level. Enforcement is the implementer's job, which in practice means yours.

Where the attack surface moved

Most agent incidents we would expect to see are not exotic model attacks. They are old problems (over-broad permissions, trusted input that isn't, unverified software) arriving through a new channel. The useful map has four parts:

  • The context window: every piece of text the model reads, including tool descriptions and tool results, can carry instructions.
  • The tool layer: what each tool can do, with whose credentials, and whether anything checks the call before it runs.
  • The server supply chain: who wrote each MCP server, how it was installed, and whether it can change after you approved it.
  • The evidence trail: whether you can reconstruct which instruction led to which tool call, on whose behalf, with what result.

The OWASP Top 10 for Agentic Applications (published December 2025 by the OWASP GenAI Security Project) gives these risks names, from ASI01 Agent Goal Hijack and ASI02 Tool Misuse and Exploitation to ASI03 Identity and Privilege Abuse and ASI04 Agentic Supply Chain Vulnerabilities. It extends the OWASP Top 10 for LLM Applications 2025, where the matching entries are LLM01 Prompt Injection, LLM03 Supply Chain and LLM06 Excessive Agency.

Prompt injection through tool output

Indirect prompt injection is the agent-era version of an old lesson: data and instructions share a channel. An agent asked to summarize a web page, triage an inbox or read a ticket will also read any instructions an attacker placed there. If the agent holds a tool that can send data out, the injected text can ask it to.

MITRE ATLAS, the knowledge base of adversary techniques against AI systems, now catalogs this chain directly: LLM Prompt Injection (AML.T0051) leading to AI Agent Tool Invocation (AML.T0053) and Exfiltration via AI Agent Tool Invocation (AML.T0086). Its case study AML.CS0045 describes a proof of concept in which a web-scraping MCP server returned a page containing instructions that told the coding agent to run a shell command exfiltrating credential files; the client's prompt before running commands was the control that could stop it.

Filters and instruction-hierarchy training reduce the success rate of injection. None of them removes it. Design as if some injected instruction will eventually be followed, and decide in advance what it must not be able to reach. ATLAS lists that as a mitigation in its own right: Restrict AI Agent Tool Invocation on Untrusted Data (AML.M0030).

Tool poisoning, shadowing and rug pulls

The model reads a tool's name, description and parameter schema to decide when and how to call it. The user usually sees a short label. In April 2025 Invariant Labs published a disclosure showing that a tool description can carry hidden instructions: a harmless-looking add tool whose description told the agent to read an SSH private key and the MCP configuration file and pass them along in an unused parameter, without mentioning it to the user.

The same disclosure described two variants that matter for review:

  • Shadowing: a malicious server's description changes how the agent uses a different, trusted server's tool. In their demonstration it redirected every email sent through a legitimate send tool to the attacker, even when the user named another recipient. The malicious tool never has to be called.
  • Rug pull: a server changes its tool descriptions after the user approved them. MCP lets servers notify clients that their tool list has changed, so an approval given on day one says little about what is running on day thirty.

Sandboxing the server process does not help here, because the attack runs through the agent's own instruction following. The defenses are visibility (show the full description the model sees), pinning (hash approved tool definitions and alert on change), and isolation between servers so one server cannot steer another's tools. ATLAS tracks the same ideas as AI Agent Tool Poisoning (AML.T0110) and Publish Poisoned AI Agent Tool (AML.T0104).

Confused deputies, token scope and passthrough

A confused deputy is a program with legitimate authority that is tricked into using it for someone else. Agents are deputies by design. Two versions show up in MCP deployments.

The first is in the OAuth plumbing. The MCP Security Best Practices page describes an attack on MCP proxy servers that use a single static client ID with a third-party API and also allow dynamic client registration: a consent cookie from an earlier, legitimate approval lets an attacker's newly registered client receive an authorization code without the user seeing a consent screen. The specification requires per-client consent stored server side, exact redirect URI matching and single-use state values. It also forbids token passthrough: an MCP server must not accept tokens that were not issued for it, because forwarding them breaks audience checks, rate limits and the audit trail.

The second is simpler and more common: the tool runs with a shared service account. The user asking the agent can read three records; the tool can read every record. An injected instruction then inherits the tool's authority, not the user's. The specification's scope guidance applies directly: start with minimal scopes, step up with targeted challenges when a privileged operation is first attempted, and avoid wildcard or omnibus scopes. The same page lists treating claimed scopes as sufficient without server-side authorization logic as a common mistake.

The MCP server supply chain

An MCP server is software you run, often installed with one command from a public registry or a README. The specification's section on local MCP server compromise is blunt: a client configuration can carry a malicious startup command, a server can carry a malicious payload, and a local server left listening on localhost can be reached through DNS rebinding. Clients that offer one-click setup must show the exact command before running it and should run servers sandboxed with minimal privileges.

Treat servers the way you treat dependencies. Know where each one came from, who maintains it, which version you approved and what changed since. Remote servers add a second question: who operates them, and what happens to the data and tokens they receive. The MCP specification also warns that a malicious server can feed a client URLs during OAuth discovery that point at internal addresses or cloud metadata endpoints (server-side request forgery), and authorization URLs with dangerous schemes that turn into script or command execution in a careless client.

Logging and forensics for agents

When something goes wrong, the first question is which input caused which action. Many agent deployments cannot answer it, because the conversation, the tool calls and the downstream API logs live in three places with no shared identifier. Token passthrough makes this worse: the downstream service logs the request under an identity that is not the agent's.

A minimum useful record, per tool call:

  • Who: the human user, the agent or host, the MCP client and server, and the token audience and scopes used.
  • What: tool name, the hash of the tool definition at call time, arguments and a truncated result.
  • Why: a reference to the context that preceded the call, including which tool results or documents were in the window.
  • Decision: whether the call was auto-approved, approved by a person, or blocked, and by which rule.
  • Correlation: one ID that joins the agent log, the MCP server log and the downstream API log.

Send this to the same place your security operations team already looks, keep it under the retention rules of the data it contains, and alert on the patterns that matter: a tool definition hash that changed, a sensitive read followed by an external write in the same task, and scope step-ups outside normal hours.

A review method that works

This is the method behind our MCP & Agent Tool-Permission Review. It fits in one to two weeks for a typical deployment and produces a permission matrix you can act on.

  • Inventory: list every host, agent, MCP server and tool in use, including servers developers installed locally. Record source, version, operator and owner.
  • Map authority: for each tool, record the credential it uses, the scopes granted, and the widest action it can take. Mark tools that read sensitive data and tools that can send data out or change state.
  • Find the dangerous pairs: any task where an untrusted input source and an outbound or destructive tool can share one context window. These are the paths an injection would use.
  • Read the descriptions: review the full tool names, descriptions and schemas the model sees, not the UI label. Look for instructions, references to other tools, and requests for unrelated data.
  • Check the OAuth path: token audience validation, no passthrough, per-client consent on proxies, exact redirect matching, scope minimization and step-up.
  • Test it: plant instructions in content the agent will read and try to reach each dangerous pair; change a tool description after approval and see whether anyone notices.
  • Verify the evidence: confirm each test produced a log record that your security team could find and reconstruct.
  • Fix and retest: least privilege per tool and per user, human approval for destructive or costly calls, pinned definitions, and segmentation between servers. Retest after every model, prompt or server change.

Use MITRE ATLAS techniques to scope the testing and its mitigations (for example AML.M0028 AI Agent Tools Permissions Configuration and AML.M0029 Human In-the-Loop for AI Agent Actions) to name the fixes. For governance, the results map onto the NIST AI Risk Management Framework functions: the inventory supports Govern and Map, testing is Measure, and the fix plan is Manage. NIST's Generative AI Profile (NIST AI 600-1) adds risks specific to generative systems, including information security.

Checklist

Use this before connecting a new MCP server or giving an agent a new tool.

  • Inventory: every MCP server and tool has a named owner, a known source and a pinned version.
  • Descriptions: full tool descriptions were read by a person and are hashed; a change triggers re-approval.
  • Credentials: tools act with the requesting user's permissions, not a shared service account.
  • Scopes: tokens carry the minimum scopes; no wildcard or omnibus scopes; step-up for privileged operations.
  • Audience: servers reject tokens not issued to them and never pass client tokens through.
  • Dangerous pairs: no task combines untrusted input with an outbound or destructive tool without a human check.
  • Approval: destructive, costly or external actions require explicit human approval that shows the real arguments.
  • Isolation: local servers run sandboxed with limited file system and network access.
  • Outputs: tool results are treated as untrusted input and validated before reaching another system.
  • Network: OAuth discovery and redirects block private address ranges and non-HTTPS schemes.
  • Logging: every tool call is logged with user, tool, definition hash, arguments, decision and a correlation ID.
  • Retesting: injection and rug-pull tests rerun after each model, prompt or server change.

Sources

Related

Want a second pair of eyes on this?

Talk to the practitioners behind our research about your environment.

Talk to an expert