TL;DR: MCP servers expand AI agent attack surface through tool poisoning, excessive permissions, cross-server leakage and data exfiltration via tool parameters, according to Repello AI, making pre-install and post-install testing essential before connecting them to agents. The control problem is not just trust in one server, but whether the host can govern tool descriptions, parameter boundaries and chained tool use.
At a glance
What this is: This guide explains how MCP servers enlarge an AI agent’s tool surface and why malicious descriptions, broad permissions and chained calls can turn normal integrations into attack paths.
Why it matters: It matters because IAM and security teams now have to govern what an AI agent can invoke, how much each tool may touch, and how multiple MCP servers interact inside one context.
Context
MCP turns tool access into a runtime governance problem: once an AI agent can call databases, APIs, file systems and browsers through connected servers, the trust boundary shifts from the model to every tool it can invoke. The question is no longer whether the agent is useful, but whether each connected server is safe to place in the same decision context.
The practical gap is that many teams still evaluate integrations as if a server were a single permissioned connector. In reality, each tool, parameter and response becomes part of the agent’s operating surface, so a weak description, loose parameter contract or shared context can create a path to unwanted access.
Key questions
Q: What breaks when MCP access is managed separately in each AI client?
A: Governance fragments quickly when each client keeps its own access list. Teams lose a single revocation point, users retain inconsistent permissions, and shadow access grows as people switch between tools. A central policy layer avoids that drift by making the access decision once and enforcing it everywhere.
Q: Why do MCP servers increase risk when tool permissions are too broad?
A: MCP servers can expand risk because they sit between an AI client and sensitive backends, often with enough reach to query data, trigger workflows, or modify records. If permissions are broad, a compromised or misbehaving agent can move from one tool to another with little friction. Least privilege and scoped discovery reduce that blast radius.
Q: How can security teams spot unsafe MCP server behaviour?
A: Look for servers that request secrets, widen access unexpectedly, or accept tokens that were not clearly approved for the current task. Suspicious behaviour also shows up when a server is added without ownership, review, or an offboarding path. Those are signs that the server is functioning as an unmanaged identity rather than a controlled integration point.
Q: Should teams isolate trusted and untrusted MCP servers?
A: Yes, when the servers can influence one another through shared context or broad data access. Isolation reduces the chance that a low-trust integration can steer high-trust operations or leak data across toolchains. Separate sessions are especially important when database, file system and network tools coexist in the same agent workflow.
Technical breakdown
How MCP tool descriptions become an attack surface
MCP tool descriptions are not just documentation. They are machine-readable instructions that help the AI decide when to call a tool and what it can do. If a server hides manipulative language in that metadata, the agent may treat the instruction as part of its operating context rather than as untrusted content. That is why tool poisoning works even when user prompts are filtered. The failure mode sits in the metadata path, not the user input path. Practical implication: inspect tool descriptions as security-sensitive content, not product copy. See the MCP Security Guide.
Practical implication: Treat tool metadata as executable governance input and review it before any server is connected.
Why broad tool permissions widen the effective blast radius
MCP does not natively enforce fine-grained permission scoping. A server advertises tools and the host either allows them or does not, which means the real control point is the host application and its policy layer. When a server can read, write, query or send data more broadly than the task requires, the agent inherits that overreach at runtime. The issue is not only excess access, but excess capability hidden behind a normal-looking integration. Practical implication: define the minimum tool surface before connection and block servers whose scope cannot be constrained. See the NHI Authentication Guide.
Practical implication: Enforce least privilege at the host boundary, not just in the downstream system.
How cross-server context turns one tool into another tool's input
When multiple MCP servers share one AI context, the agent may use output from one server while deciding how to invoke another. That creates a cross-server trust problem: a malicious or compromised server can influence later tool calls by embedding instructions in its own responses. This is not classic network pivoting. It is context pivoting, where language inside one tool response alters the behaviour of the next tool call. Practical implication: isolate high-trust and low-trust servers into separate sessions when they can affect each other’s decisions. Read Zero Trust for AI Agents.
Practical implication: Separate high-trust and low-trust toolchains so one server cannot shape another server’s use.
Threat narrative
Attacker objective: The attacker wants to make the AI agent move sensitive data through trusted tool calls and send it to an attacker-controlled endpoint or an unintended server.
- Initial access begins when an AI agent connects to an MCP server that advertises malicious or overly broad tools.
- Credential access occurs when poisoned tool descriptions, permissive parameters or injected responses steer the agent toward sensitive data sources.
- Escalation follows when the agent chains tools across servers, turning separate capabilities into a data-exfiltration path.
- Impact is the loss of confidentiality through unintended disclosure of files, credentials, query results or other sensitive context.
Breaches seen in the wild
- Smithery.ai MCP hosting breach 2025: A Smithery.ai build flaw gave GitGuardian a live fly.io token controlling 3,000+ hosted MCP servers and the API keys their clients sent.
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
Tool descriptions are now part of the trust perimeter: MCP turns tool metadata into an operational control surface, not a static reference page. Because the agent reads those descriptions to decide what to do, malicious or careless metadata can reshape behaviour before any downstream system is touched. That means governance has to treat descriptions, prompts and parameter contracts as identity-bearing inputs, not documentation. The practitioner conclusion is simple: if metadata can influence action, it must be governed like access.
Context sharing creates a hidden lateral movement channel: Once multiple MCP servers sit inside the same agent context, one server can influence how another server is used without ever touching the second server directly. That is a governance gap, not just an integration flaw, because the trust boundary is the shared context window itself. The implication is that risk review has to include interaction effects between servers, not only the privileges of each server in isolation.
Ephemeral tool trust debt: The article’s core lesson is that the moment an AI agent can accept tool guidance at runtime, trust accumulates faster than most review workflows can see it. A server can be installed, used, and forgotten while its metadata, parameters and responses continue shaping decisions. That is why the security problem is not only who published the server, but how long the agent keeps trusting its claims after connection. The practitioner conclusion is to govern the entire connected tool set as a living identity surface.
Minimal permission on paper is not minimal permission in practice: A database helper or repository connector can appear narrow while still accepting arbitrary inputs, broad queries or downstream network calls. That breaks the assumption that tool purpose alone defines safe scope. In MCP, the real question is whether the tool can be repurposed through parameters and responses. The practitioner conclusion is to validate behaviour, not just advertised function.
Cross-server attacks make MCP a system-of-systems problem: A server with no obvious malicious payload can still become the launch point for exfiltration if its response content changes the agent’s next action. That is the defining governance challenge here: the trust model is distributed across tools, not local to one server. The practitioner conclusion is that MCP review must include chained interactions, not just per-server approvals.
From our research library:
- A May 2025 Gartner poll of 147 CIOs and IT leaders found that 24% had already deployed AI agents, 50% were experimenting and 17% planned to deploy by the end of 2026.
- Read next: MCP Security Guide
What this signals
Context pivoting: In MCP environments, the more important boundary is often between toolchains, not between the model and a single tool. Once one server can shape the agent’s next decision, teams need to think in terms of inter-server influence paths rather than isolated connector approvals.
Review and monitoring have to move closer to runtime because static approval lists cannot capture what a connected agent does with tool responses. That is especially true when tool output can carry instructions, data or unexpected parameters that only become risky after the agent chains them.
A mature programme will treat MCP governance as identity governance for tools: each server needs scope, separation and revocation logic, not just installation approval. That framing makes the operational problem visible before an integration becomes a persistent access path.
For practitioners
- Review tool descriptions before connection Inspect every advertised tool for hidden instructions, unusual wording and references to data or files outside its stated purpose.
- Constrain the permission surface Document what each tool can read, write, query or transmit, then reject integrations whose parameters are too open-ended for the task.
- Separate trust domains by session Run broad-access MCP servers in a different AI session from untrusted or experimental servers so one toolchain cannot shape another.
- Use environment variables for credentials Keep API keys and tokens out of MCP configuration files so the agent does not inherit plain-text secrets in its working context. See the NHI Authentication Guide.
- Monitor tool calls continuously Enable host logging or hooks and review which tools are called, with what parameters and in what sequence, to catch unusual chaining behaviour.
Key takeaways
- MCP servers expand the AI agent attack surface because tool descriptions, parameters and responses can all be abused.
- The article’s testing model shows that the main failure modes are tool poisoning, excessive permissions, cross-server leakage and exfiltration through chained calls.
- Teams should govern connected servers as a live trust perimeter, with isolation, logging and scope review built into the host layer.
Related NHI Mgmt Group resources: MCP Security Guide · NHI Authentication Guide · AI Agent Authorisation Guide · Zero Trust for AI Agents
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | The article repeatedly shows how secrets and sensitive context can leak through MCP tool paths. |
| NHI-05 — Overprivileged NHI | MCP servers often request more access than their stated task needs. | |
| NHI-06 — Insecure Cloud Deployment Configurations | The article stresses host-level configuration and session isolation failures that widen exposure. | |
| Recommendation — Scan MCP configurations and tool outputs for exposed secrets, then revoke any credentials that appear in plain text. Limit each MCP server to the minimum tool scope required and block broad read/write permissions. Separate sensitive MCP tools into constrained sessions and review host settings that allow mixed-trust execution. | ||
| MITRE ATT&CK | TA0006;TA0010 — Credential Access; Exfiltration | The testing model centers on stealing credentials and moving data out through tool chains. |
| Recommendation — Map suspicious MCP tool activity to credential access and exfiltration patterns and hunt for chained abuse. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article is fundamentally about governing what AI agents may access through connected tools. |
| Recommendation — Apply PR.AA-05 to review tool entitlements, parameter scope and server-to-server trust boundaries. | ||
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.
- Cross-server Attacks: Cross-server attacks happen when one connected MCP server influences how an AI agent uses another server through the shared context window. The risk is not direct compromise of the second server, but a trust bridge created by reused context, instructions or data that the agent carries forward.
- Permission surface: Permission surface is the total set of content and systems that an identity can reach, whether or not that access is regularly used. In AI-enabled environments, a large permission surface becomes a direct exposure surface because search and summarisation can traverse it quickly.
- Tool chaining: Tool chaining is the practice of using one capability to unlock the next, such as searching for a secret, authenticating with it, and then using that access to reach another system. For AI agents, tool chaining is the mechanism that turns broad permissions into compound risk.
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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.
Published by the NHIMG editorial team on October 22, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org