If your AI agent communicates with another AI agent, the controls that protect each agent individually may no longer be enough.

The practical first step is to identify who governs every agent in the interaction. If one organisation controls them all, it can monitor and intervene across the complete system. If several organisations are involved, they need shared rules and infrastructure. If an agent connects to unknown parties on the open internet, it should assume those parties may be incompatible, misleading or malicious.

That is the central business lesson from Risks and controls for multi-agent systems, released by Australia’s AI Safety Institute on 10 August 2026. The report is technical research, not a new law or mandatory standard. It provides a framework for understanding how risk changes as AI agents interact across organisational boundaries.

For organisations considering autonomous AI agents, the useful question is no longer only, “Is our agent safe?” It is also, “Is the system created by all these interacting agents safe, observable and controllable?”

Why individually reliable agents can still create an unreliable system

In the report, an AI agent is software that uses a large language model to plan and carry out self-directed actions towards a human-specified goal. A multi-agent system exists when two or more agents affect what each other knows or does.

The Australian AI Safety Institute report highlights an important distinction: a collection of well-tested agents is not automatically a well-controlled system. New behaviour can emerge from the interactions between them.

Miscoordination: agents misunderstand messages, duplicate work or hand a task to the wrong destination.
Propagation and contagion: an error, false belief, malicious instruction or sensitive information moves from one agent to others.
Strategic and incentive failure: agents acting for different parties adapt in ways that create conflict, unfair coordination or harmful outcomes.
Infrastructure and environment failure: a population of agents disrupts or manipulates the shared systems, markets or resources on which it depends.

These failure patterns are cumulative. Moving into a more open environment adds risks without removing those present in the earlier tiers.

Tier 1: one organisation governs every agent

Under singular governance, one organisation controls all agents, tools and infrastructure in the system. Examples include internal coding agents, employee-support agents or a group of agents coordinating an administrative workflow. This is the most controllable tier, but interaction failures can still spread quickly.

Imagine three internal invoice-processing agents. An intake agent extracts supplier information, a verification agent checks the supplier and purchase order, and an ERP agent prepares the transaction for approval. If the intake agent invents or misreads a bank detail, the verification agent may accept it because it assumes the source was already checked. The ERP agent can then turn the shared error into a prepared payment.

Use structured handoffs with required fields, source references and confidence indicators.
Validate critical details independently against an approved system of record.
Give each agent a separate identity and minimum necessary permissions.
Require human approval before money, customer records or contractual commitments are affected.
Use checkpoints and rollback to a known-good state.
Test the complete system with contradictory, incomplete and malicious inputs.

Do not test only whether each agent completes its own task. Test whether the whole workflow reaches the correct result when one component is wrong, delayed or unavailable.

Tier 2: several organisations operate under shared rules

Under federated governance, agents from different organisations interact in a shared environment governed by agreed conditions. No participant has unilateral control over the complete system.

Consider a buyer’s procurement agent communicating with a supplier’s fulfilment agent. The buyer might request stock availability, compare delivery options and prepare an order. The supplier may respond with pricing, allocation and lead-time information.

Both agents can behave rationally for their own organisations while producing an undesirable result. Ambiguous instructions could create an excessive order. Repeated interactions could create pricing patterns nobody explicitly intended. An incorrect delivery promise might also pass through both organisations before a person sees it.

Authenticate agents and the organisations they represent.
Agree message schemas, accepted data standards and participation rules.
Define what agents may negotiate, recommend or commit.
Set price, quantity, access and transaction limits.
Agree which activity is logged and available for investigation.
Establish incident notification, escalation, suspension and dispute processes.
Define how material agent, model or infrastructure changes are communicated.

Monitoring has to look across the interaction. A single organisation’s log may not reveal a pattern that becomes visible only when both sides’ actions are considered. This is partly a technology-design task and partly an operating agreement between the participating organisations.

Tier 3: agents interact in an open environment

In an open environment, there is no central governing authority and the counterparty may be unknown. An agent could browse public websites, negotiate with online services or interact with autonomous systems it discovers while completing a task.

Imagine a sourcing agent searching the web for a component. It encounters several sales agents. One provides a malicious instruction embedded in a product page. Another uses multiple fabricated identities to create false consensus or an artificial reputation signal.

The report describes two broad responses: lock the agent down with narrow goals, limited tools and tight permissions, or use voluntary standards to identify compatible agents and establish shared governance at runtime. The identity, reputation and tool-register infrastructure needed for the second approach is not yet widely established.

Treat external content and agent messages as untrusted input.
Keep web-facing activity isolated from sensitive internal systems.
Allow read access before granting write or transaction access.
Verify supplier identity and material claims through independent sources.
Use short-lived credentials, rate limits and strict spending limits.
Prevent the agent from exposing secrets or confidential context.
Require human approval for payments, commitments and irreversible actions.
Stop when identity, intent or system state cannot be verified.

A practical control checklist before deployment

Map the complete system: every agent, model, tool, data source, API, memory store and handoff.
Classify the governance tier using the minimum governance shared by every participant.
Name owners for the business outcome, technical operation, security response and external relationship.
Define what each agent may read, draft, recommend, send, change, purchase or delete.
Use least privilege and short-lived credentials wherever possible.
Structure and authenticate handoffs, including source provenance, identity, freshness and integrity.
Test invalid inputs, unavailable systems, conflicting goals, prompt injection, compromised counterparties and cascading errors.
Monitor tool calls, handoffs, denied actions, overrides, identity changes and unusual patterns, not only final answers.
Build spending limits, rate limits, isolation, stop conditions, checkpoints, rollback and tested fallback processes.
Agree participation standards, evidence retention, incident notification and change management with partners.
Reassess the system when models, tools, permissions, partners or operating conditions change.

The leadership decision is about reach

The report’s most useful governance question is: who is positioned to act when something goes wrong? Within one organisation, the answer may be clear. Across a partnership, control depends on shared arrangements. On the open web, some failures may sit beyond any single organisation’s reach.

That does not mean organisations should avoid multi-agent systems. It means autonomy should expand only as evidence, monitoring and governance expand with it. Start with a narrow workflow, prove that the complete system behaves reliably, then increase permissions or external interaction in controlled stages.

Our AI Agents Operating Model explains how to define task, tool, data, approval and stop boundaries for an individual deployment. The Australian AI Safety Institute’s framework extends that thinking to the agents and organisations on the other side of the interaction.

What is the difference between a single AI agent and a multi-agent system?

A single agent operates without another agent affecting its knowledge or actions. A multi-agent system has at least two connected agents. They might exchange messages, call each other through APIs or work through a shared file, platform or marketplace.

Does the report prohibit agents from interacting across organisations?

No. It is an analytical framework, not a prohibition or new law. It helps organisations identify the governance tier, relevant risks, available controls and situations where no participant has complete reach.

Is a human in the loop enough?

Not by itself. Human approval is important for consequential actions, but people also need usable logs, clear escalation signals and enough time to intervene. Structured handoffs, identity, least privilege, monitoring, containment and rollback remain necessary.

What should a smaller organisation do first?

Begin with a narrow internal workflow under singular governance. Map every tool and permission, test the complete workflow and retain human approval for high-impact actions. If the agent later connects to suppliers, customers or the open web, reassess the tier before expanding access.

Build the controls before expanding autonomy

ExIQ helps organisations design AI-agent operating models, permissions, integrations, tests and human oversight around real workflows. If your agents will interact across teams, suppliers, customers or public services, contact ExIQ to map the system and its control boundaries before deployment.

This article summarises technical and governance guidance and provides ExIQ’s practical interpretation for implementation. It is not legal advice. Organisations should obtain appropriate legal, privacy, cybersecurity and regulatory advice for their circumstances.