MCP Tool Security and Prompt Injection Risks in Agentic Pipelines

In a conventional API integration, a human engineer writes the call. Intent is explicit, parameters are fixed at authoring time, and the operation is auditable before it executes. In an MCP pipeline, the LLM decides what to call and how to parameterize it, based on natural language context that includes untrusted content. Decision authority has moved from a deterministic author to a probabilistic model. The security frameworks inherited from conventional integrations were never designed for that shift, and retrofitting them is genuinely difficult in ways that aren't always obvious until something breaks.

The protocol itself enforces no authentication, no role-based access control, no message integrity by default. Security is entirely a function of implementation discipline, which means it varies with whoever did the implementing. The Center for Internet Security's MCP Companion Guide, published in April 2026 and grounded in CIS Controls v8.1, made this explicit — MCP materially expands identity, access control, logging, and application security surfaces. The NSA's May 2026 Cybersecurity Information Sheet framed MCP servers as warranting the same rigor as traditional API gateways and privileged access management systems. These are not cautionary positions from outside the technology. They are the security community arriving at the obvious conclusion after examining what MCP actually does.

Simon Willison articulated what he called the "lethal trifecta" in June 2025 — when an agent simultaneously has access to private data, processes untrusted content, and can communicate externally, it is exploitable by design. The critical point is that the trifecta isn't a misconfiguration. It describes a correctly functioning, useful agent. An agent that can access your file system and call external APIs is valuable precisely because it can do those things; an attacker values it for exactly the same reason. The properties that make the system worth building are the same properties that make it worth attacking. That particular symmetry has no clean resolution, and anyone who tells you otherwise is selling something.

MCP tool definitions are also mutable after installation. An agent trusts metadata it cannot independently verify and has no native mechanism to detect that the metadata has changed between sessions. Unremarkable in isolation, that property becomes structurally significant when combined with the autonomous execution model MCP enables.

How Prompt Injection Works in an MCP Context, and Why Indirect Injection Is Especially Hard to Defend Against

OWASP's Top 10 for LLM Applications, published in 2025, ranks prompt injection as LLM01, the top risk, flagged explicitly because tools wired to applications can execute arbitrary commands when the model processes a crafted instruction. The mechanism is familiar in principle. What MCP changes is the attack surface available to exploit it, and the change is not incremental.

Direct injection involves malicious user input that instructs the model to reveal secrets or take unauthorized actions. Serious, but at least the attack requires proximity to the user or the prompt.

Indirect injection is the form that occupies security practitioners. The attacker doesn't need access to the user or the prompt at all. The malicious payload is embedded in content the agent retrieves during normal operation — a document the agent reads, a web page it summarizes, a repository file it ingests, a database record it queries. The agent processes that content as context, exactly as it processes legitimate instructions, because from the model's perspective there is no meaningful distinction between the two. The channel for legitimate context and the channel for attacker-placed instructions are the same channel. That is a property of how these systems work, and I find that worth sitting with before moving on.

Demonstrated cases from 2025 confirm this. In May 2025, researchers identified that GitHub Issues, Pull Request comments, and README files are viable injection vectors for agents with repository access via the GitHub MCP integration. A developer's agent, reviewing an open-source project, processes a malicious README. The attack has already landed before the developer knows anything happened. In June 2025, the Supabase Cursor incident showed that user-controlled input fields processed by an agent with database access created a direct injection path into privileged system operations. The pattern holds — the attack vector is any external data source the agent treats as trusted context, and the attack surface grows with every tool added to the pipeline.

There is no clean technical solution that distinguishes legitimate content-embedded instructions from attacker-placed ones at the model layer. The defenses must be architectural — limit what the agent can do with what it retrieves, validate inputs and outputs at the boundary, and treat every external data source as potentially adversarial regardless of its apparent origin.

Tool Poisoning and the Silent Redefinition Problem

Tool poisoning moves the malicious payload upstream. The attack lives in the tool description the LLM reads to decide what to call and how, not in executable code. Nothing in a standard security review catches it, because nothing executable has changed. I've watched experienced engineers miss this class of vulnerability precisely because their threat model was calibrated for binaries.

When an MCP-connected agent selects a tool, it reads that tool's manifest — name, description, parameter schema. A crafted or compromised manifest can redirect the agent's behavior while appearing entirely legitimate. The model has no independent way to verify that the description it's reading matches the implementation it will invoke.

The "Rug Pull" pattern illustrates the temporal dimension of this problem. A developer reviews and approves a tool at installation time. The tool's definition is safe. By a later session, that definition has quietly changed — an API key has been rerouted, the command the agent runs has been altered, or the scope of what the tool accesses has been expanded. Nothing in the conventional security stack generates an alert, because no binary changed. A configuration artifact changed, and MCP trusts configuration artifacts implicitly.

The scale of this exposure is not anecdotal. Analysis of more than 67,000 servers across six public registries identified widespread conditions enabling server hijacking and invocation manipulation. MCPInspect identified 833 vulnerable servers and 18 with suspicious descriptions in a single scan of publicly available infrastructure. With multiple MCP servers connected to the same agent, the problem compounds — a malicious server can override or intercept calls intended for a trusted server, exploiting the agent's inability to maintain a verified model of which server it is actually communicating with.

Installing an MCP tool is not a one-time trust decision. It is an ongoing relationship with a mutable artifact that can change its behavior at any point without triggering any conventional security alert. Practitioners who treat tool installation as a completed review are working from the wrong threat model entirely.

The CVEs from 2025 and 2026 That Confirm These Are Not Theoretical Risks

CVE-2025-59536, disclosed by Check Point Research on February 25, 2026, carries a CVSS score of 8.7. The vulnerability is in Claude Code's Hooks feature, which runs predefined shell commands at lifecycle events. The attack vector is a malicious Hook injected into .claude/settings.json inside a repository. A developer opens the project. Remote code execution follows without any additional user action. The attack surface is the developer's normal workflow, nothing exotic about it.

CVE-2025-49596 affects MCP-Inspector, the tool developers use to test MCP servers during development. It accepted unverified inputs, allowing remote code execution via crafted messages. The fix arrived in version 0.14.1. Before that fix, the testing tool itself was the vulnerability, meaning developers were exposed before any production agent was deployed. The instrument meant to surface problems in MCP servers was itself an entry point. That particular irony is uncomfortable, and it should be.

Researchers examining StdioServerParameters and related functions in widely used LangChain MCP adapters found that arbitrary OS command execution was achievable through that adapter layer. The research produced over 30 disclosures and 10 CVEs across multiple languages, affecting packages with a combined download count exceeding 150 million. That figure represents the installed base of software that carried this class of vulnerability through the adapter layer alone.

The pattern across these three cases is instructive. Vulnerabilities materialized not in exotic edge-case configurations but in the developer toolchain — the inspector, the hooks system, the widely-used adapter layer. The attack surface reaches developers before any end-user agent is deployed. Beyond CVEs, 492 MCP servers have been publicly identified as lacking basic authentication or encryption. That is a substantial portion of the publicly visible ecosystem, not a tail-risk count.

How MCP Tools Extend the Software Supply Chain Threat Model in Ways Existing SBOM Practices Don't Cover

A conventional Software Bill of Materials is a point-in-time compliance artifact. It records what was installed at build time. It doesn't capture what a tool does, whether its behavior has changed since installation, or what the tool's description will instruct the model to do at runtime. For MCP, that's a fundamental gap, and the distinction matters concretely for anyone responsible for maintaining a defensible inventory.

MCP servers can modify their tool definitions between sessions. A static SBOM cannot represent a mutable artifact. It captures a snapshot of what was installed and says nothing about the definition the agent will read the next time it runs. Unsigned MCP components without verified integrity checks compound this problem, and provenance is inconsistent across distributed MCP registries.

The supply chain threats that have historically targeted libraries now apply directly to the tools an agent invokes autonomously. Backdoors can be injected into source code, dependencies can be modified in build pipelines, and the resulting artifact can be distributed through registries without triggering detection mechanisms calibrated for binary integrity. The delivery mechanism is different; the threat is structurally identical.

A 2026 ACM paper introduced the concept of "agentic AI Bills of Materials," or AIBOMs, as a response to the limits of static inventories. The proposal extends SBOM thinking into active provenance artifacts, incorporating policy-constrained reasoning that accounts for runtime behavior and definition change, not just installation-time state. The emerging trust graph model, which centralizes SBOMs, vulnerability data, cryptographic signatures, attestations, and deployment inventories to trace from binary back to source across the full pipeline, represents where the field is heading.

The EU Cyber Resilience Act and AI-specific transparency obligations have moved supply chain accountability from engineering teams onto executive and board agendas. The question of what tools an agent can invoke, and under what verified conditions, is no longer something that can be deferred until after deployment.

What a Defensible MCP Security Architecture Actually Requires

Anthropic's official guidance articulates the foundational principle — treat all agents as more-or-less unpredictable and build defenses from the first server, not as an afterthought. Least privilege, strict isolation, and complete visibility are design constraints that shape the system from the beginning. They are not hardening steps applied to a running system that already has problems. Engineers who encounter MCP security for the first time often want to start with the interesting problems; the unglamorous controls come first.

Authentication and transport come first, using OAuth 2.1 for identity and TLS for transport. Strong token handling and session protections prevent token passthrough and session hijacking, both live concerns in multi-server configurations. MCP servers should operate under scoped, user-delegated permissions rather than broad service credentials that grant the agent more authority than any single user should hold.

Sandboxing and privilege scoping follow directly. MCP server commands should execute in sandboxed environments with minimal default privileges. File system access, network access, and system resource access should be restricted at launch, with additional privileges granted only through explicit, auditable approval. Containers, chroot environments, and application sandboxes are all applicable mechanisms. The choice matters less than the discipline of consistently using one.

Tool allowlisting and input/output validation enforce the "known tools only" boundary. An allowlist prevents agents from invoking tools outside a defined, reviewed set. Input validation and output filtering interrupt injection payloads in both directions — on the way into the model's context, and on the way out through the agent's actions. Neither control alone is sufficient, and their absence is a policy failure, not merely a technical gap.

Centralized logging must tie prompts to tool calls to enable investigation, not just monitoring. Knowing that something went wrong is insufficient without the ability to reconstruct the sequence of tool invocations that produced it. The NSA's May 2026 guidance adds filtering outgoing proxies and data loss prevention controls as explicit defenses against exfiltration, the downstream risk when an injection or poisoning attack succeeds.

Human-in-the-loop controls for high-risk operations are not optional. Agents should handle sensitive credentials only through structured approval gates. The "1Password for AI Agents" model, where agents request credentials scoped to specific operations rather than holding them directly, demonstrates that this is an engineering problem with workable solutions. It is not a contradiction of the agentic model.

Finally, pre-deployment scanning should function as a gate, not a retrospective audit. Tools like Cisco's mcp-scanner, released in 2025, and Invariant Labs' mcp-scan exist specifically to analyze MCP servers before integration. Discovering a vulnerability after an agent has been running in production with broad tool access is a qualitatively different problem than catching it before the agent ever runs.

Why Environment Reproducibility Is the Precondition for Making These Controls Enforceable

Every security control described above is a statement about a specific, known environment. An allowlist is only enforceable if you know which tool versions are running. A sandboxing policy is only effective if the sandbox is consistently constructed. Input validation logic only behaves predictably if the runtime it executes in is stable. Strip away reproducibility and these controls don't weaken — they become decorative.

Without reproducibility, enforcement becomes a function of luck and individual discipline rather than architecture, and individual discipline fails at scale. This is a practical concern, not a theoretical one. It is what happens to environments left without deliberate governance. I've seen it repeatedly — the policy exists, the intention is there, and the environment has quietly drifted into a state that makes the policy unenforceable.

The failure modes are ordinary, which is precisely why they persist. Dependency drift occurs when a local toolchain diverges from the CI environment over weeks of normal development; nobody notices until a security control behaves differently in production than it did in testing. Version manager sprawl, where each language in a project has its own version manager and none of them are coordinated, means the MCP server versions actually running on a given machine differ from what was reviewed and approved. Onboarding documentation describing fifteen manual setup steps, last updated six months ago, ensures that each developer's environment is slightly different from day one. None of these are exotic failure modes. They are the default state of environments left to accumulate entropy.

In an MCP context, this matters more acutely than in conventional software, because the tools an agent invokes are resolved at runtime against whatever is actually installed. A reproducible environment, one where each component is pinned to a specific verified version and every installation of those components produces an identical result, makes security policies portable across machines, CI pipelines, and production deployments. Cryptographic hashing of packages and their dependency trees, such that identical inputs always produce identical outputs regardless of when or where the build runs, is the technical mechanism that delivers this property. The principle is the same one governing software dependency management — pin, verify, reproduce. It applies to every MCP server in the pipeline, to its version, its definition, its provenance, and the environment it runs in.

AI coding agents and automated pipelines that invoke MCP tools require the same environment rigor as human developers, and in many cases more. An agent running in a drifted environment is running in an unreviewed environment, and unreviewed environments cannot be audited. Platform engineers are positioned to enforce this at the base layer by providing locked, extensible environments that developers and agents activate rather than construct from scratch. That shift moves the security boundary from individual developer discipline to platform infrastructure, where it belongs. The controls enumerated in the previous section become enforceable consistently at that layer. Without it, they cannot be.