Securing MCP servers means governing AI agent tool access

At a glance

What this is: This is a practical security guide on MCP server controls, with the central finding that LLM-driven tool access needs governance above standard API layers.

Why it matters: It matters because IAM, PAM, and NHI teams must control tool-level authorization, token scope, and session behaviour before AI agents can touch sensitive systems.

By the numbers:

• Researchers tested 45 live MCP servers with 1,312 malicious test cases and saw attack rates up to 72.8%.
• The final evaluation cited 94% of prompt injection attacks in MCP-related testing and a 10.8% successful attack rate against earlier safeguards.

Context

MCP servers create a control problem that sits above conventional API security. The issue is not just transport or endpoint exposure, but the fact that an LLM reads tool descriptions, chooses actions, and inherits whatever scope is present at session start.

That changes the identity governance question for AI agents and the non-human identities they use. In practice, the programme has to govern tool selection, token scope, and approval boundaries rather than assume a gateway or WAF will see the meaningful policy decision.

Key questions

Q: What breaks when MCP servers rely on session-wide scopes?

A: Session-wide scopes collapse least privilege into a single inherited trust decision, so one compromised token or prompt injection can reach every tool granted at start. That creates a large blast radius, especially when tools can read sensitive data or make changes. Security teams need per-tool enforcement because session initialization alone does not control later action selection.

Q: Why do MCP servers need controls beyond API gateways and WAFs?

A: Because the policy decision happens where the LLM interprets tool descriptions and selects actions, not just where HTTP traffic enters the system. API gateways and WAFs can inspect transport, but they cannot reliably judge tool intent, hidden instructions, or session state. That is why MCP requires tool-level authorisation, logging, and approval.

Q: What are the signs that an MCP deployment is becoming too permissive?

A: Common warning signs include AI applications reaching systems they do not need, broad tool exposure without business justification, and no clear separation between read and action permissions. Another red flag is when teams cannot explain which server can access which source. If the integration map is unclear, the control model is probably too loose.

Q: Should organisations require human approval for all MCP actions?

A: No. Human approval is most valuable for high-risk operations such as destructive changes, large exports, and billing or access modifications. Low-risk read-only tasks can remain automated if the request is tightly scoped and continuously validated. The key is to separate reversible machine tasks from irreversible actions that need accountability.

Technical breakdown

Why MCP policy decisions live above the HTTP layer

MCP moves the security decision point away from simple request and response inspection. Tool descriptions, schemas, and session state guide the LLM’s next action, so a gateway that only sees HTTP cannot judge whether the tool choice is safe. This creates a policy gap between transport enforcement and runtime intent. The practical problem is that the most important authorisation event may occur after authentication, when the model decides which tool to call and with what arguments.

Practical implication: Treat tool selection and dispatch as enforceable security events, not just application behaviour.

How stateful MCP sessions expand blast radius

An MCP session is stateful, so a single token can inherit every tool and scope granted at initialisation. If one prompt injection or one compromised session token succeeds, the resulting blast radius is the full session entitlement, not just one call. That makes session-wide grants especially risky when tools can mutate systems, read sensitive data, or reach downstream APIs. Scope validation only at session start leaves later tool calls effectively ungoverned.

Practical implication: Validate scope at both session start and each tools/call dispatch.

Why tool poisoning and prompt injection evade normal controls

Tool poisoning hides malicious instructions in descriptions, schemas, metadata, or tool outputs, while prompt injection uses valid natural language that signature-based filters often accept. In MCP, the model can treat those strings as instructions because the consumer is the LLM, not a human reviewer. That means malicious guidance can arrive through normal protocol content, not just obviously hostile payloads. Integrity checks on tool definitions help, but they must be paired with runtime governance and approval for high-impact actions.

Practical implication: Hash-pin tool definitions and require human approval for sensitive actions.

Threat narrative

Attacker objective: The objective is to obtain broad, tool-level access that lets the attacker or malicious server exfiltrate data or perform sensitive actions inside connected systems.

1. Entry occurs when a developer or user installs an unvetted third-party MCP server and grants it broad OAuth scopes.
2. Credential access happens when the session token or delegated scope exposes every tool allowed at initialisation, creating a large inherited trust boundary.
3. Impact follows when the LLM uses those tools to read, modify, or exfiltrate sensitive data through actions the gateway never evaluated as high risk.

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

MCP security is an authorisation problem before it is a transport problem: the decisive control point is tool choice, not packet inspection. Standard API gateways, WAFs, and HTTP logs were designed for request-centric systems, while MCP lets an LLM interpret natural-language tool descriptions and act on them. That means governance has to move up the stack to the tool layer, where identity and intent actually meet. Practitioners should treat MCP as a new authorisation surface, not an API variant.

Broad session scopes create identity blast radius debt: the assumption that a single granted token can safely carry a session no longer holds when one model invocation can traverse multiple tools and state changes. The practical consequence is that least privilege must be expressed per tool and per action, not as a blanket entitlement at session start. This is where OWASP-NHI and zero trust principles intersect most sharply for AI agent access. Teams need to re-evaluate how much trust they place in session persistence.

Tool descriptions have become a governance input, not just documentation: when the consumer is an LLM, metadata can behave like policy. That makes hash-pinning, tool namespacing, and supply chain vetting part of identity governance, because malicious or altered tool definitions can steer behaviour after review. Runtime governance gap: static approval is not enough when a server can change behaviour after onboarding. Practitioners should assume the control plane must watch for post-deployment drift.

Human approval still matters, but only for the right actions: the article correctly separates low-risk reads from high-impact mutations such as credential access, deletion, and admin commands. That distinction is important because it prevents blanket friction while preserving a control point where irreversible actions occur. The lesson for identity programmes is to tie approval to impact classification, correlation IDs, and auditable context. Security teams should make escalation explicit rather than rely on model restraint.

Stateful agent sessions demand detection designed for delegation chains: when one identity path can touch tools, downstream APIs, and logs, correlation becomes essential to investigation. The right model is end-to-end visibility across identity, tool name, parameters, and downstream effects, because isolated logs will miss the policy-relevant event. This is the practical edge of NHI governance for AI agents. Organisations should align detection with delegated execution, not just with authentication events.

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.
• Read next: MCP Security Guide

What this signals

Runtime governance gap: MCP programmes will increasingly fail where teams stop at authentication and forget that the real control point is tool dispatch. Session-wide trust is too coarse when a model can move from read to write inside one conversation, so policy needs to follow the action path, not the network path.

MCP also sharpens the governance problem for AI agents using non-human identities. If a tool description can steer behaviour and a session token can inherit broad scope, then onboarding, offboarding, and approval are no longer separate operations; they are one continuous control loop.

For practitioners

• Enforce per-tool scope validation Validate authorisation at session start and again at each tools/call dispatch so a hijacked session cannot reuse a broad entitlement across unrelated tools.
• Hash-pin tool definitions Store and verify the name, description, and input schema for every registered tool so changes after approval trigger a security review instead of silent reuse.
• Separate read tools from exfiltration tools Do not co-load untrusted-content readers with email, HTTP POST, or file upload tools in the same session, because one injected prompt can combine them into a data path.
• Classify approvals by action impact Require explicit approval for credential access, file deletion, and administrative commands, while allowing low-risk reads to execute with logging and correlation only.
• Record end-to-end tool telemetry Log identity, tool name, parameters, response status, and a correlation ID that follows downstream HTTP calls so investigations can reconstruct what the model actually did.

Key takeaways

• MCP server risk comes from policy decisions that happen above the HTTP layer, where model-driven tool selection can bypass familiar transport controls.
• Stateful sessions and broad scopes can turn one compromised token or one injected prompt into broad access across multiple tools and systems.
• The most effective response is to validate scope per tool call, pin tool definitions, and reserve human approval for high-impact actions.

Key terms

• Tool Dispatch: Tool dispatch is the moment an AI system chooses and invokes a tool based on available descriptions, state, and permissions. In MCP, this is where policy becomes operational, because the security decision is no longer just network access but the specific action the model is about to execute.
• Workflow Blast Radius: Workflow blast radius is the amount of damage a compromised workflow can cause before it is stopped or contained. In identity and security terms, it describes how far a malicious action, bad automation step, or stolen credential can spread across systems, data, and permissions within a process.
• 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.
• Correlation Identifier: A correlation identifier is a shared trace value used to link events from different systems into one chain of evidence. In coding agent monitoring, it connects gateway logs to agent spans so teams can trace a risky action back to the specific session, input, and tool call that produced it.

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.