MCP security guide: protecting AI agent tools and data

MCP security determines whether an AI agent remains a constrained assistant or becomes an uncontrolled operator with access to email, files, repositories and production systems. The Model Context Protocol standardises how AI applications discover tools, resources and prompts exposed by servers. That interoperability is valuable, but it also connects components with different trust levels.

This guide explains MCP architecture, high-impact attack paths and controls to implement before a server receives real data or credentials. The baseline is the official MCP security best-practices documentation.

MCP architecture and trust boundaries

A typical deployment includes:

an MCP host, such as an assistant or development environment;
an MCP client that maintains a connection to one server;
an MCP server that publishes tools, resources and prompts;
a target system, such as an API, repository, database or SaaS service.

The model may propose a tool call, but the host and server are responsible for authorisation, validation and execution. Tool descriptions are data supplied by the server. Model-generated arguments are untrusted input. Tool results are also untrusted because they may contain attacker-controlled content.

Create a data-flow diagram showing content sources, model context, token issuers, scopes, user approval and outbound network access. The key question is whether an instruction in one data source can cause an effect in a different system.

Indirect prompt injection through MCP resources

An agent may read a webpage, ticket, email or README containing a hidden instruction to retrieve private information or call another tool. The model does not have a reliable internal boundary between the user’s objective and instructions embedded in data.

Microsoft describes this class as indirect injection in MCP ecosystems. Text filtering alone is insufficient. Constrain what the agent can do:

external content must not silently change the user’s objective;
write operations require meaningful approval;
confirmation shows the actual target and arguments;
the server checks identity, tenant, resource and action again;
one tool’s output cannot automatically authorise another tool;
sensitive read-and-send combinations are blocked or separately approved.

Test visible instructions, white text, HTML comments, encoded strings, OCR content and multi-step retrieval. Attempt to combine harmless read and send tools into an exfiltration chain.

Tool poisoning and rug pulls

The server describes tools to the model. A malicious or compromised server can hide instructions in a tool name, description or parameter schema. The model may see details that the human interface abbreviates. OWASP documents this as MCP Tool Poisoning.

A rug pull changes a tool after the user or organisation approved an earlier version. The updated server may publish different instructions or perform an extra action while retaining the same friendly name.

Defences include a registry of approved servers, pinned versions or image digests, review of manifests and alerts on tool-definition changes. A material change should trigger reapproval. The host should display current, complete transaction parameters, not a cached summary.

Treat MCP packages like executable software. Verify publisher, source, checksum, dependencies and update channel. Include them in the software supply-chain inventory.

OAuth, token theft and token passthrough

Access tokens are high-value assets. If an MCP server logs a token, forwards it to another service or accepts a token intended for a different audience, an attacker may bypass the agent and call APIs directly.

The MCP authorisation specification uses OAuth-based mechanisms for remote servers and requires resource servers to validate that tokens are intended for them. Token passthrough—accepting or forwarding a token minted for another resource—is prohibited because it breaks audience boundaries and auditability.

Implement these controls:

short-lived access tokens and controlled refresh rotation;
PKCE where required by the client flow;
validation of issuer, audience, signature, time and scope;
distinct read, write and administrative scopes;
proper token exchange rather than forwarding user tokens;
no credentials in URLs, prompts or tool results;
redaction in logs, traces and error platforms;
secure storage bound to the correct host and account.

Test tokens for the wrong audience, expired tokens, missing scopes, tenant changes, replay and use of one session’s token in another.

The confused-deputy problem

A confused deputy appears when the MCP server holds privileged credentials to another API and performs an operation without proving that the current user is authorised for the target. The attacker convinces the server to use its own authority for the attacker’s chosen object.

For example, a server uses a shared administrative account. The model supplies a document identifier, and the server validates only its format. It never checks whether the user owns the document.

Prefer delegated identities and per-user authorisation. Bind consent to a transaction containing user, tool, action, target, arguments and expiry. Changing any material field should invalidate the approval. Avoid shared administrative credentials; when unavoidable, enforce ownership and tenant checks in a policy layer before every operation.

Least privilege for MCP tools

A tool called manage_repository is too broad. Split capabilities into read file, search code, draft change, open pull request and merge pull request. Most assistants need read access and draft creation by default; publishing and destructive actions require a separate decision.

Apply limits at several layers:

identity: a separate service identity per server and environment;
scope: minimal OAuth or IAM permissions;
resource: allowlisted repositories, folders, mailboxes or projects;
action: read separated from write, delete and administration;
value: transaction, record and recipient limits;
time: short sessions and expiring approval;
network: outbound access only to required hosts;
human: explicit approval for consequential operations.

Do not rely on a system-prompt sentence saying “never delete files”. If deletion is not required, the agent’s identity and tool set must make it impossible.

Local MCP servers and sandboxing

A local stdio server is a process on the user’s machine. It may inherit environment variables, filesystem access, cloud credentials, an SSH agent and network connectivity. Installing an unknown MCP package is therefore similar to running an unknown application.

Use a container or sandbox with a minimal mounted directory, read-only root filesystem, restricted capabilities, resource limits and controlled egress. Inject secrets for the specific integration rather than exposing the entire user environment. Do not mount the home directory or Docker socket merely for convenience.

Pin package versions and verify source and ownership. Maintain an SBOM for server dependencies and a way to remove a compromised server from every host.

Parameter validation and safe results

JSON Schema validates shape, not permission or intent. The server must also enforce semantic rules: allowed domains, number ranges, canonical paths, tenant ownership, maximum sizes and SSRF protection.

Tool output returns to the model or UI and remains untrusted. Do not insert it into HTML without encoding, execute returned code or pass it automatically to another tool. Restrict response size and content types. Scan downloaded files where appropriate.

These controls align with the Improper Output Handling category in the OWASP Top 10 for LLM Applications.

Logging and incident response

An audit trail should answer who called which tool, through which host, with what scope, against which resource and with which approved arguments. It does not need to store full prompts or secrets. Log identifiers, decision outcomes, classifications and transaction links.

Monitor for:

unusual call volume or cost;
access across many tenants;
repeated authorisation failures;
changed tool definitions or server versions;
connections to new destinations;
secret reads followed by external sends;
administrative scopes in ordinary workflows;
long or recursive tool chains.

The response plan should support token revocation, disabling one tool, blocking a server version and identifying every host that uses it. Preserve enough evidence to distinguish model behaviour from deterministic server actions.

MCP security testing methodology

A useful assessment covers the host, client, server, OAuth flow, target system and model behaviour. Include:

prompt injection in resources and tool results;
poisoned names, descriptions and schemas;
tool-definition changes after approval;
wrong-audience tokens and scope escalation;
cross-tenant object access;
SSRF and path traversal in parameters;
exfiltration through an allowed destination;
confirmation bypass and argument changes;
local process escape and inherited secrets;
expensive or infinite tool loops.

The report should distinguish a protocol or implementation flaw from probabilistic model behaviour. Each finding needs reproducible evidence, prerequisites, permission reach and a control in code or configuration. Combine this assessment with API penetration testing for the target services and AI red teaming for end-to-end agent behaviour.

MCP deployment checklist

Is the server and publisher in an approved registry?
Are the package version and artefact digest pinned?
Does a tool-definition change trigger review?
Does every token have the correct audience, scope and short lifetime?
Is token passthrough technically blocked?
Does each action verify identity, tenant and resource ownership?
Are read, write, delete and administration separated?
Does confirmation show the real effect and current arguments?
Is a local process sandboxed with minimal filesystem and egress?
Are inputs and outputs validated outside the model?
Can logs reconstruct decisions without exposing credentials?
Can the organisation revoke tokens and disable the tool quickly?

MCP gives agents useful capabilities, but safety depends on how much authority is actually delegated. Let the model propose an action; keep policy, authorisation and validation deterministic. To review a production MCP integration before it receives real data, contact Breachroad.