MCP server security exposes trust gaps in AI tool access

At a glance

What this is: This analysis breaks down how MCP server security can fail through poisoned metadata, lookalike servers, silent behaviour changes, and pre-consent execution gaps.

Why it matters: IAM and security teams need to treat MCP servers as governed non-human identities because trust decisions based on names alone leave runtime access, provenance, and scope largely unreviewed.

Context

MCP server security is a governance problem as much as a technical one. The protocol standardises how AI hosts discover and invoke tools, but that same convenience means server identity, metadata, and behaviour can all become trust signals even when they should be independently verified.

SlashID's analysis focuses on attack paths that abuse the server layer before any downstream system is reached. That matters for NHI governance because each MCP server behaves like a non-human identity with standing access, yet many organisations still treat it as a simple integration point rather than an identity to inventory and control.

The practical question is not whether MCP can connect models to tools. It is whether the approval model can survive malicious metadata, lookalike registration, silent behaviour drift, and execution that starts before a trust check completes.

Key questions

Q: What breaks when MCP servers are approved once but allowed to change later?

A: The original approval no longer describes the current access surface. If tools, backends, or ownership change after onboarding, the enterprise is operating on stale risk information. That creates blind spots in authorization, logging, and recertification, because the governing record reflects a past state rather than the server’s present capabilities.

Q: Why do MCP servers create new identity risk for AI-native development?

A: MCP servers create risk because they extend delegated access from the model into repositories, data, and workflow tools. If the trust path is too broad, the agent can act with capabilities that were never intended for that task. Teams should review those connections as access paths, not just as integration plumbing.

Q: What are the signs that MCP session controls are failing?

A: Warning signs include permissions carrying over between sessions, inconsistent approval behaviour, and tool calls appearing in an order that does not match the intended workflow. You should also watch for reuse of stale tokens, approvals that were granted once and silently reused, and activity that exceeds the user’s original scope without a fresh consent event.

Q: How should security teams govern MCP servers in production?

A: Treat each MCP server as a governed access boundary, not just a utility. Require publisher verification, tool-level approval, least-privilege scopes, and audit logging before production use. The goal is to control what the agent can reach, how long it can reach it, and how every action is traced for response and compliance.

Technical breakdown

How MCP server identity is established and why that matters

MCP splits the interaction into a host, client, and server, with the client brokering requests to a server that exposes tools, resources, and prompts. The security consequence is that the server's metadata, not just its code, becomes part of the trust surface. If a host treats description text, naming, or a one-time approval as proof of safety, the protocol's convenience can be turned into a governance weakness. The core issue is that the server is both an identity and an execution endpoint, but most approval flows do not bind those two facts tightly enough.

Practical implication: inventory MCP servers as identities and tie approval to server provenance, not just human-readable labels.

Tool poisoning, typosquatting, and rug pulls target different trust assumptions

Tool poisoning abuses the fact that hosts feed metadata to the model as trusted context, so a malicious description can influence tool choice or embed instructions. Typosquatting attacks the selection layer by registering lookalike server names, while rug pulls attack the approval layer by changing behaviour after initial trust has already been granted. These are different techniques, but they all exploit the same weakness: the system assumes that a tool's label, description, and later behaviour will remain aligned. In practice, that assumption fails unless identity, definition, and runtime behaviour are bound together.

Practical implication: validate server naming, metadata, and post-approval drift as separate control points rather than one trust decision.

Command injection and sandbox escape show where pre-consent controls fail

The command injection cases in the article show that execution can occur before a trust dialog finishes, which makes consent-based controls vulnerable to race conditions. The sandbox escape examples show a second failure mode: path checks and filesystem boundaries can be bypassed even when the server appears to be operating within an allowed scope. Together, these issues show that runtime containment and approval prompts are not interchangeable. One controls when execution begins, the other constrains what can happen after it starts, and both can fail independently.

Practical implication: pair pre-execution gating with runtime containment and do not assume a trust prompt or path filter can carry the whole control objective.

Threat narrative

Attacker objective: The attacker wants to convert trusted MCP access into covert execution, credential exposure, or unauthorized control over downstream systems.

1. Entry occurs through malicious MCP server discovery, poisoned metadata, or an attacker-controlled repository that the host opens and trusts.
2. Credential or control access is gained when the host accepts the server's description, starts execution before consent completes, or follows a lookalike server registration.
3. Escalation happens when the server changes behaviour after approval, injects commands, or escapes its expected filesystem or sandbox boundary.
4. Impact is the execution of unauthorized tool actions, leakage of API keys or secrets, and arbitrary code execution on the host or connected environment.

Breaches seen in the wild

• LiteLLM PyPI package breach: LiteLLM PyPI supply chain attack, credentials stolen from users.
• Shai Hulud npm malware campaign: Shai Hulud campaign: npm malware exposed secrets on GitHub.

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 fails when identity is treated as a label instead of a governed runtime actor. The article shows that hosts approve tools by name, description, or one-time prompt, yet the real risk sits in what the server can do after approval. That is an NHI problem, not just an application integration issue, because the server is a standing identity with execution rights. Practitioners should treat every MCP server as an identity object with lifecycle, provenance, and scope.

Metadata trust and runtime trust are now separate control planes. Tool poisoning proves that a description can influence selection, typosquatting proves that a name can mislead discovery, and rug pulls prove that approved behaviour can change after onboarding. Those are three different failure modes, but they all collapse the assumption that a human-readable label is enough to sustain trust over time. The implication is that approval workflows must distinguish documentation from policy and policy from runtime enforcement.

Conventional consent dialogs do not neutralise pre-execution risk. When code can execute before the prompt completes, the governance model has already lost its timing assumption. The same is true when a server can issue requests before trust is explicitly granted. That makes MCP security a problem of control order, not just control presence, and practitioners need to re-evaluate where the first enforceable boundary actually sits.

Sandbox containment is only meaningful if the server cannot redefine its own scope. The path prefix and symlink bypasses show that access rules can be made to look valid while still permitting escape. This is why MCP governance has to include provenance, scope binding, and re-verification, not just a permission list. The broader lesson is that a tool approved once is not necessarily a tool still operating inside its original authorization envelope.

Named concept: trust-bounded MCP identity. The article points to a server identity model that should be bound to verifiable metadata, approved behaviour, and continuous scope validation. Without that binding, the protocol turns convenience into standing access with weak accountability. For practitioners, the control question is whether approval attaches to a mutable string or to a governable identity.

From our research library:

• 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026.
• 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
• Read next: MCP Security Guide

What this signals

Trust-bounded MCP identity: MCP servers need to be governed as identities whose metadata, provenance, and runtime behaviour must stay aligned. If approval remains tied to a mutable label, the organisation has no reliable control over what was actually authorised.

The next operational step is to separate discovery from authorization. A server can be visible, useful, and still untrusted if its definition is unsigned, its registry is weakly moderated, or its behaviour can change without re-verification. That is the point where NHI lifecycle thinking becomes practical for AI tooling.

Access review logic also needs to change. A one-time approval is not a durable control when the server can change scope, execution timing, or filesystem reach after onboarding. Teams should expect identity governance for MCP to move toward continuous validation rather than periodic review.

For practitioners

• Inventory MCP servers as governed identities Record every host-to-server relationship, owner, purpose, approval date, and downstream system touched. Treat the server as an access-bearing identity, not a plugin entry in an app catalog.
• Bind approval to signed server definitions Require a stable hash or signed definition for each MCP server and re-check it on every connection. Block silent changes to description, schema, or allowed actions after initial approval.
• Separate trust prompts from runtime enforcement Assume a trust dialog can fail open if execution begins before consent completes. Add pre-execution gating and runtime containment so a prompt is never the only barrier.
• Re-validate tool provenance and registry quality Reject unverified lookalike servers, duplicate names, and weakly moderated registries unless the server passes ownership and provenance checks. This is especially important where casing or naming rules are inconsistent.
• Review filesystem and resource boundaries Test whether path checks, symlink handling, and allowed-directory rules still hold under crafted input. A server that can escape its declared scope should be treated as a high-risk identity.

Key takeaways

• MCP server security is fundamentally an identity governance problem because the server can act with standing access long after the initial trust decision.
• The article's examples show that metadata manipulation, lookalike registration, silent behaviour changes, and pre-consent execution all undermine the same approval model.
• Controls that bind server provenance, signed definitions, and runtime containment would reduce exposure more effectively than one-time trust prompts alone.

Key terms

• Mcp Server Identity: The identity assigned to the gateway that mediates agent requests to tools and data sources. It matters because the gateway can become a privilege concentration point if it shares credentials with the agent or inherits broader permissions than the task requires.
• 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.
• Trust Prompt: A consent checkpoint that asks a user to approve execution before code or tool access proceeds. In MCP security, a trust prompt is only useful if execution cannot begin before the prompt completes and if later behaviour is still validated against the approved server definition.

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 IAM programme, it is worth exploring.