MCP tool invocation is becoming the new enterprise perimeter

At a glance

What this is: This is an analysis of why MCP tool invocation is becoming the security perimeter for enterprise AI systems, with the key finding that authorization now matters more than simple connectivity.

Why it matters: It matters because IAM, PAM, and NHI teams need controls that decide whether an agent, user, or local MCP server can execute a specific action in a specific context.

Context

MCP is a standard for connecting AI systems to tools and data sources, but connection alone does not answer who may trigger a privileged action. That gap matters for enterprise identity governance because the control boundary moves from access to the tool itself to the moment an action is invoked.

In practice, the article focuses on how MCP can expand the AI attack surface when authorization is missing or too broad. It also shows why local or unofficial MCP servers create shadow risk that traditional inventory and monitoring often miss.

The underlying governance problem is not whether an agent can connect, but whether the enterprise can constrain what that connection is allowed to do. That is a familiar identity problem, but MCP makes it immediate and runtime-driven.

Key questions

Q: What breaks when MCP tools are connected without runtime authorisation?

A: The control boundary breaks at the point of action. An MCP server can expose broad access, but without invocation-time checks the system cannot distinguish intended use from coerced use. That leaves the enterprise vulnerable to destructive tool calls, data exposure, and confused deputy behavior.

Q: Why do MCP servers increase risk when tool permissions are too broad?

A: MCP servers can expand risk because they sit between an AI client and sensitive backends, often with enough reach to query data, trigger workflows, or modify records. If permissions are broad, a compromised or misbehaving agent can move from one tool to another with little friction. Least privilege and scoped discovery reduce that blast radius.

Q: How do security teams detect shadow MCP access in practice?

A: They correlate client configuration, registry data, and network telemetry to identify servers that were installed outside approved workflows. The key signal is a valid connection that exists without an approval record, owner, or business justification. If the server is reachable but not governed, it should be treated as exposed delegated access.

Q: What should identity teams do about MCP governance and non-human identities?

A: Treat MCP servers and connected agents as governed non-human identities with ownership, approval scope, and offboarding requirements. That means they need inventory, policy review, and access reduction just like any other privileged machine-access pathway.

Technical breakdown

Why tool invocation changes the control boundary

MCP standardizes how an LLM or agent calls external tools, but it does not inherently govern whether a call is appropriate. That creates a separation between transport and authorization: the protocol can route the request while a policy layer must decide whether the specific action is allowed. In identity terms, this is closer to externalized authorization than to authentication. The important shift is that the decision has to happen at invocation time, not just at onboarding or connection setup. For enterprises, that means the security model must understand user, agent, tool, and context together.

Practical implication: treat MCP as a runtime authorization problem, not just an integration pattern.

How the confused deputy problem appears in MCP servers

A confused deputy occurs when a more privileged component is tricked into using its authority on behalf of a less privileged requester. In MCP, the server may hold broad read-write access while the agent or prompting user supplies the request that drives action. If the server does not evaluate intent and context, the tool can become a proxy for deletion, data exposure, or other misuse. This is especially risky when the server has blanket permissions that exceed the caller’s legitimate scope. The protocol is not the flaw; the missing decision point is.

Practical implication: constrain each tool call to the exact action, object, and context the request requires.

Shadow MCP turns local convenience into invisible privilege

Shadow MCP refers to unofficial or locally deployed MCP servers that developers spin up on laptops or workstations. These instances may run with full system privileges and direct filesystem access, which makes them high-value but poorly governed non-human identities. Because they are not centrally inventoried, security teams may have no reliable view of where they exist, what they can access, or who can trigger them. That is an NHI governance issue, not merely a tooling issue, because unmanaged service-style access can bypass normal oversight and recertification paths.

Practical implication: discover and inventory local MCP servers before they become unmanaged production pathways.

Threat narrative

Attacker objective: The objective is to turn a privileged tool bridge into a channel for unauthorized data access, destructive actions, or uncontrolled agent-driven misuse.

1. Entry begins when an agent or user connects to an MCP server that exposes tools with broad permissions and insufficient context checks.
2. Escalation occurs when the requester coerces the server into using its authority for actions the original user did not intend, including file deletion or data exfiltration.
3. Impact follows when shadow MCP instances or over-permissioned tools give the caller invisible access to local systems, repositories, or enterprise data.

Breaches seen in the wild

• Moltbook AI agent keys breach: Moltbook breach exposed 1.5M AI agent keys.
• DeepSeek database exposure 2025: An unauthenticated DeepSeek ClickHouse database exposed over a million log lines with plaintext chat history and API keys in 2025.

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

Tool invocation is now the governing boundary for MCP security: the protocol solved connectivity, but it did not solve authority. Once an agent can reach a tool, the enterprise still has to decide whether that specific action is allowed in that specific context. That makes invocation-time policy the real control plane for agent access.

Confused deputy risk is the native failure mode of broad MCP permissions: a privileged server can be induced to act beyond the requester’s intent if context is not evaluated at the point of use. This is not a new attack class, but MCP makes it easier to industrialise. The implication is that authority must be clipped to the smallest actionable scope.

Shadow MCP is a governance problem before it is a technical problem: local servers with filesystem or system-level access behave like unmanaged non-human identities. They evade normal inventory, recertification, and offboarding discipline because teams do not consistently know they exist. That weakens the identity programme at the discovery layer, not just the enforcement layer.

MCP governance is converging with zero standing privilege for non-human actions: permanent tool access does not align with agentic workflows that only need access for a single task. The market is moving toward per-invocation policy, short-lived trust, and continuous monitoring because standing access no longer matches runtime behavior. Practitioners should expect their access model to move closer to task-scoped control than to app-level entitlement.

Named concept: tool invocation perimeter: the decisive control boundary shifts from connection establishment to the moment a tool call is authorized. That reframes the identity problem around action authorization, not just session establishment or API reachability. Security programmes that still treat MCP as a connectivity layer will miss the real governance choke point.

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: AI Agent Authorisation Guide

What this signals

Tool invocation perimeter: enterprises should stop thinking about MCP as simple connectivity and start treating each tool call as an authorization event. That shift matters because agentic systems can reach business data without ever looking like traditional interactive users, which makes invocation-time policy the only reliable choke point.

Shadow MCP is the operational blind spot in many AI programmes. Local servers with broad filesystem or system privileges create unmanaged access paths that sit outside normal inventory, so discovery and offboarding need to extend to developer endpoints as well as central infrastructure.

Access reviews alone will not solve agentic tool access if the privilege exists only for milliseconds at invocation time. Security teams need governance models that evaluate who may trigger the action, not just which account owns the connector.

For practitioners

• Define per-invocation authorization for MCP tools Require each tool call to evaluate user, agent, target action, and context before execution. Replace blanket read-write access with narrowly scoped decision logic for each invocation.
• Inventory shadow MCP servers across endpoints Discover local and unofficial MCP instances on developer machines, then map what data sources, files, and system privileges each server can reach.
• Reduce blanket permissions on MCP servers Remove repository-wide or filesystem-wide authority where the server only needs task-specific access. Align tool permissions to the minimum action set the workflow truly requires.
• Monitor abnormal tool-call patterns in real time Alert when an agent that usually performs low-volume reads starts issuing large-scale access requests or destructive actions. Use those anomalies to trigger session termination or review.
• Tie MCP governance to identity lifecycle controls Treat MCP servers and agent connectors as governed non-human identities with ownership, review, and offboarding requirements instead of one-off developer utilities.

Key takeaways

• MCP changes the enterprise problem from connecting AI systems to governing what those systems may do once connected.
• Broad tool permissions and missing invocation checks create the confused deputy conditions that make agent-driven misuse possible.
• Shadow MCP deployments extend NHI risk onto developer endpoints, so discovery and lifecycle control have to move beyond central infrastructure.

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.
• Confused Deputy: A confused deputy is a privileged system that is tricked into performing an action on behalf of an untrusted requester. In agentic AI, the agent may misread malicious input as legitimate intent and then use its own authority to act, which turns a logic problem into a security incident.
• Shadow MCP: Shadow MCP is an unauthorized or ungoverned use of the Model Context Protocol inside an organization. It appears when AI agents, scripts, or tools connect to data or actions through MCP servers without security review, inventory, policy control, or monitoring. This creates hidden access paths, data exposure, and weak accountability.
• Runtime Authorisation: Runtime authorisation is the practice of deciding access while a task is in progress, rather than only at provisioning time. It matters for NHIs because credentials and entitlements can change risk mid-session, especially when automation or AI agents interact with sensitive systems.

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