MCP tool invocation is becoming the new enterprise perimeter

At a glance

What this is: This is an analysis of why Model Context Protocol adoption creates a new authorization problem for AI tool use, especially around confused deputy behavior and shadow MCP deployments.

Why it matters: It matters because IAM, PAM, and NHI teams now have to govern tool invocation and runtime authorization, not just credentials and network access, across human-led and agentic workflows.

👉 Read Reva.AI's analysis of MCP tool invocation and runtime authorization

Context

Model Context Protocol is a standard for connecting AI models to external tools, local files, and enterprise data sources. The governance gap appears when that connection is made before the enterprise has defined who may execute a specific action through the connected tool.

For identity teams, the issue is not MCP connectivity itself. It is the shift from static access to runtime authorization, where a connected agent can become a privileged actor unless tool invocation is constrained by policy, context, and explicit approval boundaries.

Key questions

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

A: Security teams should govern MCP tool calls at the moment of execution, not just at connection time. That means binding each request to the user, agent, tool, and context, then enforcing policy before the tool runs. If a connector can read or write sensitive data, treat it as a privileged control point and require runtime authorization.

Q: Why do MCP deployments create confused deputy risk for identity teams?

A: MCP deployments create confused deputy risk because a privileged server can be tricked into doing something the original user never intended. The server has authority, but the triggering request may not deserve it. Identity teams should assume that broad tool permissions can be misused unless every invocation is checked against explicit context and intent.

Q: What do security teams get wrong about shadow MCP servers?

A: They often treat them as developer convenience rather than identity-bearing infrastructure. In reality, local MCP servers can have full filesystem and system privileges while escaping central visibility. That makes them an unmanaged perimeter, so discovery, owner assignment, and policy enforcement have to extend to endpoints as well as platforms.

Q: Who is accountable when an AI agent uses an MCP tool to expose data?

A: Accountability usually sits with the organisation that allowed the tool path, the server privilege, and the agent behaviour to intersect without adequate controls. In practice, the governance failure is shared across identity, platform, and application teams. The right response is a clear approval model for high-risk tool invocation and auditable ownership for each server.

Technical breakdown

Confused deputy risk in MCP tool invocation

The confused deputy problem appears when a privileged MCP server or tool is instructed by an agent to perform an action that the original user did not intend. In practice, the server has more authority than the immediate request deserves, so the tool becomes the enforcement point rather than the model. If the tool exposes broad read/write permissions, a coerced call can turn a simple integration into a data-exfiltration or destructive-action path. This is a governance problem because authorization sits too far downstream from intent.

Practical implication: bind each tool call to explicit user, agent, and context checks before execution.

Shadow MCP expands the unmonitored identity perimeter

Shadow MCP refers to local or unofficial MCP servers that developers run to speed up work. These instances often inherit full system privileges and direct filesystem access, which means the effective identity boundary extends beyond centrally managed infrastructure. Traditional monitoring struggles here because the server may be on a laptop or in an unsanctioned environment, yet still capable of acting on enterprise data. The security issue is not only unauthorized access, but invisible authority.

Practical implication: inventory and classify every MCP server as an identity-bearing endpoint, including local instances.

Intent-aware authorization changes tool security from static to runtime

Static tokens and broad permissions are poorly matched to agentic workflows, because the same agent may request different actions in different contexts. Intent-aware authorization evaluates the request at the moment of invocation, using the user, agent, tool, and context together. That shifts control from pre-granted capability to decision-time enforcement, which is the point where misuse can still be blocked. In MCP environments, this is the difference between giving a model access and giving it permission.

Practical implication: move policy enforcement to the tool-calling layer and recheck authorization on every high-risk invocation.

Threat narrative

Attacker objective: The attacker wants to use trusted tool connectivity to make a privileged system perform actions or disclose data that the user did not authorize.

1. Entry occurs when an agent is connected to an MCP server that exposes tools, files, or data sources with broad permissions.
2. Escalation follows when the agent is coerced into invoking a tool outside the original user's intent, turning the server into a confused deputy.
3. Impact is data exposure, destructive action, or unauthorized system use through the tool invocation path.

Breaches seen in the wild

• ASP.NET machine keys RCE attack — 3,000+ exposed ASP.NET machine keys enabled remote code execution.
• DeepSeek breach — DeepSeek breach exposed 1M+ log lines and sensitive secret keys.

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 tool invocation is now an identity control point, not a transport detail. The security question is no longer whether a model can connect to data, but whether each discrete action is authorized at the moment it is invoked. That changes MCP from a plumbing standard into an access-governance problem that belongs with IAM, PAM, and NHI oversight. Practitioners should treat every tool call as an entitlement decision, not a mere API request.

Confused deputy risk is the clearest failure mode in MCP adoption. The MCP server often holds more authority than the agent or user that triggered the call, so the security boundary is misplaced if authorization happens only after connection. This is not a theoretical weakness, it is the structural result of delegating action to a privileged intermediary. The lesson for practitioners is that tool privilege and user intent must be coupled before execution.

Shadow MCP creates an unmanaged identity perimeter that existing discovery tools will miss. Local servers on developer machines can carry full filesystem and system privileges while remaining invisible to central governance. That is a classic NHI expansion pattern, but with a new wrapper: the tool server itself becomes the identity-bearing asset. The practitioner takeaway is that discovery must extend to developer-run infrastructure, not stop at sanctioned platforms.

Intent-aware authorization is the right category, but it also exposes the limits of static least privilege. Least privilege was designed for predictable access patterns and stable execution paths. MCP-driven workflows are more dynamic, and the tool chosen at runtime may differ from the one assumed at provisioning. The implication is that identity governance for AI tool use needs context-sensitive authorization rather than one-time access grants.

Autonomy amplifies the problem because the control point shifts from request approval to runtime containment. Once an agent can select tools and act without a human approval gate for each step, the governance assumption that access can be reviewed after the fact becomes weaker. That does not make MCP inherently unsafe, but it does mean practitioners must rethink where authority sits in the delegation chain. The control model must move closer to execution, not further away from it.

From our research:

• 98% of companies plan to deploy even more AI agents within the next 12 months, despite documented rogue behaviour in 80% of current deployments, according to AI Agents: The New Attack Surface report.
• 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.
• As agent usage expands, practitioners should compare governance patterns with the findings in OWASP Agentic Applications Top 10 and tighten runtime policy before tool access becomes normalised.

What this signals

Shadow MCP: the next governance problem is not only unauthorised models, but unauthorised tool servers that sit outside enterprise inventory. Once developers can stand up local servers with privileged access, the control objective shifts from app registration to endpoint discovery and action governance.

The practical signal for IAM and PAM teams is that static permissions will keep losing relevance as agentic workflows spread. The policy question is no longer whether a credential exists, but whether a specific action can be authorised at the exact moment the tool is invoked.

As more organisations adopt connected agents, the boundary between platform security and identity governance will blur further. Teams that already align to NIST AI Risk Management Framework and OWASP Agentic AI Top 10 will be better placed to define runtime controls before shadow usage becomes routine.

For practitioners

• Map every MCP server to an identity owner Create a complete inventory of sanctioned and unsanctioned MCP servers, including developer-hosted instances, then assign a business and security owner to each one. Treat uncatalogued servers as unmanaged identity infrastructure until they are approved or removed.
• Enforce tool-level authorization before execution Require the authorization decision to happen at the tool invocation layer, with the user, agent, tool name, and context evaluated together. Broad connector access is not sufficient when a single tool can delete files, read sensitive data, or trigger downstream actions.
• Separate discovery from trust Detect connected tools and local MCP instances first, then apply differentiated policy by data sensitivity and action risk. Use the same inventory to flag broad read/write access, system-level permissions, and any server that bypasses central monitoring.
• Add behavioral thresholds for anomalous tool use Set alerts for unusual tool-call volumes, unusual data targets, or sudden changes in action patterns, then use session termination where the behaviour exceeds expected bounds. This is especially important where an agent can chain multiple calls in a single workflow.
• Review delegation chains for hidden authority Trace how a request moves from human to agent to tool server to underlying system, and identify where authority exceeds intent. Remove any standing permissions that allow the chain to continue without a fresh authorization decision.

Key takeaways

• MCP introduces a governance problem at the point of tool invocation, where connection alone is no longer a sufficient security boundary.
• The strongest failure modes are confused deputy behaviour and shadow MCP servers, both of which expand authority faster than identity teams can observe it.
• Practitioners should move policy enforcement into the runtime path, inventory every server that can act on enterprise data, and treat tool calls as privileged decisions.

Key terms

• Model Context Protocol: A standard that lets AI models connect to external tools, files, and data sources through a common interface. In identity terms, MCP does not itself decide who may act, so the enterprise still has to enforce authorization, accountability, and scope at the tool layer.
• Confused Deputy: A failure mode where a privileged system is tricked into using its authority on behalf of someone who should not have it. In MCP environments, the server or tool may have more access than the request deserves, so the control problem is about binding intent to execution.
• Shadow MCP: Unofficial or unsanctioned MCP servers that are created outside central governance, often by developers seeking faster workflows. These instances can still carry system-level privileges and access to local data, which makes them a hidden identity and access perimeter.
• Intent-Aware Authorization: An access decision made at the point of action, using the current user, agent, tool, and context rather than a static permission alone. It is especially relevant for agentic workflows because the same identity may request different actions across a single session.

What's in the full article

Reva.AI's full article covers the operational detail this post intentionally leaves for the source:

• A closer look at the intent-aware authorization flow for MCP tool calls and how it intercepts execution.
• Examples of behavioral monitoring thresholds that can trigger alerts or session termination when tool use changes suddenly.
• A discussion of OAuth 2.1 and AuthZEN integration for externalised authorization in agentic environments.
• The article's view of how a centralized control plane can replace ad hoc developer-run governance around MCP.

👉 Reva.AI's full article covers the confused deputy pattern, shadow MCP discovery, and intent-aware control flow in more detail.

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.