MCP security gaps span secrets, poisoning and runtime abuse

At a glance

What this is: PipeLab’s 2026 MCP snapshot shows that exposed secrets, tool poisoning, injection, and malicious servers are all active risks across the emerging agent integration layer.

Why it matters: IAM, NHI, and agentic AI teams need to treat MCP as a live trust boundary, because existing controls only cover parts of the attack surface and leave gaps at runtime, in supply chain, and in configuration.

By the numbers:

• 82% of 2,614 analyzed MCP implementations use file operations prone to path traversal.
• 67% use APIs related to code injection.
• The first publicly documented malicious MCP server, postmark-mcp, reached about 300 real organizations before disclosure.

Context

MCP security is the problem of governing how AI agents connect to tools, data sources, and actions without treating every connected server as inherently trusted. In this report, PipeLab argues that the risk is not theoretical: secrets exposure, poisoned tool content, and insecure server behaviour already overlap in production-like deployments.

The identity issue is broader than one protocol. MCP turns tool access into a runtime governance problem for MCP security and related agent control layers, because the agent inherits trust from configuration, content, and transport rather than from a single static permission check.

Key questions

Q: What breaks when MCP tools are treated as trusted by default?

A: When MCP tools are trusted by default, a poisoned or spoofed component can inherit privileged access, manipulate outputs, or expose secrets without crossing a traditional perimeter. The failure is not only technical compromise. It is the assumption that registration equals trust. Teams should verify provenance, scope permissions tightly, and review tool behaviour continuously.

Q: Why do MCP deployments increase risk if organisations do not govern tool permissions and secrets carefully?

A: MCP can accelerate AI agent access to tools and data, but that also concentrates trust in a small set of configuration and credential paths. Without access scoping, vaulting, and review of how credentials move through the stack, a single misconfiguration can expose many systems at once. The risk grows because machine access is often persistent, automated, and harder to audit than human access.

Q: What are the signs that an MCP server has become a supply chain risk?

A: Look for packages that ship clean versions first, then change behaviour later, or for servers with broad workflow reach but weak review, provenance, and revocation. The warning sign is not just malware code. It is an integration that gains the same operational trust as a governed service without the same lifecycle controls.

Q: How should security teams decide between gateways, scanners, and runtime inspection for MCP?

A: Use gateways for routing and policy enforcement, scanners for pre-deploy review of tool definitions, and runtime inspection for poisoned content, arguments, and responses. None of the three covers the full attack surface on its own, so the decision is not either-or. It is which combination closes your most likely failure mode first.

Technical breakdown

Why MCP tool poisoning works at runtime

Tool poisoning succeeds because MCP clients often place tool descriptions and tool output into the agent context as if they were trustworthy instructions. That means a malicious or compromised server can smuggle instructions through metadata or returned content, and the model may act on them before any human sees the prompt. The control failure is not just weak sanitisation. It is the assumption that tool text is safe because it arrived through the protocol. Once the agent treats content as executable guidance, the trust boundary moves from transport to interpretation. Practical implication: scan tool definitions and responses on every session, not just at install time. See the MCP Security Guide.

Practical implication: Inspect tool descriptions and tool responses at runtime, not only before deployment.

How path traversal and argument injection turn MCP into file abuse

Many MCP servers expose file operations, repository access, or shell-adjacent arguments that are vulnerable if path handling is loose. Path traversal lets an attacker escape the intended directory boundary, while argument injection lets user-controlled values reach underlying commands or file writes. In the Anthropic Git MCP chain, those flaws combined to produce arbitrary file overwrite and then code execution through chained server behaviour. The architectural issue is that the protocol does not enforce safe path semantics by itself. Practical implication: validate every file path and command argument before the tool call is executed. See the Web Application Attacks Guide.

Practical implication: Apply strict path validation and argument sanitisation to every MCP file operation.

Why MCP supply chain risk is now an identity problem

The first malicious MCP server showed that trust can be stolen before runtime even begins. A package can look legitimate, ship clean versions to build confidence, and then add exfiltration logic later. That is a supply chain issue, but it becomes an identity issue the moment the package receives the same operational trust as an approved connector. The server is then acting as a delegated identity path into email, repositories, or agent workflows. Practical implication: treat third-party MCP servers as governed non-human identities, with review, approval, and revocation logic tied to the package lifecycle. Read the Ultimate Guide to NHIs.

Practical implication: Govern third-party MCP servers as lifecycle-managed non-human identities, not disposable integrations.

Threat narrative

Attacker objective: The attacker wants to hijack agent-mediated trust so they can steal secrets, exfiltrate data, or run code through an apparently legitimate MCP path.

1. Entry occurs when an attacker gets a malicious MCP server, poisoned tool description, or vulnerable client library into the agent workflow.
2. Credential harvested or trusted content abused when the agent accepts tool text, repository output, or configuration as legitimate runtime input.
3. Escalation happens when path traversal, argument injection, or auto-approved tool calls expand the attacker’s reach into files, private repos, or outbound channels.
4. Impact is exfiltration, arbitrary file overwrite, command execution, or silent abuse of the connected workflow under the victim’s own trust context.

Breaches seen in the wild

• postmark-mcp malicious MCP server 2025: A fake Postmark MCP server on npm quietly BCC'd every email AI agents sent through it to an attacker, using victims' own Postmark tokens.
• PyPI secrets exposure 2023: Researchers found 3,938 unique secrets in published PyPI packages, 768 still valid; a new release or yank does not remove them.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

MCP security is becoming a delegated identity problem, not just a protocol problem. Once agents rely on third-party servers, package registries, and tool metadata, the attack surface includes trust assignment, not only transport and content. That shifts the core governance question from whether a tool is connected to whether it should ever be allowed to act with the same standing as a governed non-human identity. Practitioners should stop modelling MCP as a narrow integration layer and start modelling it as a runtime delegation boundary.

Tool poisoning shows that trust assumptions collapse at the point of interpretation. The system assumes tool descriptions and responses are inert data, but agent runtimes often elevate them into decision-making context. That is why static review alone misses the problem: the dangerous instruction is not always in code, but in the content the model consumes after authentication. This is why agentic application risks matter even when the payload looks like ordinary metadata. Practitioners need to treat context ingestion as a control boundary, not a convenience feature.

Secrets sprawl in MCP configs is the named risk that makes the category visible to attackers. Exposed tokens, API keys, and service credentials in MCP-related files create a clean entry point before any runtime defence can help. The scale matters because leaked secrets do not just enable one server compromise; they extend the attacker’s reach across multiple connected tools and delegated actions. The implication is straightforward: if secret handling is weak, MCP expands blast radius rather than containing it.

The market is converging on partial controls because no single product class can cover all ten OWASP MCP risks. Gateways, scanners, and runtime inspection each solve different slices of the problem, but none closes the whole chain. That fragmentation is not a weakness of one vendor category; it is a structural property of the threat model. Practitioners should expect layered governance to remain necessary, with procurement and architecture decisions mapped to specific failure modes instead of broad platform claims.

Runtime inspection will matter, but only when it is paired with lifecycle governance over MCP servers themselves. The report shows attack paths that begin with package trust, continue through tool handling, and end in session abuse. That means runtime control is necessary but not sufficient if the connector is already compromised or unmanaged. Practitioners should measure MCP security as a programme that spans approval, inventory, observation, and revocation, not as a point solution exercise.

From our research library:

• 28.65 million new hardcoded secrets were detected in public GitHub commits in 2025 alone, a 34% year-over-year increase and the largest single-year jump ever recorded, according to the State of Secrets Sprawl 2026.
• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to the Ultimate Guide to NHIs.
• Read next: Secrets Management Guide

What this signals

Secrets sprawl is the earliest indicator that MCP governance is already behind runtime adoption. When secrets are sitting in configs, repos, and workflow files, agent access can be abused before any runtime guard sees the traffic. The practical shift is to govern MCP as a lifecycle problem, not only as a protocol problem, because the first compromise often starts before the agent calls a tool.

Runtime delegation will force identity teams to think in terms of trusted content, not only trusted services. If an agent consumes tool descriptions and responses as actionable instructions, then the control boundary is the content pipeline as much as the network path. That makes secret sprawl management and tool provenance part of the same programme, especially where server ownership changes quickly.

MCP security will likely settle into layered control patterns rather than a single dominant architecture. Gateways, scanners, allowlists, and inspection each address different failure modes, so procurement should be mapped to the exact risk class the team expects to fail first. The organisations that do best will be the ones that treat MCP as a governed ecosystem, not a feature checkbox in an agent platform.

For practitioners

• Audit MCP server inventory and ownership Identify every approved MCP server, who owns it, what data it can reach, and whether the approval path is still current.
• Scan tool definitions and responses at runtime Inspect descriptions, arguments, and returned content on every session so hidden instructions and injected data are visible before the agent acts.
• Validate file paths and command arguments strictly Reject escaping paths, canonicalise inputs before authorisation, and block any tool argument that can change the filesystem target or shell behaviour.
• Separate approval from execution Require re-approval when an MCP configuration or package changes, especially after a trusted server has already been introduced into production workflows.
• Map each control to a specific OWASP MCP risk Use the OWASP MCP Top 10 to decide whether the gap is secret exposure, tool poisoning, audit loss, or scope creep before buying more tooling.

Key takeaways

• MCP creates a trust boundary problem where poisoned tool content, malicious servers, and exposed secrets can all steer agent behaviour.
• The article’s evidence shows the category is already large enough for defenders to need multiple controls, not a single product class.
• Practitioners should govern MCP servers, tool content, and secret handling as one lifecycle problem rather than three separate ones.

Related NHI Mgmt Group resources: MCP Security Guide · Guide to the Secret Sprawl Challenge · Secrets Management Guide · Ultimate Guide to NHIs · OWASP Agentic Applications Top 10

Key terms

• MCP tool poisoning: MCP tool poisoning is the practice of hiding malicious instructions in a tool name, description, or metadata exposed by an MCP server. Because those fields are often treated as trusted configuration, the agent may adopt the attacker’s instructions during tool selection or invocation.
• Delegated trust: Delegated trust is the decision to let another system or organization issue, validate, or transmit access on your behalf. It is common in cloud and SaaS environments, but it becomes risky when scope, duration, and revocation are not tightly controlled. In NHI governance, delegated trust must be explicit and continuously reviewable.
• Runtime Inspection: Real-time monitoring of AI prompts and responses while the interaction is happening. Unlike point-in-time review, runtime inspection can detect sensitive data, prompt injection, and harmful outputs during the session, which is essential when risk changes faster than governance cycles.
• Shadow MCP Server: An MCP server that exists in an environment without being fully visible, approved, or governed by the teams responsible for identity and access. In practice, it becomes a hidden trust path for tools, data, and credentials, especially when developers install it directly into agent workflows.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.