MCP concentrates risk in AI tool orchestration and access control

At a glance

What this is: MCP is an open standard for structured LLM-to-tool connectivity, and the key finding is that it improves consistency while concentrating risk in tool permissions, orchestration, and monitoring.

Why it matters: For IAM practitioners, MCP matters because it turns AI tool access into an identity and governance problem spanning NHI controls, agent behaviour, and audit visibility.

By the numbers:

• Only 18% of MCP server deployments implement any form of access scoping for tool permissions.
• 53% of MCP servers expose credentials through hard-coded values in configuration files.

👉 Read Lasso Security's analysis of MCP security risks and tool governance

Context

MCP, or Model Context Protocol, is the interface layer that lets AI systems discover tools, retrieve context, and trigger operations in a structured way. The governance problem is not connectivity itself, but that tool access becomes easier to scale faster than the identity controls around it. In practice, that shifts AI integrations into the same NHI risk domain as service accounts, API keys, and other machine identities.

For enterprise IAM and security teams, the issue is whether tool use is being constrained, logged, and reviewed as an identity event rather than treated as application plumbing. When the protocol standardises how agents call capabilities, weak scoping or poor telemetry can spread across many workflows at once. That makes MCP a governance layer concern, not just an engineering convenience.

The practical question is no longer whether AI systems can call tools, but whether every capability exposed to a model is tightly bounded, auditable, and resistant to misuse. That is why MCP sits at the intersection of NHI governance, zero trust, and agentic access control. The article’s starting position is typical of early protocol adoption: standardisation arrives before mature control design.

Key questions

Q: What breaks when MCP tools are not tightly scoped?

A: When MCP capabilities are too broad, a model can convert a normal tool call into unsafe operational behaviour, especially if prompt injection or a compromised server is involved. The main failure is not just data exposure. It is delegated authority without enough boundary control, which lets one action cascade into multiple systems.

Q: Why do MCP environments increase identity governance complexity for AI agents?

A: MCP turns model-tool interaction into a repeatable identity event, which means access, logging, and approvals must work at the capability level rather than at the application level. That complicates governance because the same tool may be reused across many workflows, making privilege review and audit trails harder to standardise.

Q: How do security teams know if MCP governance is actually working?

A: They should be able to answer who invoked which capability, with what parameters, and under what policy. If that evidence is missing, governance is mostly theoretical. A working MCP control plane produces usable logs, narrow permissions, and clear separation between discoverable tools and permitted actions.

Q: Who is accountable when an MCP-connected agent misuses a tool?

A: Accountability sits with the organisation that defined the tool exposure, the policy layer, and the oversight model, because MCP does not remove the need for governance. If a server, orchestrator, or registry is trusted without review, that trust decision becomes the control failure, not just the model’s behaviour.

Technical breakdown

MCP tool discovery and structured capability calls

MCP replaces one-off integrations with a protocol where tools advertise schemas, inputs, outputs, and context in a machine-readable form. The model does not call raw APIs directly in the intended pattern. Instead, it works through a protocol layer that makes actions more deterministic, but also creates a new trust boundary: if the capability description is too broad or incomplete, the model can still invoke unsafe operations within an apparently valid schema.

Practical implication: scope every exposed capability to the narrowest valid action set and review schemas as security controls, not just interface definitions.

Why MCP centralises governance and blast radius

Because MCP standardises tool access, it also centralises policy enforcement, telemetry, and failure modes. That is useful for consistency, but it means one weak orchestrator, one overly permissive server, or one compromised registry entry can affect many downstream systems. The blast radius is larger than in bespoke API integrations because the protocol encourages reuse across multiple agents and workflows, which is exactly where control failures propagate fastest.

Practical implication: treat the host orchestrator and MCP registry as high-value identity infrastructure and apply stricter review than to ordinary application integrations.

Prompt injection, server trust, and delegated tool misuse

MCP risks are often expressed as prompt injection, but the deeper issue is delegated authority. If an agent can call a high-permission tool, manipulated instructions can become real operational actions. A compromised or malicious server can also return data that blends into normal traffic, while the host may trust agent output too broadly. The protocol therefore shifts security from simple authentication to continuous validation of what the agent is allowed to ask, see, and execute.

Practical implication: monitor tool calls, validate server authenticity, and enforce capability-based access controls with audit logging for every invocation.

Threat narrative

Attacker objective: The attacker aims to turn a trusted AI tool interface into broad delegated access that can expose data, misuse capabilities, or pivot across connected systems.

1. Entry occurs when a malicious prompt, unsafe registry entry, or compromised MCP server enters a trusted tool path and becomes available to an AI workflow.
2. Escalation follows when the model is given a high-permission capability or overly broad scope, allowing delegated tool misuse, credential exposure, or cross-tool data access.
3. Impact appears when the orchestrator or connected server propagates the misuse across multiple systems, creating exfiltration, workflow manipulation, or enterprise-wide privilege abuse.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• 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 is not just an integration pattern, it is an identity boundary. The moment a model can discover tools and trigger actions through a standard interface, the question changes from application connectivity to delegated authority. That makes tool scoping, auditability, and policy enforcement part of the identity stack, not optional platform extras. Practitioners should treat MCP servers like privileged non-human identities with explicit lifecycle and access governance.

Standardisation reduces integration sprawl, but it also standardises failure. One consistent protocol makes it easier to scale controls, yet it also means a single weak policy can repeat across every connected workflow. That is why MCP changes the governance conversation from isolated app risk to shared capability risk. The practitioner conclusion is straightforward: uniform interfaces require uniform control rigor.

Capability-based access control is the right mental model for MCP, but only if the capabilities are truly narrow. A typed schema is not a security boundary by itself. If the schema hides broad or multi-step authority, the model can still be manipulated into actions that developers never intended. Teams need to think in terms of exposed authority, not exposed endpoints.

Cross-tool trust breaks down when the orchestrator becomes a single point of privilege. The host that brokers all model-to-tool traffic inherits the highest practical privilege in the chain. If that layer trusts model output too broadly, every connected system inherits the same exposure. Practitioners should read this as an orchestration governance problem, not a point product problem.

Prompt injection against MCP tools is really a delegated action problem. The attack succeeds because the model can translate untrusted language into operational behaviour inside a trusted interface. That means the real governance gap is not the prompt itself, but the assumption that the model’s interpretation can be safely converted into action without stronger containment. The implication for teams is that request provenance and action approval cannot be separated.

From our research:

• Only 18% of MCP server deployments implement any form of access scoping for tool permissions, according to The State of MCP Server Security 2025.
• 53% of MCP servers expose credentials through hard-coded values in configuration files, which shows how quickly protocol adoption becomes a secrets governance problem.
• For a broader agentic view, read OWASP Agentic Applications Top 10 for the controls teams should align before scaling MCP-based workflows.

What this signals

Capability sprawl is the real MCP risk. As AI systems move from single-purpose assistants to reusable tool brokers, the control challenge becomes less about whether a model can act and more about how much authority each callable capability carries. Teams that already map service-account privileges will recognise the pattern, but MCP makes the exposure more dynamic and harder to audit.

With only 18% of MCP server deployments implementing access scoping for tool permissions, per The State of MCP Server Security 2025, most environments are still scaling the interface before the governance model. That means platform teams should expect a late-arriving control backlog around approval flows, logs, and server trust.

Policy at the protocol layer is becoming the differentiator. The organisations that can prove capability-level enforcement, tamper-resistant telemetry, and server authenticity checks will be better positioned to absorb AI growth without multiplying operational risk. For everyone else, MCP will function as a fast path to hidden privilege and undocumented delegation.

For practitioners

• Inventory every MCP capability as a privilege-bearing control surface Map each exposed tool, schema, and parameter set to the smallest business action it can perform. Remove any default or inherited permissions that are broader than the workflow requires.
• Enforce capability-based access controls at the protocol layer Bind tool invocation to context, role, and workflow state so the model cannot call a function simply because it is discoverable. Review each high-risk operation for separate approval and tighter scoping.
• Treat the orchestrator and registry as privileged identity infrastructure Apply stronger authentication, change control, and isolation to the host broker and any package source used to onboard MCP servers. A compromise there can cascade across every connected tool.
• Log every agent-to-tool action with decision context Capture which agent invoked which tool, what parameters were passed, and what response was returned. Without that record, incident investigation and policy enforcement both degrade quickly.
• Validate server authenticity before allowing production trust Require signing, provenance checks, and behavioural review for MCP servers before they are enabled. Community packages and copied templates should be assumed untrusted until verified.

Key takeaways

• MCP turns AI integration into a governance problem because tool discovery and action execution now sit inside a shared protocol boundary.
• The strongest evidence in the market is not theoretical risk but weak access scoping, exposed credentials, and unmonitored tool traffic.
• Practitioners should focus on capability-level control, orchestrator trust, and auditability before expanding MCP into production-scale agent workflows.

Key terms

• Model Context Protocol: An open standard that lets AI systems discover tools and call them through structured interfaces. In practice, it moves tool use from bespoke integrations to a shared protocol, which improves consistency but also concentrates identity, access, and monitoring risk around a common control surface.
• Capability-based access control: A control model that grants an identity permission to invoke a specific function rather than broad access to an entire system. For MCP, the capability must be narrow enough that a model cannot turn a discoverable tool into unintended operational authority.
• MCP orchestrator: The host layer that brokers communication between the model and downstream MCP servers. It is more than plumbing because it often holds the highest practical privilege in the chain, making its isolation, policy enforcement, and logging central to overall security.
• Prompt injection: A technique that inserts malicious instructions into content the model will read and act on. In MCP environments, the danger is not just altered output, but untrusted language being converted into real tool actions when permissions and validation are too broad.

Deepen your knowledge

MCP governance and capability-based access control are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are standardising agent-to-tool access in a similar environment, it is worth exploring.

This post draws on content published by Lasso Security: MCP: Enabling Controlled & Composable AI Systems. Read the original.