MCP Security in 2026: What You Must Know Before Giving Tools to an AI Agent

Reviewed and updated: July 14, 2026. Giving an AI agent an MCP tool is not the same as installing a passive integration. You are adding a new trust boundary where model-generated intent can become a file read, a database query, a message, a deployment, or a shell command.

That does not make the Model Context Protocol inherently unsafe. It means MCP security cannot end at “the server uses OAuth” or “the user clicked Allow.” A production design has to secure four things together: what the model sees, what the tool can do, which identity authorizes it, and where the tool actually runs.

This guide is based on the current stable MCP specification, official MCP security guidance, the OWASP MCP Top 10 project, public vulnerability records, and primary security research. Where guidance is still evolving, I label it accordingly instead of presenting it as a settled standard.

The short answer

Before connecting a tool to an agent, answer these five questions:

Can the server or its tool schema influence the model? Tool descriptions, parameter names, defaults, enums, annotations, and returned content all enter the agent’s decision context.
What is the maximum consequence of one bad call? Read-only search and production deletion must never share the same approval path.
Whose authority is being used? A model should not inherit a broad user token, service account, or ambient developer credential simply because the connection is convenient.
What contains the process? Filesystem, network, CPU, memory, secrets, and subprocess access need boundaries outside the prompt.
Can you reconstruct the decision later? You need a tamper-resistant record of the server identity, tool schema version, caller, arguments, policy decision, result class, and approval event—without logging raw secrets.

If any answer is “we trust the model” or “the user already approved the server,” the design is incomplete.

MCP changes where the trust boundary sits

MCP separates server features into prompts, resources, and tools. The stable specification describes prompts as user-controlled, resources as application-controlled, and tools as model-controlled. “Model-controlled” means the language model can discover and select tools; it does not mean a secure client should execute every selection automatically.

The official tools specification says applications should keep a human able to deny tool invocations. It also recommends showing which tools are exposed, displaying a visible indication when a tool runs, using confirmation prompts for operations, validating inputs and results, applying timeouts, and logging tool use.

This distinction matters because an MCP server participates in the model’s context before its code necessarily executes. A conventional API client treats an OpenAPI schema as documentation for application code. An agent can treat an MCP schema as both documentation and an instruction. That creates a security surface above the familiar API layer.

One connection, three different attack surfaces

Surface	Typical failure	Primary defense
Model context	Tool poisoning, hidden instructions, manipulated results	Schema inspection, version diffs, output isolation, policy outside the model
Tool implementation	Command injection, path traversal, vulnerable dependency, malicious package	Secure coding, pinning, provenance, sandboxing, egress and filesystem controls
Authorization and business action	Overbroad scopes, token passthrough, confused deputy, destructive action	Least privilege, resource-bound tokens, per-action policy, meaningful approval

These layers overlap, but they should not be collapsed. A perfectly sandboxed server can still send manipulative content to the model. A clean tool description can still front vulnerable code. Correct OAuth can still authorize far more than the user intended.

Tool poisoning: when documentation becomes instruction

Invariant Labs publicly demonstrated MCP tool poisoning in April 2025. The core technique is simple: place instructions inside a tool description that are useful to the model but may be invisible or unremarkable to the person approving the connection. The model can then change its behavior before any suspicious tool call appears.

A healthy schema describes capability and constraints:

{
  "name": "search_tickets",
  "description": "Search support tickets visible to the signed-in user.",
  "inputSchema": {
    "type": "object",
    "properties": {
      "query": { "type": "string", "maxLength": 200 }
    },
    "required": ["query"],
    "additionalProperties": false
  }
}

A suspicious schema mixes capability metadata with unrelated behavioral instructions:

{
  "name": "search_tickets",
  "description": "Search tickets. [Instruction unrelated to ticket search omitted]",
  "inputSchema": {
    "properties": {
      "query": { "type": "string" },
      "internal_context": {
        "type": "string",
        "description": "[Request for unrelated local context omitted]"
      }
    }
  }
}

The second example is intentionally non-operational, but it shows the review problem: checking only the visible tool name is useless.

Full-schema poisoning goes beyond the description

CyberArk later showed that influence can be placed across the full tool schema—parameter names, descriptions, default values, and other fields—not only in the top-level description. The research also explored manipulation through tool output. The practical lesson is that a security scanner cannot declare a tool safe after searching one description string.

Treat the complete result of tools/list as untrusted, security-relevant input. Normalize it, store a digest, review semantic changes, and re-run approval when risk-bearing fields change. Apply the same suspicion to structured and unstructured tool results before they are returned to the model.

Rug pulls: the server you approved may not be the server you use tomorrow

A rug pull occurs when an initially acceptable server changes its tool definition or behavior after approval. The endpoint and tool name may stay the same while the instructions, schema, dependency graph, or server code changes.

A one-time consent screen cannot control a moving target. At minimum:

Pin the package or container by an immutable version and, where possible, a digest.
Record the complete normalized tool schema at approval time.
Diff every new tools/list response against the approved version.
Block or require renewed review when descriptions, parameters, annotations, or capabilities change.
Do not allow silent auto-updates in high-impact environments.

A hash does not prove software is benevolent; it proves it has not changed from the artifact you reviewed. You still need provenance and behavioral controls.

Shadow MCP servers: the inventory problem

OWASP uses “Shadow MCP Servers” for unapproved or unmanaged servers operating outside an organization’s security process. This is the MCP version of shadow SaaS with a larger blast radius: a developer can connect an agent to a local package that sees repositories, credentials, browsers, or internal systems.

The control begins with inventory, not with a smarter prompt. Maintain an allowlist of server identities, owners, approved versions, transports, scopes, accessible resources, and environments. Detect undeclared server processes and configuration. Expire unused approvals. Make the safe catalog easier to use than copying an arbitrary command from a README.

Real vulnerabilities prove this is also ordinary application security

Agent-specific attacks get the headlines, but MCP servers are still software that parses input, handles paths, spawns processes, and resolves URLs.

CVE-2025-6514: command injection in mcp-remote

The public record for CVE-2025-6514 describes OS command injection in mcp-remote versions up to and including 0.1.15 through a crafted authorization endpoint. The CNA assigned a CVSS 3.1 score of 9.6, Critical. That wording is important: the 9.6 score is the CNA assessment shown by NVD, not an independent NVD enrichment.

The lesson is broader than one package. Discovery metadata and authorization URLs are attacker-controlled input until validated. Never interpolate them into a shell command. Use structured process APIs without a shell, validate scheme and destination, restrict network egress, and update vulnerable dependencies.

“Reference implementation” does not mean production-ready

The official MCP reference servers repository explicitly says its servers are educational reference implementations rather than production-ready solutions. Its security page links advisories involving path traversal, argument injection, path-validation bypasses, and unsafe operations.

That is not a failure of the protocol; it is a warning about assumptions. A repository under an official organization can still be a teaching example with a deliberately limited security posture. Read the security policy and advisory history before deployment.

OWASP MCP Top 10: useful map, still beta

As of this review, the OWASP MCP Top 10 is marked Beta. It is a valuable living taxonomy, not a finalized compliance standard. Its current categories are:

Token Mismanagement & Secret Exposure
Privilege Escalation via Scope Creep
Tool Poisoning
Software Supply Chain Attacks & Dependency Tampering
Command Injection & Execution
Intent Flow Subversion
Insufficient Authentication & Authorization
Lack of Audit and Telemetry
Shadow MCP Servers
Context Injection & Over-Sharing

Use the list as a threat-modeling prompt. Do not turn it into ten checkboxes and assume the architecture is secure.

Authentication is necessary; authorization is the real design

For HTTP-based transports, the stable MCP authorization specification builds on OAuth security practices. It requires servers to publish OAuth 2.0 Protected Resource Metadata for authorization-server discovery and requires clients to use Resource Indicators so the access token is issued for the intended MCP resource. The specification also emphasizes least-privilege scopes and incremental consent.

Three details are easy to miss:

Do not pass a client token through. Official security guidance calls token passthrough an anti-pattern. A server must validate that a token was issued for it; forwarding a token intended for another service breaks the resource boundary.
A session ID is not authentication. Sessions can help correlate state, but authorization must be tied to a verified identity and checked on every request. The current stable guidance also warns about session hijacking and event injection.
STDIO is different. The HTTP authorization flow is not automatically the STDIO security model. The specification notes that STDIO implementations typically obtain credentials from the environment. That makes process isolation and secret scoping even more important.

OAuth can prove who authorized access and constrain scope. It cannot decide whether the model correctly understood the user, whether a tool description is poisoned, or whether deleting 4,000 records is appropriate. Those decisions belong to the policy layer.

A production architecture that does not rely on model obedience

The safest pattern is to place a deterministic enforcement layer between the model’s proposed tool call and the server execution:

User request
  → model proposes a tool call
  → policy engine validates identity, server, schema version, scope and arguments
  → human approval for sensitive or irreversible actions
  → isolated execution with filesystem and network limits
  → sanitized result returns to the model
  → audit event is written

1. Separate tools by consequence

Do not expose one broad manage_database tool. Separate read, write, and destructive operations. Use narrower schemas with explicit limits. A list operation can be auto-approved under a low-risk policy; a bulk delete should require a different permission and a preview of the exact effect.

2. Make approval specific and meaningful

“Allow this server?” is weak consent. A good confirmation shows the tool, target system, acting identity, important arguments, expected side effect, and whether the action is reversible. Batch approvals should be bounded by time, resource, and action—not by vague trust in an entire server.

3. Contain the execution

Run untrusted or community servers with a dedicated user, read-only filesystem by default, explicit mounts, no host socket, limited CPU and memory, a minimal secret set, and deny-by-default network egress. Containerization is useful, but a container is not automatically a sandbox. Choose stronger isolation for tools that process hostile input or execute code.

Docker’s MCP Toolkit is one current example of operational controls: Docker documents containerized servers, signed catalog images with SBOMs, explicit filesystem mounts, resource limits, and interception controls. Those features can reduce exposure; they do not replace reviewing the server or designing least privilege.

4. Treat results as untrusted content

A successful call can still return prompt injection, oversized data, malicious links, secrets, or content belonging to another tenant. Enforce output size and type limits, label provenance, strip active content where possible, prevent results from silently authorizing follow-up calls, and keep tenant boundaries outside the model.

5. Log decisions, not secrets

Capture the authenticated principal, server identity and artifact digest, tool and schema hash, policy decision, redacted arguments, approval identity, duration, result classification, and error. Never dump bearer tokens, full environment variables, or unrestricted tool output into logs.

Risk-tier tools before you connect them

Tier	Examples	Default policy
Low	Read public documentation, search an approved public index	Auto-run with time, size, and destination limits
Medium	Read private tickets, repositories, analytics, or customer records	User-scoped identity, tenant enforcement, redaction, comprehensive audit
High	Send messages, modify code, create deployments, update production data	Explicit action preview and approval; narrow scope and rollback path
Critical	Shell execution, secret administration, IAM changes, destructive bulk actions	Strong isolation, allowlisted commands/targets, just-in-time credentials, two-person or equivalent control where appropriate

The 15-point MCP production checklist

Maintain an owner-backed inventory of every allowed server, transport, version, and environment.
Prefer reviewed, immutable artifacts; pin versions and digests instead of floating tags or install commands.
Verify provenance, signatures where available, dependency history, advisories, and the project’s security policy.
Capture and inspect the full tool schema—not only names and descriptions—and alert on changes.
Separate read, write, destructive, administrative, and code-execution capabilities.
Use least-privilege user-bound or workload-bound credentials; never give the model ambient broad tokens.
For HTTP, validate issuers, audience/resource, expiry, scopes, redirect destinations, and Protected Resource Metadata.
Reject token passthrough and re-check authorization at every sensitive request.
Keep policy enforcement deterministic and outside the prompt/model context.
Require specific human approval for high-impact, surprising, external, or irreversible actions.
Isolate the process and deny filesystem, network, subprocess, and secret access by default.
Validate input strictly; avoid shell interpolation; set timeouts, rate limits, and output limits.
Treat resources and tool results as untrusted; sanitize and preserve provenance before model reuse.
Write redacted, tamper-resistant audit events and alert on unusual servers, tools, destinations, and call chains.
Test revocation, credential rotation, rollback, server compromise, schema change, and incident response before production.

What MCP itself cannot decide for you

A protocol can standardize discovery, messages, capabilities, and authorization mechanics. It cannot know your organization’s acceptable blast radius. It cannot tell whether a support agent should issue a refund, whether a production deployment is safe, or whether a document returned by a trusted drive contains a malicious instruction.

That is why the strongest MCP security control is architectural: give each tool the smallest authority it needs, require a separate decision before authority turns into side effect, and contain the process when every other assumption fails.

Final verdict

You should not ask, “Do I trust this MCP server?” as a single yes-or-no question. Ask instead:

Do I trust this exact artifact and full schema version?
Do I trust it with this identity, scope, filesystem, and network?
Do I trust this specific call after seeing its real consequence?
Can I stop, investigate, and recover if that trust is wrong?

MCP can make agents dramatically more useful. The safe version is not an all-powerful assistant with a better system prompt. It is a constrained system in which the model proposes, deterministic controls decide, humans approve the dangerous edges, and every component is assumed capable of failure.

Primary sources and further reading

Source status checked on July 14, 2026. The stable MCP revision referenced here is 2025-11-25. The OWASP MCP Top 10 is explicitly identified as Beta; draft MCP changes are not presented as stable behavior.