By NHI Mgmt Group Editorial TeamBased on Lasso Security: “MCP: Enabling Controlled & Composable AI Systems” (May 14, 2026)

TL;DR: MCP standardises how LLMs discover tools and trigger actions, but Lasso Security notes that concentrated capability access, weak scoping, and limited visibility can turn one misconfiguration into broad misuse or exfiltration. That makes protocol-level governance, auditability, and least-privilege boundaries decisive for enterprise AI programmes.

At a glance

What this is: This is an analysis of MCP as the protocol layer for AI tool orchestration, with the key finding that centralising tool access can also centralise failure if scopes, logs, and server trust are weak.

Why it matters: It matters because IAM, PAM, and NHI governance teams need to treat MCP as an access-control boundary, not just an integration standard, when agents can trigger real actions across enterprise systems.

Context

Model Context Protocol, or MCP, is an open standard for connecting LLMs to tools and data sources in a structured way. In identity terms, the question is not whether the protocol works, but where governance must sit when an AI system can discover capabilities and trigger operations across many services.

This article argues that standardised tool orchestration reduces integration chaos while also concentrating access-control risk, audit burden, and blast radius. For NHI and AI agent programmes, MCP turns tool exposure, capability scoping, and telemetry into first-order governance issues rather than implementation details.

The practical shift is that teams can no longer evaluate each integration as a one-off wrapper. They need to treat the protocol, the orchestrator, and each exposed capability as part of a single identity control plane.

Key questions

Q: What breaks when MCP integrations are not governed tightly?

A: Tool trust breaks first, then command integrity, then secret exposure. If an assistant can register or trust the wrong MCP server, the environment may execute commands or disclose data in ways the developer never intended. That makes MCP onboarding part of access governance, not a simple configuration step.

Q: Why does MCP increase the impact of a compromised server?

A: MCP increases the impact of a compromised server because the server can sit inside a shared orchestration path and return data or actions that look legitimate to the agent. If the orchestrator and registry trust that server too broadly, one foothold can influence multiple downstream systems.

Q: What are the signs that MCP governance is failing?

A: Common signs include agents reaching systems outside their intended workflow, incomplete audit trails for tool use, and data retrieval that cannot be tied back to a clear business purpose. If teams cannot reconstruct who invoked which tool, against which resource, and why, the MCP layer is already operating with insufficient control.

Q: How should teams govern MCP at scale without overexposing tools?

A: Teams should govern MCP as a capability-based control plane, with explicit approval for server provenance, granular scoping for each tool, and monitoring that covers every request and response. The goal is to keep discoverability useful while preventing shared interfaces from becoming shared privilege.

Technical breakdown

How MCP changes the tool-calling trust boundary

MCP replaces bespoke integrations with a structured protocol for tool discovery, context retrieval, and action execution. That standardisation reduces ad hoc glue code, but it also moves trust into the protocol boundary itself. Once tools are exposed as discoverable capabilities, the security question becomes which actor may invoke which capability, under what schema, and with what downstream effect. The risk is not simply API access, but a shared orchestration layer that can carry broad privilege if scope definition is loose.

Practical implication: define MCP capability boundaries as access-control objects, not just integration endpoints.

Why mis-scoped capabilities become broad misuse paths

An MCP server can expose functions with typed inputs and outputs, but typed schema does not equal safe authority. If default permissions are broad, an agent can be authorised to do more than its task really requires, especially when multi-step workflows chain several tools together. That creates a practical overprivilege problem: one poorly scoped capability can be invoked repeatedly, combined with other tools, or coerced by prompt injection into actions the developer did not intend.

Practical implication: review each MCP capability for minimum authority, not just valid syntax.

Visibility and server trust are the weak points of scale

MCP makes traffic predictable, but the article notes that many deployments still lack consistent logging of who called what, with which parameters, and why. That matters because compromised or malicious servers can embed or relay data across tool responses, creating an exfiltration path that looks like normal protocol behaviour. In practice, the orchestrator and registry become high-value trust anchors: if either is too permissive, the protocol can multiply one compromise across many connected systems.

Practical implication: instrument MCP traffic end to end and validate server authenticity before granting production access.

Threat narrative

Attacker objective: The objective is to turn one weakly governed MCP trust point into broad operational misuse, data exposure, or multi-system compromise.

  1. Entry occurs when an attacker abuses prompt injection, a misconfigured capability, or a malicious third-party MCP server to gain influence over an agent’s tool path. Credential access is not the only issue, because the protocol can expose authority through schema trust and server registration.
  2. Escalation happens when a high-permission tool or orchestrator is coerced into actions beyond the intended workflow, or when a compromised server relays sensitive data from other connected systems.
  3. Impact follows when the attacker uses the unified MCP layer to exfiltrate data, trigger unsafe operations, or cascade compromise across multiple tools from a single foothold.

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 is becoming the identity boundary for enterprise AI tool use: The main governance shift is that capability discovery, authorisation, and audit now happen at the protocol layer, not inside each downstream app. That collapses the old assumption that integrations are merely transport. Practitioners should treat MCP as a control plane for non-human access, with all the lifecycle and oversight that implies.

Protocol standardisation does not remove overprivilege, it concentrates it: When dozens of tools share one access pattern, weak scoping affects the whole estate instead of one connector. That makes the blast radius of a single misconfiguration much larger than in bespoke API integrations. The practical conclusion is that least privilege must be enforced at capability granularity, not at application granularity.

MCP turns visibility into an identity control, not just a logging problem: If teams cannot answer which agent invoked which tool, with what parameters, they cannot govern misuse or prove containment. This is especially important when third-party MCP servers and registry entries can introduce hidden data flows. Auditability becomes a prerequisite for trust, not a forensic luxury.

Third-party MCP ecosystems create a new form of NHI supply-chain exposure: The article’s risk profile is not just insecure configuration but insecure provenance of the server itself. A malicious or poorly reviewed server can weaken authentication, broaden access, or create covert exfiltration paths. Practitioners should read this as a governance problem across discovery, approval, and revocation of non-human access.

Capability-based orchestration needs an identity model that assumes compromise is local but impact is global: MCP’s strength is shared structure, but shared structure also means one compromised server or orchestrator can affect many workflows. That changes how teams think about segmentation, monitoring, and exception handling. The programme implication is to govern MCP as a high-trust interoperability layer with explicit blast-radius limits.

From our research library:

What this signals

Capability sprawl becomes identity sprawl when MCP is allowed to define trust: The main programme risk is not that agents are clever, but that a standard protocol can make broad tool access feel normal. Teams should expect the governance conversation to move from individual integrations to shared control of capabilities, servers, and orchestrators.

The next maturity step is to treat MCP as part of the identity fabric for AI systems. That means separating discovery from authorisation, limiting how much any one server can influence downstream systems, and tying every call to a traceable actor and purpose.

For practitioners

  • Define capability-level access boundaries Map each MCP tool to the minimum authority required, then separate read-only, write, and multi-step actions so one capability cannot silently expand into another.
  • Instrument orchestrator and server telemetry Log agent identity, tool name, parameters, response class, and approval context for every MCP call so investigations can reconstruct who did what and when.
  • Approve third-party MCP servers like software supply chain artifacts Review provenance, authentication behaviour, and exposed capabilities before introducing any community or vendor server into production workflows.
  • Constrain high-risk tools behind explicit policy gates Require extra validation for actions that move data, send messages, or change records so prompt injection cannot directly translate into business impact.
  • Test for cross-tool exfiltration paths Simulate a compromised server returning unexpected payloads from other systems to confirm that the orchestrator blocks lateral data leakage.

Key takeaways

  • MCP can improve AI integration consistency while also concentrating access risk in one protocol layer if scopes and server trust are weak.
  • The article highlights that poor visibility and overly broad capability design make it hard to detect misuse or contain compromise across connected tools.
  • Security teams should govern MCP like a control plane, with capability-level least privilege, strong provenance checks, and full request tracing.

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.
  • Capability-Based Authorization: Capability-based authorization grants narrowly defined verbs on specific resources instead of broad role membership. For AI agents, that means the token should allow only the exact task steps required, because probabilistic behaviour can turn coarse permission into chained misuse.
  • Orchestrator: The control plane that routes messages, stores workflow state, and manages tool access across multiple AI agents. Because it concentrates delegation and logging in one place, it becomes the highest-value identity surface in the system and needs privileged-service treatment, not ordinary application handling.
  • Public MCP Server: A public MCP server is a Model Context Protocol endpoint exposed for external AI agents or applications to discover and use tools, data, or actions. It publishes a standardized interface for model-to-system interaction, so access control, authentication, logging, and input validation become critical security requirements.

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.
NHIMG Editorial Note
Published by the NHIMG editorial team on June 9, 2026.
Updated on October 10, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org