MCP compositional risk is creating silent AI execution paths

At a glance

What this is: This research shows that MCP plugin composition can turn trusted agent integrations into silent execution paths when untrusted inputs meet privileged actions.

Why it matters: IAM, NHI, and AI governance teams need to treat MCPs as governed execution surfaces because agent behaviour can cross privilege boundaries without human review or approval.

By the numbers:

• Pynt reports that 72% of MCPs expose sensitive operations such as writing to disk, executing code, or calling high-permission APIs.
• Pynt found that 13% of MCP plugins accept attacker-controlled inputs from sources such as web scraping, Slack, or email.
• Installing 10 MCP plugins pushes exploitation risk to 92%, according to Pynt’s analysis of compositional risk.
• Pynt reports that with three MCPs in a system, the chance of a silent exploit exceeds 50%.

👉 Read Pynt's full analysis of compositional risk across 281 MCP configurations

Context

MCPs, or Model Context Protocol connectors, sit between AI agents and the tools, APIs, or execution environments they control. The governance problem is that each connector may look safe in isolation, yet the combination of input handling and privileged action can create a path to execution that bypasses normal security review. That is why MCP security now intersects directly with agent identity, authorisation, and NHI governance.

The article is not arguing that all plugins are unsafe. It shows that risk emerges when untrusted content is allowed to flow into privileged actions without approval checkpoints, runtime validation, or isolation. For IAM and PAM teams, that means the control question is no longer just who can call a tool, but what chain of delegated actions an agent can assemble from connected tools.

Key questions

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

A: Security teams should bind MCP tool access to enterprise identities, entitlements, and lifecycle state before a request reaches production tools. A gateway can enforce policy at the edge, but governance only exists when the identity system knows who is calling, what they are allowed to do, and whether approval or offboarding has already occurred.

Q: Why do MCP-based agents create more risk than ordinary API integrations?

A: Because the agent is choosing actions, chaining tools, and preserving context across steps. Ordinary API controls assume predictable request patterns, while MCP can turn one legitimate session into a route for data exposure or privilege escalation. The risk increases when identity, context, and tool access are not governed together.

Q: What breaks when AI agents can call tools after reading untrusted content?

A: The system stops being a text processor and becomes an execution surface. If an agent can ingest poisoned context and then invoke tools with delegated privileges, the attacker can redirect control flow without direct user approval. That is why tool execution needs a separate authorization check from the model’s reasoning step.

Q: How do security teams know whether MCP server governance is working?

A: They should be able to answer four questions at any time: what servers exist, which are official, what credentials they can use, and what systems they contact. If those answers are unclear, governance is not working. The signal is not just fewer alerts, but clear attribution and scoped access across the fleet.

Technical breakdown

Why MCP composition creates hidden execution paths

MCPs act like an execution layer rather than a passive API layer. A plugin that ingests email or Slack content may seem low risk, but if a second plugin can execute code or write to disk, the system can turn untrusted input into action without an explicit human step. The core issue is composition: security review often evaluates each connector separately, while attackers exploit the path between them. Static allowlists do not capture how data shape, parsing, and tool chaining interact at runtime.

Practical implication: review MCPs as chains of delegated behaviour, not as standalone integrations.

Why approval checkpoints and runtime validation matter for agent tools

Approval checkpoints insert a human or policy gate before the agent can trigger a sensitive action, while runtime validation checks whether the current request, payload, or destination matches expected behaviour. In MCP environments, those controls are important because the same tool can be safe for read-only work and dangerous when paired with untrusted content. The article’s examples show how quickly an email or HTML payload can be transformed into shell execution when the system does not re-check context at the moment of action.

Practical implication: require context-sensitive validation before any tool call that can modify state or execute code.

What compositional risk means for AI agent identity and NHI governance

In practice, each agent, plugin, token, and service connection becomes part of an NHI control surface. If an agent can inherit privileges from multiple tools, the organisation may lose track of which identity is performing which action and under what authority. That creates a governance gap between authentication and execution. For identity teams, the important question is not only whether an agent is authenticated, but whether its delegated permissions are bounded, auditable, and revocable across the full tool chain.

Practical implication: map each agent-to-tool trust relationship to a specific identity, privilege scope, and audit trail.

Threat narrative

Attacker objective: The attacker wants to convert routine agent workflows into hidden execution paths that run code, alter systems, or abuse high-privilege APIs without intervention.

1. Entry begins when attacker-controlled content enters an MCP-connected workflow through Slack, email, web scraping, or another ingestion source.
2. Escalation occurs when that untrusted content is parsed by one plugin and then handed to a second plugin with privileged execution rights such as shell access or high-permission API calls.
3. Impact follows when the agent executes code or other sensitive actions silently, without human review, turning the MCP chain into a programmable backdoor.

NHI Mgmt Group analysis

Compositional risk is the new control gap in agentic systems. The article shows that individual MCPs can appear low risk while the chain as a whole becomes exploitable. That means assessment must move from connector-level review to workflow-level authorisation analysis. In identity terms, the trust boundary is no longer the plugin alone but the sequence of delegated actions it can assemble. Practitioners should treat composition itself as a governable security object.

Agent identity must be bounded by action, not just authentication. An authenticated agent that can combine input ingestion with privileged execution is still a governance failure if its effective authority is broader than intended. This is where MCPs intersect with NHI management: tokens, service identities, and tool grants need lifecycle control, auditability, and explicit scoping. Without that, the organisation has validated an identity but not the actions that identity can orchestrate. Practitioners should align identity scope to executable behaviour.

Runtime control is more important than static review for MCP security. The article’s examples show why pre-deployment checks miss the dangerous state transitions that happen only when content, context, and privilege collide at runtime. Static policy cannot see every chained path. That makes approval gates, sandboxing, and context-sensitive validation the decisive controls for reducing exploitability. Practitioners should shift from connector approval to execution-time governance.

Chain-aware validation is the right named concept for this risk. The hidden failure mode is not simply “too many plugins”, but insufficient validation of how one plugin’s output becomes another plugin’s privileged input. This is the same class of governance problem that appears in workflow automation, but MCPs compress the time between input and action. For identity and PAM teams, the conclusion is clear: control the chain, not just the node.

AI governance now depends on tool-authorisation hygiene. As agents become part of daily operations, tool access decisions start to resemble privileged access decisions rather than ordinary application configuration. That shifts ownership toward IAM, PAM, and AI security teams working together on approval, revocation, and audit. Practitioners should expect agent governance to become a core part of broader identity architecture.

What this signals

Chain-aware validation will become a baseline expectation for any organisation putting AI agents into production. The governance task is shifting from approving individual tools to proving that no untrusted input can reach a privileged action without policy enforcement. That is where NHI governance, PAM discipline, and AI oversight start to converge.

The operational signal here is simple: if your programme cannot explain which agent can invoke which tool, under what authority, and with what audit trail, you do not have control of the execution layer. Practitioners should pair runtime isolation with reference controls such as the NIST AI Risk Management Framework and OWASP Agentic AI Top 10.

Execution-plane identity is now the practical problem behind MCP security. As agents accumulate tool access, identity teams will need to govern not just the agent itself but the sequence of delegated permissions that the agent can assemble across workflows.

For practitioners

• Map every MCP chain to a privilege boundary Inventory how untrusted inputs flow into tools that can write files, execute code, or call high-permission APIs. Flag any chain where data ingestion and privileged action sit in the same runtime path. Use that map to decide which connectors need isolation or removal.
• Require approval for sensitive server calls Use the MCP host approval feature, or an equivalent policy gate, before any tool call that can change state or expand access. Keep the gate tied to the exact action, not just the server or plugin name, so the control survives tool composition.
• Restrict active MCP servers to the minimum set Disable every server and tool that is not actively required for the workflow. Fewer enabled connectors reduce the number of compositional paths attackers can assemble, which matters when exploit probability increases rapidly as plugins are added.
• Isolate execution from ingestion workflows Separate content-parsing functions from shells, code interpreters, and other privileged execution environments. Where separation is not possible, use sandboxing and network controls so one compromised input source cannot reach the full execution plane.

Key takeaways

• MCP risk comes from composition, where untrusted input and privileged action meet inside the same agent workflow.
• The evidence shows that silent exploitability rises sharply as more plugins are added, which makes runtime governance more important than static review.
• Identity, PAM, and AI security teams need shared control over tool approval, auditability, and execution boundaries before agent sprawl becomes operationally normal.

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.
• Compositional Risk: The security risk that emerges from combining individually acceptable components into an unsafe end-to-end workflow. In MCP and agentic environments, the danger is often not a broken server but a delegation path that lets untrusted input influence privileged action.
• Approval Checkpoint: An approval checkpoint is a control that forces an action to be reviewed or confirmed before execution. For AI agents and MCP workflows, it is the point where a privileged tool call can be paused, checked against policy, and blocked if the context does not justify the action.
• Execution Layer: The execution layer is the operational point where identity policy becomes system change. It is where approvals, provisioning, revocation, and session controls either complete successfully or fail in ways that create drift. For practitioners, this is where governance is proven, not merely documented.

What's in the full report

Pynt's full research report covers the operational detail this post intentionally leaves for the source:

• A complete dataset behind the 281 MCP configurations and how the sample was analysed
• Exploit chain diagrams showing how untrusted inputs reached privileged actions in live cases
• Platform-specific risk breakdowns for different MCP deployment patterns
• Methodology details on how compositional risk and silent exploitability were measured

👉 Pynt's full report covers the exploit chain diagrams, platform breakdowns, and methodology behind the findings.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps practitioners connect identity controls to the delegated access patterns now emerging in agentic systems.