MCP server security exposes trust gaps in AI tool access

At a glance

What this is: This analysis breaks down MCP server security failures and shows that the protocol’s trust model can be manipulated through metadata, identity spoofing, silent behaviour change, and pre-consent execution flaws.

Why it matters: It matters because MCP servers function as non-human identities with standing access, so IAM, PAM, and NHI governance teams need inventory, scoping, and re-verification controls before agents inherit unsafe tool trust.

By the numbers:

• Only 18% of MCP server deployments implement any form of access scoping for tool permissions.
• 53% of MCP servers expose credentials through hard-coded values in configuration files.

👉 Read SlashID’s analysis of MCP server security failures and attack paths

Context

MCP server security is really an identity governance problem in protocol form. Once an MCP server is trusted, it can present tools, resources, and prompts that an AI host treats as authoritative, even though those surfaces can be poisoned, renamed, silently changed, or abused before consent gates complete.

For IAM and NHI teams, the central weakness is not simply code execution. It is the assumption that a tool description, server label, or one-time approval accurately represents an identity that may later expand, impersonate, or misbehave at runtime.

That makes MCP server governance closer to managing a fleet of privileged non-human identities than to managing a normal integration. The article’s starting point is typical of early AI adoption: fast tool enablement first, identity control second.

Key questions

Q: What breaks when MCP servers run with shared local trust?

A: Shared local trust breaks isolation because any process on the machine may be able to call the server, and the server may inherit privileges that were never intended for broad reuse. This creates a local attack surface where authentication is bypassed or reduced to process proximity instead of explicit authorisation.

Q: Why do MCP servers create new identity governance issues for NHI programmes?

A: Because they act as access surfaces for software identities, not just as application endpoints. Once an MCP server can invoke tools, read user context, or reach external systems, it needs the same scoping, ownership, and audit discipline used for other non-human identities. The control gap is usually entitlement drift, not authentication alone.

Q: How do security teams reduce the risk of poisoned MCP metadata?

A: They should assume tool descriptions, prompt text, and registry metadata are untrusted input. The control point must be policy enforcement around what a server may invoke, not the wording used to describe it. That prevents instruction injection from becoming access authority.

Q: Who is accountable when a hostile MCP server steals developer secrets?

A: Accountability usually sits with the organisation that allowed the tool to run without sufficient provenance, isolation, and egress controls. In regulated environments, teams should also map the incident to secrets management, privileged access, and software supply chain control obligations.

Technical breakdown

How MCP tool metadata becomes a control plane risk

MCP servers expose metadata, tool lists, resources, and prompt templates to the host, and the host often passes that information into the model as trusted context. That creates a control-plane problem: a tool description can act like documentation or like instruction, depending on how the host and model interpret it. Tool poisoning hides commands in metadata, while preference manipulation biases selection among functionally similar tools. The protocol itself does not separate descriptive text from persuasive or malicious text, so trust is inferred from packaging rather than enforced by identity or policy.

Practical implication: treat tool metadata as untrusted input and require policy checks that separate description from authorization.

Why MCP server identity is vulnerable to typosquatting and rug pulls

MCP servers are selected by name, registry placement, and client trust rather than by a cryptographic identity that binds behaviour to approval. That leaves room for lookalike servers, especially when registries differ in moderation and uniqueness rules. Rug pulls exploit the same weakness after approval: if the server changes behaviour without changing the approved label, many clients keep trusting it. In identity terms, the approved object is the name, but the risk comes from the behaviour behind the name.

Practical implication: bind approval to signed, versioned server definitions instead of relying on a stable display name.

How sandbox escape and command injection break MCP trust boundaries

The technical failures in the article show two different boundary breaks. Command injection can fire before a trust dialog finishes, which means the gate is present but too late. Sandbox escape then extends a legitimate tool call beyond its intended file boundary through weak path checks or symlink abuse. These are not abstract bugs, they are control failures in execution order and scope enforcement. Once the server can act before consent or outside its sandbox, the host has lost the ability to constrain what the non-human identity can do.

Practical implication: require pre-execution gating and path enforcement that is resilient to symlinks, directory tricks, and race conditions.

Threat narrative

Attacker objective: The attacker wants to turn a trusted MCP server into a vehicle for code execution, credential theft, or unauthorized filesystem access through the host’s own approval path.

1. Entry occurs when a victim opens a malicious repository, chooses a typosquatted server, or loads a poisoned MCP configuration that the host treats as trusted context.
2. Escalation follows when the server or its metadata gains access before consent, widens its effective scope, or bypasses path and sandbox enforcement to reach unintended files or commands.
3. Impact is credential exposure, arbitrary code execution, or filesystem compromise through a trusted tool channel that should have remained constrained.

Breaches seen in the wild

• Replit AI Tool Database Deletion — Replit vibe coding AI assistant deletes live production database and creates 4,000 fake user records.
• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

MCP server security is NHI governance, not just application security. Once an MCP server can enumerate tools and execute against external systems, it behaves like a privileged non-human identity with standing access. That means the relevant controls are inventory, scoping, verification, and offboarding, not just code review. Practitioners should treat every server as an identity subject to lifecycle governance.

Tool descriptions are an attack surface, not a neutral label. The article shows that metadata can instruct, bias, or misdirect a model because hosts often relay descriptions into trusted context. That creates a policy ambiguity: the same field can be documentation for humans and command content for agents. The implication is that protocol trust must be decoupled from prose.

Server name trust creates identity blast radius. If approval is tied to a visible label rather than a cryptographic definition of behaviour, typosquatting and rug pulls become governance failures, not edge cases. The named concept here is identity blast radius: how far a malicious or altered server can spread once one approval is granted. Practitioners need to reduce that blast radius by design.

MCP exposes a runtime trust gap between approval and behaviour. A one-time approval model assumes the server’s function stays fixed after review. The article shows that behaviour can change, execution can precede consent, and sandbox boundaries can fail after trust is granted. Security teams should read this as proof that approval state alone is not a durable control.

The control model for MCP must align with non-human identity lifecycle. Discovery, approval, re-verification, and revocation have to work at the server level, because the host is interacting with machine identities that can persist longer than a session or a deployment. That makes MCP governance a direct extension of NHI lifecycle management, not a separate discipline.

From our research:

• Only 18% of MCP server deployments implement any form of access scoping for tool permissions, according to The State of MCP Server Security 2025.
• 53% of MCP servers expose credentials through hard-coded values in configuration files. That is a governance failure, not just a configuration weakness, because the secret and the server identity often fail together.
• For the broader control model, see Ultimate Guide to NHIs for lifecycle, scoping, and revocation patterns that apply to machine identities.

What this signals

Identity blast radius is the right lens for MCP programmes. When server approvals are name-based and metadata can be altered after trust is granted, the real question is how far a single approval can travel across tools, prompts, and external systems. Teams should map that blast radius in the same way they map privileged service accounts, because the failure mode is structural rather than incidental.

With 24,008 unique secrets exposed in MCP configuration files in 2025 alone, according to The State of MCP Server Security 2025, the combination of secrets leakage and weak scoping is already measurable. That should push programmes toward server inventory, approval re-checks, and lifecycle-controlled revocation instead of one-time onboarding.

For teams building controls against this pattern, the relevant benchmark is not whether the server works, but whether it remains the same identity across time. Mature governance means a changed definition, changed registry state, or changed behaviour becomes a trigger for revalidation, not a post-incident clean-up task.

For practitioners

• Build a complete MCP server inventory Record every server, registry source, tool scope, and business owner before allowing hosts to connect. Include unverified servers, local deployments, and one-off project integrations so the inventory can support review and offboarding.
• Bind approval to signed server definitions Require hashes, versioning, and signed definitions for each tool and resource list, then re-verify them on every connection. If the behaviour changes without a corresponding version change, block the server until it is reapproved.
• Separate metadata from authorization Do not let tool descriptions, prompt templates, or registry text influence access decisions. Validate tool identity and permission scope in policy code, not in free-text metadata that can be poisoned or manipulated.
• Harden sandbox and path controls Test against path traversal, symlink tricks, and pre-consent execution paths. Enforce filesystem boundaries with controls that survive directory renaming and race conditions, not simple prefix checks.
• Treat MCP servers as lifecycle-managed identities Apply onboarding, review, and revocation to each server in the same way you would for privileged service accounts. Remove trust promptly when a server’s behaviour, owner, or registry status changes.

Key takeaways

• MCP servers create an identity governance problem because trust is often granted to names and descriptions rather than to stable, verifiable behaviour.
• The article shows multiple failure modes at once, including poisoned metadata, typosquatting, rug pulls, command injection, and sandbox escape, all of which expand the server’s effective blast radius.
• Practitioners should inventory MCP servers, bind approval to signed definitions, and apply lifecycle revocation to non-human identities before AI hosts inherit unsafe access.

Key terms

• MCP Server: An MCP server is a tool endpoint that connects an AI agent to external systems and data sources through Model Context Protocol. Because it extends what the agent can reach, it becomes part of the identity and access surface and must be reviewed like any other privileged connector.
• Tool Poisoning: Tool poisoning is an attack in which malicious instructions are hidden inside tool descriptions, examples, or schemas that an AI agent reads when deciding what to do. The danger is not only in the tool's code, but in the metadata that shapes the agent's behaviour and trust decisions.
• Rugpull: A change in an MCP tool’s advertised behaviour after approval while agents continue using a cached definition. The server appears familiar, but its semantics have shifted, which means the identity and access decision made at approval time no longer matches the live system.
• Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.

What's in the full article

SlashID's full analysis covers the operational detail this post intentionally leaves for the source:

• Controlled reproductions of the pre-patch MCP server flaws and how each exploit chain works in practice.
• The specific trust-dialog, path-check, and registry weaknesses that enabled the attacks against affected versions.
• The article's own reconstruction of tool poisoning, typosquatting, and rug-pull behaviour across MCP server types.
• Implementation context for the reproduced CVEs and the affected pre-patch server versions.

👉 SlashID’s full post covers the reproduced vulnerabilities, server internals, and the attack chains behind each MCP weakness.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an identity security programme, it is worth exploring.