DEV Community

Cover image for Your Multi-Agent System Has a Governance Blind Spot. Here's Where to Look.
Waxell profile image Logan
Logan for Waxell

Posted on • Originally published at waxell.ai

Your Multi-Agent System Has a Governance Blind Spot. Here's Where to Look.

#ai #agents #governance #multiagent

When your orchestrator delegates a task to a subagent, it passes context, instructions, and — unless you've thought carefully about this — implicitly delegates authority too. That authority is ungoverned in most systems today.

This is the multi-agent governance blind spot. It's not the agents themselves. It's the space between them.

According to Salesforce's 2026 Connectivity Benchmark Report, organizations currently run an average of 12 AI agents — with that number projected to climb 67% within two years. Half of those agents are still operating in isolated silos — disconnected from the multi-agent coordination that would let them work together. The governance tooling and thinking for most teams is still single-agent.

Teams that have invested in per-agent governance — policy rules on individual agents, cost limits per session, PII filtering on outputs — often assume those controls extend through the system when agents start coordinating. They don't. A well-governed orchestrator can spawn a subagent that operates with none of its constraints. The parent agent's policies don't automatically propagate to the child. Context crosses the boundary. Authority crosses the boundary. Governance stops at the edge.

Gartner predicts 40% of enterprise applications will be integrated with task-specific AI agents by the end of 2026, up from less than 5% in 2025. Most of those deployments will involve multiple agents coordinating. Almost none will have solved the coordination layer.

Multi-agent governance is the set of policies, enforcement mechanisms, and tracing infrastructure that control agent behavior across a coordinated system — including at the delegation boundaries where one agent instructs, spawns, or hands off work to another. It differs from single-agent governance in one critical way: the coordination layer itself must be governed. An agent that operates correctly in isolation can violate policy when operating as a subagent receiving instructions from an orchestrator, because the context it receives may exceed its authorization scope, and because most governance systems evaluate agents individually rather than evaluating the full delegation chain. Multi-agent governance treats the handoff as a policy enforcement point, not just the agent.

Why doesn't single-agent governance scale to multi-agent systems?

Single-agent governance works by attaching policies to an agent — or to the session the agent runs in. You define what tools the agent can call, what data it can access, how much it can spend, what it can output. You evaluate those policies at execution time, before each action. For a single-agent system, this is sufficient.

Multi-agent systems break this model in three ways.

Delegation is not instrumented. When Agent A spawns Agent B, the spawning event typically isn't treated as a policy evaluation point. There's no system asking: is Agent A authorized to delegate this scope of work? Is the context it's passing to Agent B within what B should be permitted to receive? Most orchestration frameworks — LangChain's LangGraph, CrewAI, AutoGen — handle delegation as a code-level call. The governance layer, if any exists, was built around the agent's own actions, not around what it's allowed to tell other agents to do.

Context accumulates across the hierarchy. Each agent in a chain can add to the context window that downstream agents receive. By the time a specialized subagent in a four-step workflow acts, its context may contain data that none of its individual policies would have allowed it to access directly — because the data arrived indirectly, assembled by upstream agents. The subagent's PII policy triggers on direct inputs. It doesn't catch PII that arrived assembled in a summary generated by a summarizer agent two steps up.

Errors compound rather than isolate. A single-agent failure has a bounded blast radius: the session produces a bad output or takes a bad action, and the damage is contained to that session. In a multi-agent system, a bad output from an early agent becomes the input to a downstream agent. That agent trusts the input — by default, it has no reason not to — and the error propagates through the pipeline, potentially triggering a cascade of downstream actions before any governance layer catches it. One bad summarization becomes a bad database query becomes a bad customer communication.

What actually happens when one agent delegates to another?

Take LangGraph as a concrete example. When an orchestrator node delegates to a worker node, it passes a message — typically containing the task description, any relevant context, and possibly a slice of earlier state. From the worker node's perspective, this message is an instruction. The LLM running the worker node treats that instruction the same way it would treat a user's input: it follows it.

This is the trust boundary problem. LLMs don't have a built-in mechanism to distinguish an instruction from a human user from an instruction from an orchestrating agent. An orchestrating agent that has been compromised by prompt injection — or that simply made a reasoning error — can direct a subagent to take actions the subagent would never have taken if the request had come directly from a user. The subagent's individual policies won't block the action, because those policies were written with direct user input in mind, not delegated instructions.

The deeper problem: this isn't just about adversarial inputs. A perfectly correct orchestrating agent can still make a delegation that violates the spirit of the system's policies — not because anything went wrong, but because the delegation boundaries were never defined. The agent did exactly what it was built to do. Nobody specified what it wasn't allowed to delegate.

LangChain has published carefully on multi-agent architecture: when to use routers, how to structure handoffs, how to design subagent specialization. The gap is that none of that architectural thinking addresses what gets evaluated at the delegation boundary — what the receiving agent is permitted to do with what it receives. That is a governance question, and it currently goes unanswered by every major orchestration framework.

What are the three governance gaps specific to multi-agent architectures?

Gap 1: Context scope leakage. An orchestrating agent that has access to a full customer record may summarize that record and pass the summary to a specialized subagent. The summary may contain PII that the subagent's individual policy would have blocked if the subagent had accessed the customer record directly. The policy wasn't bypassed intentionally — the data just arrived via a different path, one the policy wasn't written to cover. Addressing this requires evaluating the content of context passed at delegation boundaries, not just at direct API calls to external systems.

Gap 2: Unbounded delegation depth. Multi-agent systems can spawn hierarchies several layers deep. An orchestrator delegates to a coordinator, which delegates to multiple specialists, each of which may use tool-calling sub-agents. Cost limits attached to the top-level agent don't cascade to agents at depth 3 or 4. Each layer runs under whatever policy its own definition includes — which is often nothing, because the agent was built as a component to be coordinated, not as an independently governed entity. The aggregate cost of a multi-agent pipeline can exceed any individual agent's session budget by an order of magnitude, with no policy catching the overage until the invoice arrives.

Gap 3: Broken audit trail. In a single-agent system, you can produce a coherent execution trace: what the agent was asked, what it decided, what tools it called, what it returned. In a multi-agent system, that trace must span the full hierarchy — parent to child to grandchild — to mean anything for compliance purposes. Most observability tooling traces individual agents. Connecting those traces into a cross-agent execution graph requires instrumentation at the delegation boundaries. Without it, an auditor asking "what did the system do, and why?" gets a collection of per-agent logs, not a unified chain of custody. Logs are not an audit trail.

How do you govern the coordination layer?

Three additions to single-agent governance close the gaps above.

Evaluate delegation as a policy event. Every time an agent spawns or delegates to another agent, treat the delegation itself as an enforcement point. The questions to evaluate: is the delegating agent authorized to make this delegation? What context scope is it allowed to pass? What tools should the receiving agent be permitted to use, given the nature of what's being delegated? Blocking or scoping delegations that exceed their authorized scope is the control that per-agent policies can't provide — and it's the one that stops context leakage and unbounded delegation problems before they reach execution.

Apply policies at the pipeline level, not just the agent level. Define cost ceilings, data handling rules, and operational constraints that govern entire execution patterns, not just individual agents. A research pipeline spanning four agents should have a pipeline-level token budget that the aggregate spend counts against, in addition to any per-agent limits. The pipeline ceiling governs the total. Individual agent limits govern the parts. You need both.

Instrument the full delegation graph. Governance without a connected trace is unverifiable after the fact. The instrumentation layer must capture not just what each agent did, but the full delegation graph: which agent spawned which, what context was passed at each handoff, what policies were evaluated at each boundary, what was allowed or blocked. This is what transforms a collection of per-agent logs into an actual audit trail — something you can present to a compliance team as evidence that the system operated within its defined constraints, not just evidence that the system ran.

Most teams instrument agents individually and assume those traces can be stitched together after the fact. They mostly can't, because the delegation events — the links that would connect parent traces to child traces — weren't captured at runtime.

How Waxell handles this

How Waxell handles this: Waxell's agent registry maintains a system of record for every agent running in your system — including in multi-agent hierarchies, where knowing what's running and what it's been delegated to do is itself a governance requirement. When you instrument a multi-agent workflow with the Waxell SDK, execution traces span agent hierarchies: parent-to-child delegation events are captured, the context passed at each handoff is recorded, and the full graph is queryable as a connected structure rather than fragmented per-agent logs. On top of that trace, cross-agent policy enforcement evaluates policies at delegation boundaries — not just within individual agents. A pipeline-level cost ceiling terminates the full hierarchy when aggregate spend hits the threshold, regardless of which agent in the hierarchy is accumulating cost. The governance plane treats multi-agent coordination as a first-class concern from the start: delegation is an enforcement point, not just a logging event.

If your team is deploying multi-agent systems and wants to instrument them with cross-agent governance, get early access to Waxell.

Frequently Asked Questions

What is multi-agent governance?
Multi-agent governance is the set of policies, enforcement mechanisms, and tracing infrastructure that control how AI agents behave in coordination — specifically at the delegation boundaries where one agent spawns, instructs, or hands off context to another. It extends single-agent governance to cover the coordination layer: what context agents can pass to subagents, what tools receiving agents are permitted to use given what they've been delegated, how cost and compliance constraints apply across the full hierarchy rather than per-agent in isolation, and how to produce an audit trail that spans the complete execution graph.

How is governing a multi-agent system different from governing a single agent?
Single-agent governance attaches policies to an agent or session and evaluates them before each action. This works when agents operate independently. Multi-agent systems add three requirements single-agent governance doesn't address: delegation events need to be policy evaluation points (not just code operations), context scope needs to be evaluated at handoffs (not just at direct data access), and audit trails need to span the full execution hierarchy as a connected graph. Teams that retrofit single-agent governance to multi-agent systems typically close two of these gaps and miss the third.

What is a trust boundary in a multi-agent AI system?
A trust boundary in a multi-agent system is the delegation point where one agent passes instructions or context to another. LLMs follow instructions from orchestrating agents the same way they follow instructions from users — there's no built-in authorization check at the handoff. A compromised or mistaken orchestrating agent can direct subagents to take actions they wouldn't have taken under direct user instruction. Governing trust boundaries means evaluating the full authorization chain at each delegation step: did the delegating agent have the authority to make this delegation? Does the receiving agent have the right to act on what it's received?

What happens when a subagent inherits context from a parent agent?
When an orchestrating agent passes context to a subagent — a summary, a document slice, a set of intermediate results — the subagent receives that content as its working set. Any PII, sensitive data, or confidential content that arrived in the orchestrating agent's context through its own earlier work is now accessible to the subagent, regardless of whether the subagent would have been permitted to access that data directly. This is context scope leakage: data arriving indirectly through the delegation chain, bypassing the subagent's individual access policies. The fix is evaluating content at delegation boundaries — not just at direct data access calls.

How do you trace governance across a multi-agent execution hierarchy?
Tracing governance across a multi-agent hierarchy requires instrumentation at the delegation boundaries, not just inside individual agents. Each spawning event and context handoff needs to be captured with enough information to reconstruct the full chain: which agent made the delegation, what context was passed, what policies were evaluated at that boundary, what the receiving agent was authorized to do. The output is a connected execution graph — parent traces linked to child traces through the delegation events — rather than a collection of per-agent logs. This connected graph is what compliance audits require: a chain of custody showing that each step in the hierarchy operated within its defined constraints.

Sources

Top comments (0)