Enterprise AI Governance Best Practices

Why Multi-Agent Systems Require Their Own Governance

Most agent governance assumes a single agent acting on systems. Increasingly, agents do not act alone.

An agent may invoke another agent, hand work to a specialist agent, coordinate several agents toward a goal, or be created and directed by an agent whose role is to manage other agents.

When agents interact, the unit that must be governed is no longer only the individual agent. It is also the system they form together.

That system has properties the individual records do not capture: a combined reach across everything its members can touch, a combined authority that may exceed what any single member was granted, and failure modes that exist only because the agents are connected.

This chapter governs those properties. It does not repeat the governance of the individual agent, which is established elsewhere in this document, but adds what interaction makes necessary.

Preserve Attribution Across the Chain

When one agent acts through others, the enterprise must still be able to say who did what.

Each action in a multi-agent interaction should be attributable to the agent that performed it, the agent that requested it, and the authority under which it was taken. A record that shows only the final outcome, or only the first agent in the chain, is not enough to govern it.

The interaction itself should be reconstructable. The enterprise should be able to trace an outcome backward through the agents that contributed to it, in the order they contributed, so that accountability does not dissolve into the collective.

Attribution across agents depends on each agent holding its own identity, which is governed as described in this document’s treatment of non-human identity. A chain in which agents share an identity cannot be attributed and therefore cannot be governed.

Contain Combined Authority

The most dangerous property of a multi-agent system is that its combined authority can exceed the authority of any single agent within it.

An agent that can only read, feeding an agent that can only write, may together accomplish what neither was permitted to do alone. The composite reach of the system should be assessed as a whole, not only agent by agent.

Authority that passes between agents should never expand as it passes. This document establishes, in its treatment of non-human identity, that delegated authority should not exceed the authority of the agent delegating it. At the system level, the same principle means the combined authority of a chain should be bounded and understood rather than allowed to accumulate.

Where the combined authority of a multi-agent system reaches a level of risk that no single agent would be permitted, the system should be governed at that higher level, with oversight and controls proportionate to what it can do together.

Govern Orchestrating and Supervisory Agents

An agent whose role is to direct other agents is a distinct governance object.

An orchestrating agent holds an elevated form of authority: it decides which agents act, in what order, and toward what goal. That authority should be recorded, scoped, and reviewed with the seriousness its reach deserves.

An orchestrating agent should not become a route around the controls applied to the agents beneath it. If a supervised agent is restricted from an action, invoking it through an orchestrator should not bypass that restriction.

The ability of one agent to create, spawn, or direct another should itself be a scoped and reviewed permission, so that the population of agents cannot expand without governance simply because an agent was allowed to generate more of them.

Prevent Cascading Failure

One agent’s output frequently becomes another agent’s input. This is the source of much of a multi-agent system’s value, and of its most characteristic failure.

An error, hallucination, unsafe output, or unauthorized action in one agent can be accepted as trusted input by the next, and propagate through a chain that no human is watching, growing as it goes.

The enterprise should not assume that the output of one agent is safe simply because it came from another agent rather than from an external source. Interactions between agents deserve the same scrutiny applied to inputs from outside the system.

Where the consequences of propagation are significant, the enterprise should place checks between agents, such as validation of critical outputs before they are consumed, limits on how far an action can travel without human confirmation, and boundaries that stop a fault from spreading across the whole system.

Standardize and Govern Interaction Protocols

Agents interact through some means of connection. When every team improvises that connection differently, agent-to-agent interaction becomes a sprawl of incompatible and unmonitored channels.

It is not the purpose of this document to select a particular protocol. The best practice is that the enterprise chooses standard protocols for agent interaction, requires their use, and governs them, rather than allowing each team to invent its own.

Standardizing the connection layer is itself a control. It makes agent-to-agent interaction observable, attributable, and containable in ways that ad hoc integration cannot be, and it gives the enterprise a defined place to apply monitoring and boundaries.

The enterprise should inventory where agents connect to one another, govern the versioning and change of the protocols they use, and treat an unmanaged interaction channel as it treats any other ungoverned surface: as a risk to be brought under governance.

Recognize and Constrain Emergent Behavior

A multi-agent system can produce behavior that no individual agent was designed or approved to exhibit.

Agents adapting to one another, retrying, escalating, or combining their actions can lead to outcomes that appear nowhere in any single agent record and that no one specifically intended.

The enterprise should monitor the behavior of the system as a whole, not only the health of its individual agents, so that emergent behavior is detected rather than discovered after it has caused harm.

Where a multi-agent system operates with meaningful authority, it should have a defined boundary of acceptable collective behavior and a means of halting the system, not merely its individual agents, when that boundary is crossed.

Connect Multi-Agent Systems to the Inventory

A multi-agent system should be visible in governance as more than a set of unrelated agent records.

The enterprise should be able to see which agents participate in a system, how they relate, which orchestrates which, and what the system as a whole is permitted to do. The relationships between agents are governable information, not incidental detail.

Where a multi-agent system carries significant authority or risk, its composite should be owned, assessed, and reviewed as an entity in its own right, so that responsibility for the whole does not fall between the owners of its parts.

Governance Questions Multi-Agent Systems Should Answer

For Multi-Agent Systems, governance should answer what exists, who owns it, what is affected, which risks, obligations, controls, evidence, incidents, changes, and gaps require action.