pvakati-tech.ai

// agent_security

MCP server security

The Model Context Protocol made it trivial to hand an agent new tools. It also made it trivial to hand an agent someone else's instructions, your credentials and a way to send data out. This is the threat model, and the controls that matter, for both sides of the connection.

Checked against the sources below · September 22, 2026MCP live demo →

The short version

An MCP server is code that runs with your agent's privileges and text that goes straight into your model's context. Both halves are attack surface: the code can do damage directly, and the text — tool descriptions, tool results, resources — can steer the model into doing damage for it.

The durable defenses are least privilege per tool, audience-bound authorization, human approval for side effects, pinned and reviewed servers, and never letting one agent combine private data, untrusted content and a way to send data out.

Where the attacks come from

via content

Prompt injection through tool output

A tool fetches a web page, an email, a ticket or a file containing instructions. The model cannot reliably tell data from commands, so text returned by a tool can redirect what it does next.

via metadata

Tool poisoning

Instructions hidden in a tool’s description or parameter docs. The model reads them on every request; the user usually never does.

via updates

Rug pulls

A server is approved while benign, then changes its tool definitions. Hosts that approve once never re-check.

via naming

Tool shadowing

One server’s descriptions tell the model how to use a different server’s tools — rerouting an email tool’s recipient, for example — without calling anything suspicious itself.

via credentials

Token passthrough and confused deputies

A server that forwards the client’s token upstream, or accepts tokens issued for someone else, acts with privileges no one granted it.

via the host

Local server exposure

Local servers run as you, with your files and network. A command-injection bug in a tool, an unpinned package or a localhost HTTP server reachable from a browser page turns into code execution.

The lethal trifecta

The single most useful rule for agent security: an agent is exploitable for data theft when it has all three of access to private data, exposure to untrusted content, and a way to communicate externally. Injected instructions in the untrusted content tell it to read the private data and send it out.

MCP makes the trifecta easy to assemble by accident — connect a mailbox server, a web fetcher and anything that can make an HTTP request, and you have all three. No filter reliably stops injection, so the robust fix is architectural: make sure no single agent session holds all three capabilities, or require a human in the loop at the point where data would leave.

Filters are not a boundary

Injection detectors and “ignore instructions in tool output” prompts reduce risk; they do not remove it. Design as if some injected instruction will eventually be followed, and limit what that instruction could accomplish.

If you build MCP servers

  1. 01

    Authorize remote servers properly

    Follow the specification’s OAuth-based authorization for HTTP servers. Validate every token’s audience and accept only tokens issued for your server; never pass a client’s token through to an upstream API — obtain your own credentials for that.
  2. 02

    Scope each tool to the least it needs

    Separate read tools from write tools, and narrow scopes per tool rather than per server. A “search tickets” tool should not share a credential that can delete them.
  3. 03

    Treat tool arguments as hostile input

    Arguments come from a model that may be following injected instructions. Validate them against a schema, never interpolate them into shell commands or queries, and constrain file paths to an allowed root.
  4. 04

    Label untrusted content in results

    When a tool returns third-party text — web pages, emails, user uploads — mark it as untrusted data in the result so hosts and models can treat it accordingly. Return the minimum needed.
  5. 05

    Mark and gate side effects

    Use tool annotations to declare destructive or non-idempotent tools, but enforce confirmation server-side for anything irreversible. Annotations are hints to the host, not a control.
  6. 06

    Harden the transport

    For local HTTP servers, bind to localhost and validate the Origin header to block DNS-rebinding attacks from web pages. Rate-limit, and log every call with the caller identity, arguments and result status.

If you connect agents to MCP servers

  1. 01

    Allowlist and pin

    Connect only servers you have reviewed, pinned to a version or digest. Unpinned “latest” installs are an unreviewed code update on every launch.
  2. 02

    Show and diff tool descriptions

    Surface full tool descriptions to users, and alert when a server’s tool list or descriptions change between sessions — that is how rug pulls are caught.
  3. 03

    Sandbox local servers

    Run them in a container or sandbox with only the directories and network destinations they need. A filesystem server does not need the internet.
  4. 04

    Split the trifecta across sessions

    Keep agents that read untrusted content away from tools holding private data or sending data out, or insert a human approval step where data would cross that line.
  5. 05

    Require approval for side effects

    Sending, paying, deleting, publishing and changing permissions should need a person’s confirmation that shows the actual arguments, not a summary written by the model.

Checklist

MCP security checklist
ControlServer buildersAgent / host operators
AuthorizationAudience-validated tokens; no passthroughPer-server credentials, never shared broadly
PrivilegeLeast-privilege scopes per toolOnly connect tools the task needs
Untrusted contentLabel third-party text in resultsNever combine with private data + egress unattended
Side effectsServer-side confirmation for irreversible actionsHuman approval showing real arguments
Supply chainSigned releases, changelog of tool changesPin versions; diff tool definitions
IsolationConstrain paths; no shell interpolationSandbox local servers; restrict network
VisibilityAudit log of every callLog tool calls per session; alert on anomalies

MCP security FAQ

Is MCP secure?

The protocol defines authorization for remote servers and publishes security best practices, but it cannot make a given deployment safe. Most real risk comes from what a server is allowed to do, what untrusted content reaches the model, and whether anyone reviews third-party servers before connecting them.

What is tool poisoning in MCP?

Tool poisoning is hiding instructions in a tool’s description or metadata. The model reads tool descriptions as part of its context, so a malicious server can tell it to read files, leak data or call other tools — often in text the user never sees in the host’s interface.

What is an MCP rug pull?

A server that behaves well when you approve it and changes its tool definitions later. Because many hosts approve a server once, a changed description or a new tool can go unnoticed. Pin versions and alert on any change to a server’s tool list or descriptions.

Should an MCP server pass the user’s token to upstream APIs?

No. The MCP specification forbids token passthrough: a server must only accept tokens issued for it, and must obtain its own credentials for any upstream service. Forwarding a client’s token lets a server act with privileges it was never granted and breaks audit trails.

How do I safely use third-party MCP servers?

Treat each one as code you are about to run with your agent’s privileges: review it, pin its version, run local servers in a sandbox with restricted filesystem and network access, show users every tool description, require approval for actions with side effects, and never connect a server that reads untrusted content to an agent that also holds private data and can send it somewhere.

Sources

Connecting to MCP servers (live demo)AI agent authenticationOAuth vs API keys vs JWTAgentic AI architecture