Securing MCP servers means governing AI agent tool access

At a glance

What this is: MCP servers create a distinct security layer for AI agent tool access, with the key finding that existing API controls miss the policy decisions made by LLM-driven sessions.

Why it matters: IAM, NHI, and security teams need to govern MCP as a separate identity and authorisation model because broad scopes, hidden tool logic, and stateful tokens can expand blast radius quickly.

By the numbers:

• Researchers tested this across 45 live MCP servers with 1,312 malicious test cases and saw attack rates up to 72.8%.
• The first confirmed malicious MCP server, postmark-mcp, was downloaded more than 1,600 times before it was removed.
• 94% of prompt injection attacks in MCP-related evaluations and shows a 10.8% successful attack rate against earlier safeguards in one evaluation.

👉 Read Panther's blog on practical controls for securing an MCP server

Context

MCP, or Model Context Protocol, connects AI agents to tools and data sources, but that convenience creates a governance gap when the consumer is an LLM making runtime decisions about what to call and when. In practice, the security model has to account for the identity that is acting, the scope it inherits, and the tools it can reach, not just the API endpoint being exposed.

For IAM and NHI programmes, the issue is not whether tools are authenticated. It is whether tool access is scoped, logged, and constrained at the same layer where the agent makes decisions. That is why MCP needs controls for tool-level authorisation, session boundaries, supply chain vetting, and auditability, alongside the usual transport and secret-management controls.

Key questions

Q: How should security teams govern AI agents that use service accounts and MCP tools?

A: Start with ownership, then add runtime attribution and containment. Security teams should know which human deployed the agent, which identity the agent uses, what tools it can invoke, and when to revoke access. If the agent can chain tool calls or spawn sub-agents, governance must cover those paths as well, not just the initial login.

Q: Why do broad session scopes create more risk for MCP than for normal APIs?

A: Because MCP sessions are stateful and the LLM can chain decisions within one token's lifetime. If a broad scope is granted once, a single malicious prompt or tool change can reuse that access across multiple calls. The safer pattern is use-case-scoped access with expiry and re-authorisation.

Q: What breaks when MCP tool definitions change without re-approval?

A: What breaks is the assumption that a previously trusted tool still behaves the same way. If definitions can change silently between sessions, the agent may continue using a modified capability under old approval. That undermines auditability, makes security reviews stale, and hides new malicious instructions.

Q: Who is accountable when an AI agent takes action through an MCP server?

A: The accountable party is the human or team that authorised the agent's access, but only if the organisation can prove that chain. Without immutable logs that connect the initiating identity to the tool call and final action, accountability becomes weak, and legal or compliance teams lose the evidence they need.

Technical breakdown

Why MCP changes the identity boundary for AI agents

MCP defines a tool-mediated control plane where the LLM reads descriptions, chooses actions, and executes calls through a stateful session. That means authorisation cannot stop at connection setup, because the most important decision is often made later, when the agent selects a tool and arguments. If the session token covers broad entitlements, one successful prompt injection or malicious tool change can inherit the full session scope. The security model therefore has to treat tool access as an identity and policy problem, not only an API problem.

Practical implication: enforce per-tool scope validation at dispatch, not just at session start.

Tool poisoning, rug pulls, and prompt injection

Tool poisoning occurs when malicious instructions are hidden in tool metadata, schemas, or outputs, and the model treats them as trusted context. Prompt injection works because the payload is valid natural language, which bypasses signature-based inspection. Rug pull attacks exploit protocol features that let tool definitions change after initial approval, so a safe-looking server can become dangerous later without an obvious re-onboarding event. These are identity-adjacent failures because they change what the agent is authorised to do without changing the nominal connection.

Practical implication: hash-pin tool definitions and monitor for post-registration schema drift.

Why runtime isolation matters as much as scopes

MCP servers can run locally over stdio or remotely over HTTP, and each transport changes the attack surface. If a server is compromised, the next layer of defence is runtime containment: sandboxing, egress restriction, rate limits, and secret injection from a vault instead of baked-in credentials. Transport checks, TLS validation, and mTLS help establish server identity, but they do not reduce the damage a hijacked server can cause once it is trusted. The architecture has to assume tool abuse will happen and narrow the blast radius accordingly.

Practical implication: combine transport verification with sandboxing, egress control, and short-lived secrets.

Threat narrative

Attacker objective: The attacker aims to convert trusted AI tool access into unauthorised data movement, system modification, or credential exposure using the agent's own authorised session.

1. Entry occurs when a developer installs a third-party MCP server and grants it broad OAuth scopes or connects it to sensitive production data.
2. Escalation follows when the model consumes malicious tool descriptions, inherits broad session scope, or accepts changed tool definitions after initial review.
3. Impact is achieved through unauthorised tool execution, data exfiltration, or destructive actions performed with legitimate session authority.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• Meta AI Instagram Account Takeover — 20,225 Instagram accounts hijacked via compromised Meta AI support chatbot with overprivileged access.

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 introduces a policy boundary that classic API security does not cover: the LLM is not just consuming data, it is choosing actions from natural-language descriptions in a stateful session. That breaks the assumption that transport security and endpoint authentication are enough to define access. The practical conclusion is that tool selection and tool dispatch are identity events, not just application events.

Session-wide privilege is the wrong unit of control for agentic tool use: broad OAuth scopes, long-lived tokens, and inherited permissions turn one agent session into a high-blast-radius identity. That model was tolerable for users making explicit requests, but it fails when the actor can chain tool calls autonomously within one session. Practitioners should treat scope granularity as a governance boundary, not a convenience setting.

Tool definitions themselves are part of the security perimeter: if descriptions, schemas, or tool lists can change after approval, then the thing being authorised is no longer the thing being executed. That is a governance failure, not only a detection problem. The named concept here is tool-definition drift, and it means approval at registration time does not survive post-registration mutation.

Supply chain trust extends into MCP package selection and server onboarding: pulling a third-party server from npm or another ecosystem places identity risk into the software acquisition path. A trusted package can still behave like an attack surface if publishers, versions, or permissions are not continuously checked. The implication is that NHI governance now includes package vetting, version pinning, and runtime monitoring for agent-facing services.

Human approval remains necessary for high-impact agent actions because accountability does not disappear when the actor is non-human: delete, credential access, and admin commands need a control point that is separate from the model's internal decision path. This is where PAM-style governance and NHI governance meet. Practitioners should not let model confidence substitute for human accountability on high-impact actions.

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.
• Another finding in the same research shows that 53% of MCP servers expose credentials through hard-coded values in configuration files.
• For broader context on agentic application risk, see OWASP Agentic Applications Top 10 and use it to frame MCP governance alongside tool misuse and identity abuse.

What this signals

Tool-definition drift will become a routine governance concern as more teams adopt MCP-style integrations. If tool metadata can change after onboarding, then change control, schema hashing, and runtime validation need to sit alongside standard IAM review cycles. The practical signal is that AI agent access reviews will increasingly depend on evidence from execution logs, not just entitlement records.

With 18% of deployments implementing access scoping for tool permissions, the category is still operating with a structural control gap, not a tuning problem. That gap will matter most where MCP connects agents to CRM, ticketing, and internal documentation systems, because those environments combine sensitive data with write-capable workflows. Teams should expect audit and incident-response requirements to move toward per-tool evidence and session traceability, not simple app-level logging.

MCP governance should now be read through the same lens as OWASP Agentic AI Top 10 because the risk is not only model behaviour, but the authorisation surface created around it. The next maturity step is to align identity controls, approval gates, and runtime isolation into one operating model before agent use becomes widespread.

For practitioners

• Scope MCP sessions per tool and use case Validate authorisation again at every tools/call dispatch, not only at session initialisation. Replace broad session-wide grants such as files:* or db:* with narrow entitlements tied to the exact action being performed.
• Hash-pin tool definitions and watch for drift Store a schema hash for each registered tool and compare it before every session starts. Alert when descriptions, inputs, or available tool lists change after review, because that can signal tool-definition drift or a rug pull.
• Isolate MCP runtimes and restrict egress Run MCP servers in a sandboxed container or VM, inject credentials at runtime from a vault, and block access to localhost, metadata services, and unapproved outbound destinations. Narrow the blast radius if a session or server is compromised.
• Require approval for high-impact tool actions Put explicit human approval in front of destructive or credential-sensitive actions such as delete_user, secret access, and admin commands. Deny by default when the approval path is unavailable, rather than allowing the model to proceed autonomously.
• Log every tool call with full identity context Capture the identity, tool name, parameters, response status, correlation ID, and schema hash for each invocation. That evidence is what makes investigation, containment, and post-incident review possible when AI-driven tool use crosses systems.

Key takeaways

• MCP exposes a security boundary that classic API controls do not cover, because the model makes tool decisions inside the session.
• Broad session scopes, mutable tool definitions, and weak runtime isolation create the conditions for unauthorised agent behaviour.
• Security teams should respond with per-tool authorisation, tool hashing, sandboxing, and mandatory approval for high-impact actions.

Key terms

• Model Context Protocol: Model Context Protocol is an open protocol that lets AI agents connect to tools and data sources. It expands what an agent can reach, so governance has to cover not only the model and its prompts, but also every system that can receive or return agent-driven data.
• Tool-definition drift: A mismatch between the tool definition that was approved and the tool definition that is later executed. Drift can happen when descriptions, schemas, or tool lists change after onboarding, which means a prior review no longer reflects the live authorisation surface.
• Session-wide privilege: Access granted for the full lifetime of a session rather than for a single action or tool call. In MCP and agentic systems, this creates a large blast radius because one token or approval can be reused across multiple actions, systems, and outputs without fresh validation.
• Prompt Injection (Agentic): An attack where malicious instructions are embedded in content that an AI agent reads — causing the agent to execute unintended actions using its own legitimate credentials. A primary vector for agent goal hijacking and identity abuse.

What's in the full article

Panther's full blog covers the operational detail this post intentionally leaves for the source:

• Step-by-step controls for OAuth 2.0, PKCE, and client-credentials patterns in MCP deployments
• Specific runtime hardening guidance for stdio and Streamable HTTP transports, including sandbox and egress choices
• Detection details such as correlation IDs, schema hashes, and fields to capture in tool-call logs
• Examples of tool-scoping patterns for read-only versus high-impact agent actions

👉 Panther's full post covers transport hardening, scope validation, and detection details for MCP servers.

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 building or maturing an identity security programme, it is worth exploring.