MCP security needs identity context before tool access scales

At a glance

What this is: This is an analysis of MCP security that says the protocol’s utility becomes risk when tool access is detached from user identity, policy, and audit context.

Why it matters: It matters because IAM, PAM, and AI governance teams need identity context around tool calls before LLM-driven workflows can be trusted in production.

Context

MCP, the Model Context Protocol, standardises how large language models call external tools and services, which makes it easier to connect AI systems to real business actions. The security problem is that the protocol does not by itself tell you who is asking, what they are allowed to do, or whether the request should be blocked.

That gap matters because once tool invocation scales, identity decisions cannot remain implicit or simulated. If the user context, role, risk, and approval path are missing, the model can act with more reach than the enterprise’s governance model was designed to permit.

In this article, the central question is not whether MCP is useful. It is whether access decisions remain defensible when LLMs begin to operate through tools at production speed.

Key questions

Q: How should security teams govern MCP tool access in enterprise environments?

A: Security teams should bind MCP tool access to enterprise identities, entitlements, and lifecycle state before a request reaches production tools. A gateway can enforce policy at the edge, but governance only exists when the identity system knows who is calling, what they are allowed to do, and whether approval or offboarding has already occurred.

Q: Why do unchecked MCP tool calls create more risk than ordinary automation?

A: Unchecked MCP calls are riskier because they let a model initiate actions with real-world side effects without the same identity checks that govern human or service access. That breaks the normal assumption that high-impact actions are tied to explicit authority, making privilege expansion and unauthorised execution much easier to miss.

Q: What breaks when MCP tool registries are not controlled?

A: When registries are not controlled, malicious or poisoned tool definitions can enter the workflow as if they were legitimate. The result is an execution path where the model trusts the tool source, but the organisation has no assurance that the source, function, or permissions align with policy.

Q: How do approval gates change MCP governance for high-risk actions?

A: Approval gates stop sensitive actions from becoming model-only decisions. They preserve human accountability for requests that can alter permissions, move money, or touch sensitive systems, while still allowing lower-risk tool use to proceed under policy. That separation is essential when a model can act faster than a human reviewer can react.

Technical breakdown

How MCP routes tool calls through a standard interface

MCP defines a structured way for models to discover tools, learn the request shape, and submit function calls through an MCP server. That avoids ad hoc integrations and gives the model a predictable contract for external actions. Security changes at the boundary: once the model can invoke tools, the trust decision is no longer only about the prompt or the model output, but about whether the tool request is authorised, scoped, and attributable. In practice, the protocol becomes an execution bridge between model intent and real-world side effects.

Practical implication: treat MCP tool discovery and invocation as an access-control boundary, not just an integration layer.

Why missing identity context creates policy blind spots

The article’s core technical point is that tool calls without user context remove the data needed to enforce policy. Roles, entitlements, and risk signals normally determine whether a request is allowed, but MCP workflows can strip that linkage if the model acts without a verified identity context. That creates a control vacuum where the system knows a function was called, yet cannot reliably say on whose authority, under what approval model, or with what privilege constraints. The result is not just weaker logging, but weaker authorisation itself.

Practical implication: bind every MCP request to a verified user identity, entitlement set, and risk posture before execution begins.

Why trusted registries and approvals matter for MCP security

MCP introduces a second trust problem beyond tool invocation itself: where the tool definition comes from. If tool registries are uncontrolled, malicious or poisoned definitions can masquerade as legitimate functionality and become the entry point for abuse. The article also notes that some tool actions need human approval, which means the security model must distinguish ordinary calls from high-impact actions that require a gate. In short, authorisation, provenance, and review all sit on the same control path.

Practical implication: curate MCP tool registries and reserve approval gates for actions with real business impact.

Threat narrative

Attacker objective: The objective is to make the model execute sensitive tool actions or expose backend services without the identity checks that would normally block them.

1. Entry occurs when an attacker or untrusted source introduces a malicious tool definition through an uncontrolled MCP registry or uses over-broad tool access.
2. Credential or authority abuse follows when the model invokes tools without reliable user context, allowing actions beyond the intended identity scope.
3. Impact lands when those calls reach sensitive APIs or privileged functions with no trustworthy audit trail or approval gate to stop them.

Breaches seen in the wild

• Moltbook AI agent keys breach: Moltbook breach exposed 1.5M AI agent keys.
• LiteLLM PyPI package breach: LiteLLM PyPI supply chain attack, credentials stolen from users.

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 creates an identity context gap, not just a new integration layer: The article shows that the real failure mode is not tool access itself but the loss of user context when models act through MCP. That context gap breaks the normal IAM logic that ties action to a known subject, known authority, and known risk. The practitioner implication is that MCP security has to be assessed as an identity problem before it is treated as an AI tooling problem.

Unchecked tool invocation is a privilege problem disguised as automation: When a model can reach databases, payments, or administrative functions without contextual policy checks, the organisation has effectively extended privilege into the prompt layer. That is a governance failure because the enterprise has delegated action without preserving the authorisation evidence needed to justify it. Practitioners should treat every MCP function as a potential privilege boundary, not a convenience feature.

Identity-aware policy enforcement is the control plane that makes MCP governable: The article’s strongest practical insight is that runtime evaluation against role, entitlements, and risk level is the only way to keep tool use inside policy. Static allowlists are too brittle when tool access is dynamic and context-sensitive. The control question becomes whether the policy engine can see who is behind the request before the model commits to the action.

Trusted tool provenance is now part of identity governance: A curated registry is not just a software hygiene measure, it is a governance requirement because tool definitions can be as dangerous as credentials when they are unvetted. This extends identity control from the user and the workload to the source of the tool itself. For practitioners, MCP governance now spans identity, registry trust, and execution control in one chain.

Identity context is the named concept that will separate safe MCP from operational sprawl: Identity context means the verified user, entitlement, and risk data attached to a tool request before execution. Without it, the enterprise cannot explain why a call was allowed, blocked, or approved, which makes incident review and policy enforcement structurally weak. The implication is that MCP adoption has to be sequenced with identity orchestration, not layered on afterwards.

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.
• AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers, according to the State of Secrets Sprawl 2026.
• Read next: MCP Security Guide

What this signals

Identity context is now the gating control for tool-using AI: MCP adoption changes the programme question from whether a model can reach a tool to whether the organisation can prove the request was authorised by the right identity at the right risk level. That is a governance design problem, not a plugin problem, and it belongs in IAM, PAM, and AI access policy discussions together.

Tool registries now sit inside the trust boundary: Once external tools are discoverable by models, registry governance becomes part of identity assurance because unvetted definitions can become execution paths. The control objective is to ensure the request, the tool source, and the privilege path all line up before the model is allowed to act.

For practitioners

• Bind tool calls to verified identity context Require each MCP request to carry the user identity, roles, groups, entitlements, and risk signals that determine whether the action is allowed.
• Enforce runtime policy checks before execution Evaluate each tool invocation against dynamic policy at the point of use, not only at registration or configuration time.
• Curate MCP registries and reject unvetted tools Limit tool discovery to known-good definitions that are mapped to governance rules and approval requirements.
• Insert approval gates for high-impact actions Pause requests that can change permissions, move money, or access sensitive systems until a human reviewer confirms the context.
• Log prompt-to-action traces end to end Record the prompt, the verified identity, the policy decision, and the function response so investigations can reconstruct why a tool call happened.

Key takeaways

• MCP extends model utility, but the article shows that utility becomes a security issue when identity context is missing from tool decisions.
• The main failure pattern is not one weak control but a chain of weak controls around authorisation, registry trust, and auditability.
• Practitioners should make identity-aware policy enforcement the default before tool access scales beyond controlled pilots.

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.
• Identity context: The entitlement, ownership, and purpose information that explains why an action occurred and whether it was expected. For security operations, identity context turns raw alerts into decisions by showing which human or non-human identity acted and what it was allowed to do.
• Tool Registry: A tool registry is a managed catalog of approved MCP servers, connectors, or other tools that AI agents are allowed to use. It gives administrators a single place to define what is available, who can access it, and under what conditions. This reduces shadow integrations and helps standardize review and audit practices.
• Runtime Policy Enforcement: Runtime policy enforcement evaluates a request at the moment it is executed instead of relying only on preconfigured permissions. For AI agents, this allows decisions to reflect current context, target sensitivity, and behavioural signals rather than static assumptions.

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.