Multi-Agent Systems

The multi-agent topology is documented: which agents are orchestrators, which are workers or sub-agents, what calls are permitted between each interface, what data passes across each interface, and which external agents participate.

The multi-agent topology is documented as part of the Behavior Charter (GOV-02) for each participating agent. Documentation covers which agents are orchestrators, which are workers or sub-agents, what calls are permitted between each interface, what data passes across each interface, and which external agents (if any) participate. Without this documentation, no other MAS control is assessable.

Every agent-to-agent invocation is authenticated using credentials issued to the calling agent's non-human identity. Authorization for cross-agent calls follows the principle of least privilege and is enforced at the runtime layer.

Every agent-to-agent invocation is authenticated using credentials issued to the calling agent's non-human identity (IAM-01). Authorization for cross-agent calls follows the principle of least privilege (IAM-03) and is enforced at the runtime layer, not solely in agent prompts or instructions. This control prevents unauthorized agent-to-agent communication and ensures that every cross-agent call is attributable.

User-confirmation requirements under INP-03 and pre-execution-review requirements under ACT-03 bind across multi-agent chains. A confirmation given to one agent does not authorize a downstream agent to take an unconfirmed consequential action.

User-confirmation requirements under INP-03 and pre-execution-review requirements under ACT-03 bind across multi-agent chains. A confirmation given to one agent does not authorize a downstream or sub-agent to take a separate consequential action on the user's behalf. The originating user's scope travels with the request and constrains every hop. This prevents the common pattern where a downstream agent assumes inherited authority.

No agent in a chain exercises authority exceeding that of the originating user or the originating agent. Privilege escalation through delegation is prevented at the runtime layer.

When agent A invokes agent B, the invocation should not result in agent B acting with greater authority than agent A had — and ideally not with greater authority than the originating user. MAS-04 forbids the common pattern where a downstream agent operates with broader permissions than the upstream context warrants. Privilege escalation is prevented at the runtime layer and tested as part of red-team coverage under SPC-03.

Loop and recursion detection under ACT-05 extends across agents. Suspicious cross-agent invocation patterns — including circular calls, exponential fan-out, and unbounded delegation depth — trigger automatic suspension.

Loop and recursion detection extends across agent boundaries. Suspicious cross-agent invocation patterns — circular calls, exponential fan-out, unbounded delegation depth — are detected and trigger automatic suspension. This control prevents cascading failures and runaway resource consumption that can occur when agents invoke each other without bound.

Each agent-to-agent invocation is logged under MON-01, including caller identity, callee identity, purpose, input, output, and a chain identifier linking the hop to its originating user request.

Each agent-to-agent invocation is logged under MON-01, including caller identity, callee identity, purpose, input, output, and a chain identifier linking the hop to its originating user request. Logs are sufficient to reconstruct the full chain after the fact. This control is the multi-agent extension of MON-01 and is essential for incident investigation in complex agent topologies.

Blast-radius limits under ACT-06 are evaluated across the entire chain, not only per-agent. Aggregate caps prevent a chain of individually in-bounds actions from producing an out-of-bounds combined effect.

Blast-radius limits under ACT-06 are evaluated across the entire chain, not only per-agent. Aggregate caps prevent a chain of individually in-bounds actions from producing an out-of-bounds combined effect (e.g., many small sub-agent transactions summing to an unauthorized total). This control addresses the emergent risk that arises when per-agent limits are met but the aggregate exceeds acceptable bounds.

Suspending an agent under ACT-07 also suspends or quarantines any agent currently depending on it within an active chain. The propagation behavior is documented, tested, and exercised during incident response drills.

A suspend or revoke decision propagates to dependent agents within a documented latency. Suspending an agent under ACT-07 also suspends or quarantines any agent currently depending on it within an active chain. The propagation behavior is documented, tested at least annually, and exercised during incident response drills. This ensures that a compromised agent cannot continue operating through downstream proxies.

Where the agent invokes external third-party agents (including via agent-to-agent protocols, agent marketplaces, or partner platforms), the integration is treated as a third-party dependency with documented risk assessment, contractual data-use commitments, and trust-boundary handling.

Where the agent invokes external third-party agents — including via agent-to-agent protocols, agent marketplaces, or partner platforms — the integration is treated as a third-party dependency under OUT-06 and OUT-09, with documented risk assessment, contractual data-use commitments, and trust-boundary handling under INP-02. External agents are never trusted by default.