Multi-agent MCP governance exposes identity and tool sprawl

At a glance

What this is: This comparison evaluates MCP platforms for multi-agent workflows and finds that governance must move down to the runtime layer to preserve identity attribution, tool scoping, trace continuity, and containment.

Why it matters: It matters because IAM, NHI, and platform teams now need controls that follow delegation across agent hops, not just authentication at the first connection.

By the numbers:

• Only 18% of MCP server deployments implement any form of access scoping for tool permissions.
• NHIs outnumber human identities by 25x to 50x in modern enterprises.

👉 Read Stacklok's comparison of MCP platforms for multi-agent workflows

Context

MCP, or Model Context Protocol, becomes a governance problem as soon as one agent delegates to another and both can invoke tools. In that model, the delegating agent, the receiving agent, and the end user are not interchangeable identities, yet many platforms still treat them as if they were.

Multi-agent workflows amplify the same identity controls that already challenge NHI programmes: delegated access, scoped tool surfaces, isolated runtime boundaries, and end-to-end trace continuity. The article argues that the control plane must sit below orchestration, because the orchestration layer coordinates tasks while the MCP runtime governs tool use.

For IAM and NHI teams, the practical question is no longer whether an AI system can call tools. It is whether every tool call remains attributable, least-privileged, and containable when workflows fan out across multiple agents and multiple MCP servers.

Key questions

Q: What breaks when multi-agent MCP workflows share one runtime boundary?

A: Shared runtime boundaries blur identity attribution, expand lateral reach between sibling agents, and make tool access harder to contain. If one agent is compromised or mis-scoped, the entire workflow can inherit that failure because the platform cannot reliably separate identities, tools, and backend access at execution time.

Q: Why do multi-agent workflows make MCP governance harder than single-agent systems?

A: Single-agent systems have one identity boundary and one tool surface. Multi-agent systems add delegation chains, role-specific tool sets, and multiple execution hops, so governance must prove who authorised each call and whether each agent only saw the tools it needed.

Q: How should security teams decide between gateway-level control and container isolation for agents?

A: Use gateway controls for routing and trace enforcement, but choose container isolation when the threat model includes compromised agents, sibling-agent reachability, or backend tool abuse. Gateway-only control is too coarse if each agent must be prevented from touching another agent’s runtime or data surface.

Q: Who is accountable when a delegated agent performs the wrong tool action?

A: Accountability should rest on the decision chain, not only on the session owner. You need to know who approved the delegated action, which policy version applied, what token was bound to the child principal and what side effect occurred. Without those records, accountability becomes speculative instead of provable.

Technical breakdown

Identity propagation across agent hops

In multi-agent MCP workflows, identity must survive delegation. A tool call initiated by one agent may be forwarded through an orchestrator, received by a specialist agent, and finally executed against a backend MCP server. If the runtime only sees an agent service account or generic session token, attribution collapses and investigators lose the ability to answer who requested what, through which chain, and under which scope. Per-request identity with delegation-chain attribution is therefore the core control, because it preserves accountability across the full workflow rather than only at the entry point.

Practical implication: enforce per-request identity and traceable delegation so every tool invocation can be mapped back to the originating workflow context.

Container isolation and tool scoping for multi-agent MCP

Multi-agent systems fail safely only when each agent’s runtime boundary is isolated from sibling agents. Container-level isolation constrains network paths, filesystem access, and tool reachability, while per-agent tool scoping ensures that an orchestrator and a specialist do not see the same tool surface. Co-tenancy at the process level is too weak for this problem because one compromised agent can pivot into another agent’s accessible tools or data surfaces if the boundary is shared. The governance issue is not just permissioning, but blast-radius control at the MCP runtime layer.

Practical implication: place agent workloads in separate runtime boundaries and scope tools by role, not by deployment-wide defaults.

Distributed trace continuity and token cost in agentic workflows

Observability and cost management become part of identity governance once multiple agents operate in sequence. Distributed trace continuity lets security and platform teams correlate a complete delegation chain across agent hops, backend servers, and observability tools. Without that continuity, failed workflows become opaque and abuse patterns are hard to reconstruct. Token optimization matters for the same reason: if each agent receives a full tool catalog at startup, the cost and exposure surface multiply with every additional agent. Runtime tool discovery reduces both the token footprint and the amount of unnecessary context each agent receives.

Practical implication: require OTel-aligned trace propagation and on-demand tool discovery so visibility and efficiency scale with the workflow.

Threat narrative

Attacker objective: The objective is to widen access through delegation ambiguity, reach tools outside the intended scope, and make the resulting activity difficult to attribute or contain.

1. Entry occurs when a delegating agent passes work to another agent that then calls tools through MCP, creating a chain where identity must be preserved across multiple runtime hops.
2. Escalation occurs when shared gateways, coarse tool scopes, or weak isolation allow a compromised agent to reach sibling tools or backend surfaces beyond its delegated task.
3. Impact occurs when investigators cannot reconstruct the full call chain, or when one degraded backend collapses an entire workflow because trace continuity and circuit breaking are absent.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• Meta AI Instagram Account Takeover — 20,225 Instagram accounts hijacked via compromised Meta AI support chatbot with overprivileged access.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Multi-agent MCP governance is an identity problem before it is an orchestration problem. Once one agent delegates to another, the control question shifts from authentication to attribution across a chain of identities. The relevant boundary is no longer the first login or token exchange but the runtime hop where a tool call is actually authorised. Practitioners should treat delegation-chain visibility as a core identity requirement, not an observability nice-to-have.

Identity propagation across agent hops is the named governance gap this category exposes. Multi-agent systems assume the platform can always answer who authorised a tool call, but that assumption weakens as soon as task decomposition is distributed across orchestrators and specialists. If the chain is only partially visible, least privilege becomes difficult to prove and even harder to enforce. The implication is that agent identity must remain traceable through every hop, or the workflow is not governable at scale.

Container isolation per agent workload is the right runtime boundary for multi-agent NHI control. Process-level co-tenancy does not provide enough separation when one agent can be compromised, misconfigured, or over-permissioned. The article’s container-per-server model reflects the broader NHI principle that blast radius must be constrained where execution happens, not after the fact in logs. Practitioners should evaluate whether sibling agents can actually be reached from a compromised runtime.

Token explosion is not just a cost issue, it is a governance signal. When full tool catalogs are injected into every agent context, the platform is moving unnecessary privilege and unnecessary data into each session. That expands exposure, increases debugging complexity, and makes over-collection of tools the default. The practical takeaway is that runtime tool discovery is a governance control as much as an optimisation feature.

Multi-agent MCP platforms are converging on a control pattern that IAM teams already know from NHI governance. The same discipline that applies to service accounts now has to account for delegating agents, per-request traceability, and scoped tool surfaces. The field is moving toward runtime-granular identity controls rather than broad gateway authentication. Practitioners should expect their existing IAM and NHI operating model to be extended downward into the MCP layer.

From our research:

• NHIs outnumber human identities by 25x to 50x in modern enterprises, according to Ultimate Guide to NHIs.
• Only 20% of organisations have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
• 52 NHI Breaches Analysis shows how identity sprawl turns small access gaps into repeatable incident patterns.

What this signals

Delegation-chain governance: multi-agent programmes will need controls that follow identity across agent hops, not just at authentication time. That means trace continuity, scoped tool access, and isolated execution boundaries become baseline requirements for operational trust.

The scale problem is already established in broader identity programmes, where NHIs outnumber human identities by 25x to 50x in modern enterprises, according to Ultimate Guide to NHIs. As agent populations grow, the same governance model that tracks service accounts will need to extend to orchestrators and specialists.

For teams building out multi-agent platforms, the next decision is architectural, not cosmetic. Choose the runtime boundary first, then align observability and tool discovery around that boundary so identity, privilege, and failure analysis stay connected.

For practitioners

• Map delegation chains end to end Track which agent initiates work, which agent receives it, which tool is called, and which backend executes the request. Use that map to identify where identity attribution breaks between orchestrator, specialist, and MCP server.
• Enforce per-agent runtime isolation Run each agent’s MCP server connections in a separate container or equivalent isolated boundary with scoped network and filesystem permissions. Treat shared process space as insufficient for sibling-agent containment.
• Scope tools by role and task Give orchestrators broader discovery only when necessary and restrict specialist agents to the smallest tool set needed for the delegated job. Review the tool surface every time workflow design changes.
• Propagate trace IDs across every hop Require OTel-compatible trace continuity so a single workflow remains visible from initial delegation through each agent and backend server. Without that chain, investigation and compliance evidence will fragment.
• Separate cost optimisation from governance design Use on-demand tool discovery to reduce context bloat, but do not treat token reduction as a substitute for identity scoping or isolation. Cost savings should follow governance, not replace it.

Key takeaways

• Multi-agent MCP introduces a delegation problem that makes identity attribution and tool scoping materially harder than in single-agent deployments.
• The main security control shift is from platform-wide authentication to per-agent runtime isolation, trace continuity, and role-based tool exposure.
• Teams that treat token optimisation as a governance substitute will miss the real issue, which is controlling who can call which tool, from which agent, under which identity.

Key terms

• Delegation With Attribution: Delegation with attribution is the ability to show what a workload did, on whose behalf it acted, and within what scope and time bound. It turns machine action into auditable identity behaviour instead of anonymous service traffic, which is critical for accountability and investigation.
• Per-Agent Tool Scoping: Per-agent tool scoping limits which tools a given agent can discover or invoke. It prevents orchestrators and specialists from sharing the same tool surface and turns least privilege into a runtime control rather than a policy statement.
• Container Isolation Per Agent: Container isolation per agent separates execution boundaries so one agent cannot easily reach another agent’s tools, data, or filesystem. It is a containment control for multi-agent workflows where shared runtimes create unacceptable lateral movement risk.
• Trace Continuity: Trace continuity is the persistence of correlated telemetry across multiple agents, servers, and backend calls. For identity governance, it is what allows a workflow to remain auditable when responsibility moves across delegation hops.

What's in the full article

Stacklok's full blog post covers the operational comparison this post intentionally leaves for the source:

• Detailed platform-by-platform feature comparison for multi-agent MCP governance
• Implementation notes on vMCP, container isolation, and per-agent tool scoping
• Trace and observability specifics for OTel-compatible agent call chains
• Token optimisation mechanics and the 60-85% per-request reduction claim in context

👉 Stacklok's full post covers the platform comparison, runtime controls, and token optimisation details.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security 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.