MCP security needs identity context before tool access scales

At a glance

What this is: MCP is the protocol layer that lets LLMs call external tools, and the article’s key finding is that those calls become risky when identity context is not enforced at runtime.

Why it matters: IAM teams need to treat MCP as an identity and access problem because the same governance failures that affect NHI also apply when model-driven actions are tied to human authority and delegated execution.

By the numbers:

• 96% of technology professionals identify AI agents as a growing security threat, and 66% believe this risk is immediate.
• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, inappropriately sharing sensitive data, and revealing access credentials.
• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases.

👉 Read Strata Identity's analysis of MCP security and identity context

Context

MCP is a structured way for large language models to discover and invoke tools, but the security problem starts when those tool calls are detached from the identity of the person or workload that initiated them. Once a model can act through APIs, the old assumption that access decisions are made inside familiar IAM boundaries begins to fail.

For IAM and NHI programmes, MCP introduces a governance gap between the requestor, the model, and the downstream service. The article’s central point is that capability without identity context creates a control blind spot, because role, risk, and approval state are no longer guaranteed to follow the action.

That matters because tool registries, endpoint exposure, and approval gates all become part of the identity plane, not just the application plane. If the request cannot be tied to a verified identity and policy state, the model is effectively operating outside enterprise access control.

Key questions

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

A: Security teams should govern MCP tool access the same way they govern other privileged actions: bind each request to identity, evaluate policy at runtime, and log the full decision path. MCP is not safe because it is structured. It is safe only when the model’s tool call is treated as an access request with a real subject, an entitlement check, and an auditable outcome.

Q: Why do MCP workflows create risk when identity context is missing?

A: MCP workflows create risk when identity context is missing because the model can make or relay actions without a verifiable subject behind them. That breaks accountability, weakens policy enforcement, and makes it impossible to distinguish legitimate automation from unauthorized action. The result is not just a logging gap. It is a control gap in the access decision itself.

Q: What do organisations get wrong about securing model-driven tool use?

A: Organisations often secure the model and ignore the tool boundary. That is backwards. The registry, the API endpoint, the approval step, and the audit trail are all part of the same control path. If any one of those is unsecured, the model can become a conduit into systems that should never be reachable without identity and policy checks.

Q: How do teams know whether MCP controls are actually working?

A: Teams know MCP controls are working when every tool invocation can be traced to a verified identity, a policy decision, and a recorded approval state where required. If logs cannot answer who asked, what was allowed, and why the call ran, then the controls are not governing the workflow. They are only documenting its existence.

Technical breakdown

Identity-aware tool invocation in MCP

MCP defines a standard way for models to discover tools, describe inputs, and execute actions through a server. The security issue is not the protocol itself, but the missing binding between the tool call and the user or workload behind it. When that binding is absent, the model can be treated as if it were the authority, even though it only received a prompt. Identity-aware invocation ties each request to roles, entitlements, and contextual risk before execution, which preserves policy decisions across the model-to-tool boundary.

Practical implication: force every MCP tool call through a verified identity check before execution.

Untrusted registries and insecure endpoints

MCP expands the attack surface by introducing registries and external tool definitions that may not be controlled by the original developer. If a registry is poisoned, the model can be steered toward malicious tool definitions that look legitimate enough to use. Even when the registry is safe, exposed APIs behind the tools can be attacked directly, bypassing the model layer entirely. This is why the trust boundary has to include both the discovery path and the execution endpoint, not just the model prompt.

Practical implication: restrict tool registries to curated sources and secure the underlying APIs as privileged services.

Audit trails and approval gates for high-risk actions

MCP workflows often fail when tool calls are not logged with enough identity detail to reconstruct who asked for what and why. That leaves incident response with an action but no accountable subject. For sensitive operations, human approval gates act as a compensating control, but only if they are bound to identity and risk rather than treated as a generic workflow step. In practice, auditability and approval are the controls that turn model-assisted action into governable access.

Practical implication: require identity-linked logging and approval for actions that change permissions, data, or money movement.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• AI LLM hijack breach — attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Identity context is the control plane for MCP, not an optional wrapper. The article is right to treat missing user context as the root cause behind most MCP risks. Once tool calls are separated from a verified identity, traditional role and policy enforcement no longer has a reliable subject to evaluate. For practitioners, that means MCP belongs in the identity governance conversation, not just the application integration stack.

Trusted tool discovery is now a governance problem, not only a software supply chain problem. Uncontrolled registries let malicious tool definitions enter the decision path before any downstream action happens. That changes the nature of third-party trust, because the model can consume a poisoned control surface as if it were legitimate. Practitioners should treat tool registries as governed access surfaces with policy, ownership, and review.

Runtime policy enforcement is the only point where model action becomes acceptable enterprise action. Static permissions lists cannot keep up when the model is selecting tools dynamically and the value of the action depends on current role, risk, and context. The article’s emphasis on real-time checks aligns with modern NHI governance, where entitlement alone is not enough. The practitioner conclusion is simple: access control has to evaluate the request at execution time.

Missing auditability creates an identity evidence gap that weakens both incident response and accountability. If tool calls are not linked to a verified user, a role, and a response record, the organization cannot prove who initiated a downstream effect. That is a governance failure, not a logging preference. For identity teams, the practical takeaway is that MCP logging must preserve who, what, when, and under which policy state the call occurred.

MCP is pushing LLMs into the same identity model that already governs NHIs, but with higher speed and lower tolerance for ambiguity. The named concept here is identity context debt: every tool call that lacks a verified subject adds unresolved governance risk to the environment. That debt accumulates when approvals, entitlement checks, and audit linkage are bolted on after the fact. Practitioners should treat it as a structural design flaw, not an operational inconvenience.

From our research:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, inappropriately sharing sensitive data, and revealing access credentials, according to AI Agents: The New Attack Surface report.
• In the same research, 92% of respondents agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so.
• That governance gap is why readers should also review OWASP Agentic AI Top 10 for the control patterns that map to tool misuse and scope drift.

What this signals

Identity context debt: every MCP tool call that cannot be tied to a verified subject creates unresolved governance work for the programme. That debt shows up later as broken approvals, incomplete audits, and policy decisions that cannot be reconstructed after an incident.

With 48% of organisations still blind to what their AI agents access, per the AI Agents: The New Attack Surface report, the operational lesson for IAM teams is clear. MCP governance will fail if model actions are treated as separate from identity evidence.

The next phase of control design is not more model tuning. It is tighter integration between identity orchestration, policy enforcement, and auditable tool invocation so that delegated actions remain accountable across the full request chain.

For practitioners

• Bind every tool request to a verified identity Require role, entitlement, and risk evaluation before any MCP tool invocation is allowed to proceed. If the request cannot be attributed to a real subject, stop the call rather than infer context later.
• Treat MCP registries as governed access surfaces Limit tool discovery to curated registries, review definitions for provenance, and revoke tools that are not tied to policy. This is especially important for environments where external registries can introduce malicious or misleading tool definitions.
• Log the full identity chain for every action Capture the initiating user, the model request, the tool selected, the policy decision, and the response. Link those records so incident response can reconstruct who initiated the action and under which approval state it ran.
• Add approval gates for high-consequence actions Require human approval for actions that alter permissions, move money, expose sensitive data, or change production systems. Tie the gate to contextual risk so it fires only when the action exceeds the acceptable threshold.

Key takeaways

• MCP expands LLM capability, but without identity context it also expands the attack surface around tool invocation and delegated access.
• The most common failure mode is not the model itself, but the missing binding between user identity, policy state, and the downstream tool call.
• Practitioners should treat registries, endpoints, approval gates, and audit trails as one governed identity path rather than separate technical layers.

Key terms

• Model Context Protocol: A standard that lets an LLM discover and invoke external tools in a structured way. In security terms, it is an access path, not just an interface, because every tool call can carry real-world side effects that require identity, policy, and audit controls.
• Identity context: The verified identity, role, entitlement, and risk information that should accompany a request before any action is allowed. For MCP and other delegated workflows, identity context is what turns model output into governable access rather than anonymous execution.
• Runtime policy enforcement: An access-control pattern that evaluates a request at the moment it is executed, using current identity and context rather than static configuration alone. For model-driven systems, runtime enforcement is what stops the model from acting outside approved boundaries.
• Trusted registry: A controlled source of tool definitions that has been reviewed, curated, and tied to policy before a model is allowed to use it. In MCP environments, registry trust matters because the discovery path can be attacked before the execution path ever begins.

Deepen your knowledge

MCP security and identity context are covered in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building governance for model-driven tool access, it is a strong place to start.

This post draws on content published by Strata Identity: MCP security and identity context for LLM tool access. Read the original.