Mythos Hardening Control · MRIS 2.0 · Applies to TISAX®

MHC-16 Multi-agent integrity

Limits how far a manipulated, faulty or compromised agent can act within a chain or orchestration of multiple AI agents before damage occurs or spreads.

At a glance

Operational benefit: limits how far a manipulated, faulty or compromised agent can act within a chain or orchestration of several AI agents before damage arises or spreads.
Policy affected: the policy on the use of AI agents (an extension for multi-agent architectures).
Dependencies: presupposes MHC-13 (single-agent identity, tool access and kill switch as the foundation).
Effort drivers: the number and complexity of agent-to-agent connections, the degree of orchestration, the extent of shared memory/context systems.
Cost envelope (license/person-days, indicative order of magnitude without individual prices; relevant only once several agents communicate in production): SME — license low to medium (mostly self-configuration within the existing agent framework rather than a separate product), roughly 20–40 person-days · Midcap — license medium, roughly 40–90 person-days · Enterprise — license medium to high (several complex orchestrations, many trust boundaries), roughly 90–180 person-days.
Primary metric: share of agent-to-agent connections with authenticated, integrity-protected communication and a functioning circuit breaker.
Standards touched (no claim of fulfilment): no comparison framework from phase 3 applicable (original); OWASP Top 10 for Agentic Applications (ASI06, ASI07, ASI08).

Control statement

Organizations deploying several communicating AI agents in production (multi-agent systems, orchestrator/sub-agent architectures, agent chains) secure the communication between the agents technically, in addition to the single-agent safeguards (MHC-13): authenticated and integrity-protected messages between agents, a separation of shared memory and context systems along clear trust boundaries, and a circuit breaker that limits the spread of a faulty or manipulated agent to downstream agents.

Purpose and threat relevance

The single-agent safeguard from MHC-13 assumes that an agent can be considered in isolation. As soon as several agents communicate with each other — for example a planning agent that delegates sub-tasks to specialized execution agents, or several agents with access to a shared store — additional, emergent risks arise: an agent may implicitly trust messages from another agent without checking that agent’s identity or the integrity of the message (insecure inter-agent communication, among other things via MCP/A2A protocols). A shared memory or context store can be poisoned by a single manipulated interaction (memory/context poisoning) and then affects all subsequent consumers of that store, potentially across sessions and agents. And a faulty or manipulated result from one agent, if passed on unchecked as trusted input to the next agent, can amplify within the chain rather than being dampened (cascading failures) — with effect on a timescale of seconds, outside direct human oversight. Notably, even where no single agent on its own satisfies the well-known "lethal trifecta" pattern (simultaneous access to sensitive data, exposure to untrusted content, and the capability for external communication), a chain of several agents can satisfy that pattern in aggregate, where each agent carries only part of it — a blind spot where risk is assessed only per agent rather than system-wide. These three threats correspond to ASI06, ASI07 and ASI08 of the OWASP Top 10 for Agentic Applications. The protective objective is that a single compromised or faulty agent cannot act on other agents or shared stores without restraint.

Effect across frameworks

These are the controls and requirements the MHC acts on. The classification shows how much each control loses its effect under AI-enabled attacks.

Original addition: MHC-16 is not mapped to any TISAX® control and goes beyond the diagnosis of the catalogue.

Maturity path

Initial: an inventory of agent-to-agent connections exists, communication not yet technically secured.
Defined: authenticated, integrity-protected inter-agent communication active; memory/context systems separated along the trust boundaries; a circuit breaker in place, at least manually triggerable.
Managed: circuit breaker automated with defined thresholds; regular testing against context poisoning and cascade effects; the trust-boundary map kept up to date.

MVP staging by protection requirement: here too the following applies: not every multi-agent architecture carries the same systems with the same protection requirement from the outset. At normal protection requirement, simple shared authentication between agents (for example a shared secret instead of full cryptographic identity verification) and a manually triggerable circuit breaker suffice as an MVP; at high protection requirement, cryptographic inter-agent authentication (connecting to the agent identity from MHC-13) and an automated circuit breaker with defined thresholds become mandatory; at very high protection requirement, provenance marking in the shared store additionally becomes mandatory, and the context-poisoning/cascade test at least annually remains the unchanged target.

Measurement and audit evidence

Metric: share of agent-to-agent connections with authenticated, integrity-protected communication (target: 100%); share of production multi-agent systems with a documented trust-boundary map and a functioning circuit breaker (target: 100%).
Evidence: the trust-boundary map, configuration evidence of the authentication, the test record of the context-poisoning/cascade test, the circuit-breaker trigger history.
Verification logic (following ISO/IEC 27001, Clause 9): documented? — a trust-boundary map per multi-agent system; responsible? — a named overall owner per system, in addition to the single-agent owners from MHC-13; frequency? — testing at least annually given the rapid development in this field; tolerance? — no production multi-agent system without authenticated inter-agent communication and a functioning circuit breaker.
Evidence mapping to the ISA catalogue: not applicable — MHC-16 is entirely original and not assigned to any TISAX® control (see Section 9); the MHC evidence above forms the sole basis for audit preparation.

Typical mistakes

Agents implicitly trust messages from other agents because they come "from the organization’s own system" — no distinction between internally vetted and externally influenced provenance.
A shared memory or context store with no provenance marking — afterwards it cannot be reconstructed which agent or which external source caused a particular entry.
No circuit breaker — a single faulty or manipulated agent continues to feed an entire chain or orchestration with faulty results, unrestrained.
Risk assessment is carried out only per individual agent, not for the chain as a whole — a chain that in aggregate satisfies a lethal-trifecta pattern remains undetected, because no single agent within it is conspicuous.

Delimitation and residual risk

Delimitation: presupposes an architecture with several communicating agents; the safeguarding of a single agent (identity, tool access, kill switch, baseline hardening against prompt injection) is governed by MHC-13, on which this entry builds.
Residual risk: emergent misbehaviour in complex multi-agent systems is not fully predictable; a circuit breaker limits the impact but does not prevent every individual faulty decision.
TISAX® controls: none. This MHC is entirely original — no TISAX® requirement finding from Part I underlies it (see Part I, section "Original additions beyond TISAX®").
Framework: original — no comparison framework from phase 3 applicable; the OWASP Top 10 for Agentic Applications (ASI06 memory and context poisoning, ASI07 insecure inter-agent communication, ASI08 cascading failures) as a threat taxonomy, not as a compliance framework; priority P2, forward-looking — relevant once several agents communicate with each other in production (see the prioritization chapter).

Implementation in detail

Organizational and technical implementation, implementation examples and the prioritization within the overall programme are described in the Implementation Guide.

Implementation Guide (PDF)Back to the MHC catalog