MCP security is the discipline of deciding what a Model Context Protocol server may expose, to which client, on whose authority, and with what evidence afterwards. The protocol standardizes how models discover and call tools; it does not, by itself, make those tools safe. This article breaks the problem into security layers, describes the mechanisms available at each layer, and ends with a deployment checklist.

If you are new to the protocol, start with the MCP security hub, which covers the basics and the main attack classes. Here we go one level deeper.

The MCP attack surface in one page

An MCP deployment has four moving parts — client, model, server and the upstream system the server talks to — and each one adds a trust boundary:

  • Tool poisoning. A server advertises a benign-sounding tool whose description, schema or examples contain hidden instructions aimed at the model. The user never sees the text; the model treats it as trusted configuration.
  • Rug pulls. The tool definition is clean at approval time and changes on a later load. Without pinning, the model silently inherits new behavior.
  • Injected tool results. Tool output is untrusted input. A web page, an email or a ticket can carry instructions that the model follows on the next turn (indirect prompt injection).
  • Over-scoped servers. One server exposes "filesystem", "database" and "shell" together, so a single approval grants a complete kill chain.
  • Token and session theft. Long-lived credentials in server config files, logs or environment variables become lateral-movement material.
  • Confused deputy. A server holds broad credentials and executes requests on behalf of any client that can reach it, losing all attribution.
  • Supply chain. Community servers are npm/PyPI packages with install hooks, transitive dependencies and, increasingly, their own network access.

The MCP security for AI agents article covers exploitation patterns; the rest of this page is about controls.

Layer 1 — Transport and network

Treat every MCP server as an internet-facing service even when it runs locally, because the model can be induced to call it from any context.

  • Use authenticated transport. stdio is only acceptable for a server bound to one local client. Remote servers should use streamable HTTP over TLS, with mutual authentication where possible.
  • No implicit localhost trust. A local HTTP server on a fixed port can be reached by any process on the host, including a browser via DNS rebinding. Bind explicitly, validate Origin, and require a token.
  • Egress allowlist. Decide which domains a server may contact. An MCP server that can reach the whole internet is a data-exfiltration primitive.
  • Resource limits. Cap response size, tool execution time and concurrent calls; a malicious or buggy server should not be able to exhaust the client.

Layer 2 — Authentication and identity

MCP authorization is built on OAuth 2.1: the server is a resource server, the client obtains a token from an authorization server, and the token's audience must identify the MCP server. The security-relevant rules are simple to state and easy to get wrong:

  • Validate the audience. A token minted for another service must be rejected. This is the fix for token passthrough and the confused-deputy pattern.
  • One token per server, per user, per task. No shared service tokens across clients.
  • Short expiry and refresh rotation. Assume any token can end up in a log or a context window.
  • Do not accept model-supplied credentials. The client, not the model, attaches the token. A tool argument containing a bearer token is a red flag.
  • Bind sessions to the authenticated principal. Reject a session ID presented by a different user or client instance.

For a broader treatment, see the authentication section of the MCP security pillar.

Layer 3 — Tool manifest integrity

The tool description is executable influence over the model. Treat it like code, not like documentation:

  • Pin and hash. Record a hash of each tool definition at approval time. On every load, compare; refuse to serve on mismatch until a human re-approves.
  • Diff on upgrade. Show a reviewer exactly which descriptions, parameters and defaults changed — not just the package version.
  • Scan descriptions for instruction patterns. Imperatives ("ignore", "always", "before using this tool"), encoded blobs, URLs and references to other tools are all signals worth reviewing.
  • Least-privilege defaults. A tool should not accept a free-form command string when an enum of operations would do.
# Pin the manifest, not just the version tools: - name: read_ticket server: zendesk-mcp manifest_sha256: 9f2c...a71 approved_by: [email protected] approved_at: 2026-10-14 scopes: [tickets:read] - name: send_email server: mail-mcp manifest_sha256: 4be1...0cd scopes: [mail:send] requires_human_approval: true

Layer 4 — Tool-call authorization

Authentication proves who is calling; authorization decides what may happen. Do it per tool, per argument and per caller — not per server:

  • Capability masks per caller. The effective permission is the intersection of the user's rights, the client's role and the task's temporary elevation.
  • Argument-level scope. read_ticket(id) must be checked against the caller's queue, not merely against the tool name.
  • Irreversibility gate. Sends, deletes, payments and permission changes require a human approval step the model cannot fabricate.
  • Tool allowlisting per agent. An agent should see only the tools its task needs. Hiding tools at discovery time reduces both attack surface and hallucinated calls.
  • Deny by default. New tools are inert until explicitly granted.

This is the same model described in Least Privilege for AI Agents; MCP makes it more urgent because tools arrive dynamically from third parties.

Layer 5 — Output handling and egress

Tool results are the most reliable injection vector because they bypass the user's review. Controls:

  • Label provenance. Mark tool output as untrusted in the context and instruct the model accordingly — necessary but insufficient on its own.
  • Sanitize before the model sees it. Strip hidden HTML, zero-width characters, control tokens and unexpected large payloads.
  • Filter the model's next action. If the output causes a call to a different tool or a new domain, require re-authorization.
  • Prevent exfiltration by construction. Combine the egress allowlist with output filtering so that secrets and PII cannot leave, even if the model is convinced to send them.

Layer 6 — Logging, detection and response

Without an audit trail, an MCP incident is indistinguishable from normal operation. Log, at minimum: client and user identity, server, tool, arguments (redacted), decision, policy version, latency and result status. Then detect:

  • a tool invoked for the first time, or by an agent that never used it before;
  • a manifest hash change outside a deployment window;
  • a call whose arguments reference a different tenant or an external domain;
  • a burst of denials followed by a successful call — a sign of probing;
  • PII or secret patterns in outbound tool arguments.

resk-mcp implements server-side tool authorization and logging for Python clients; ReskPoints covers agent-level observability. The LLM firewall sits in front of the model to block disallowed tool triggers during generation.

Deployment checklist

  1. Inventory every MCP server, its owner, tools, scopes and upstream credentials.
  2. Require authenticated transport and audience-validated OAuth tokens; ban shared tokens.
  3. Pin tool manifests by hash and review diffs before upgrades.
  4. Grant tools per agent and per task, deny by default, intersect permissions.
  5. Require human approval for irreversible tools.
  6. Allowlist egress, cap response size, sanitize tool output.
  7. Log every call with identity and policy version; alert on drift and first-use.
  8. Run an injection test suite against the server before each release.

FAQ

What are the main security considerations for MCP? Tool poisoning and rug pulls in manifests, indirect prompt injection through tool results, over-scoped servers, token theft and confused-deputy access. Controls map to transport, authentication, manifest integrity, authorization, output handling and audit.

What are the security layers of MCP? Six practical layers: transport/network, authentication and identity, tool-manifest integrity, tool-call authorization, output handling and egress, and logging/detection.

How does MCP authentication work? The MCP server acts as an OAuth 2.1 resource server. Clients obtain tokens from an authorization server, and the server must validate signature, expiry and audience before accepting a call.

What is MCP tool poisoning? A malicious or compromised server hides instructions in a tool's description or schema. The model reads them as trusted configuration, which can redirect behavior or trigger other tools.

Is MCP secure by default? No. The protocol defines how tools are discovered and called; it does not enforce least privilege, manifest integrity or egress control. Those are deployment responsibilities.

Next step

Pick the server with the broadest credentials and apply layers 2 to 4 this week: audience-validated tokens, a pinned manifest and per-tool authorization. That alone removes most realistic MCP attack paths.

Read the MCP security pillar for the architecture, or try demo.resk.fr to see tool authorization in practice.