Inter-Agent Trust and Attestation Governance requires that every interaction between AI agents in a multi-agent system is mediated by a verifiable trust framework where each agent can cryptographically attest to its identity, governance posture, and capability scope before being granted participation in shared workflows. In multi-agent environments, agents must cooperate — sharing data, delegating tasks, and relying on each other's outputs. Without a trust framework, any agent that can send a message to another agent is implicitly trusted, regardless of whether it is properly configured, has been compromised, operates under an adequate governance posture, or is even a legitimate agent within the organisation's estate. AG-080 requires that agents verify each other's identity and governance attestations before accepting delegations, sharing data, or relying on outputs, using cryptographic mechanisms that cannot be forged by the agents themselves. The control type is Assurance: this dimension provides ongoing confidence that trust relationships in the multi-agent system are well-founded, that agents only interact with verified peers, and that the trust fabric is continuously validated rather than assumed.
Scenario A — Rogue Agent Joins Trusted Workflow: An enterprise deploys a multi-agent supply-chain system with 14 agents handling procurement, logistics, invoicing, and payment. A developer deploys a test agent to the same messaging infrastructure during a debugging session. The test agent, configured with production-equivalent credentials but no governance controls, begins receiving delegation requests intended for the production invoicing agent — both listen on the same message topic. Over 6 hours, the test agent processes 23 invoices totalling £892,000, approving all of them without the compliance checks that the production agent would have applied. Three invoices — totalling £147,000 — are later identified as fraudulent.
What went wrong: No trust verification existed between agents. Any agent that could connect to the messaging infrastructure was implicitly trusted by all other agents. The production agents did not verify the identity or governance posture of the agent processing their delegations. The test agent was not attested as governance-compliant. Consequence: £147,000 in fraudulent payments, full invoice re-review required for all 23 transactions, compliance investigation, messaging infrastructure redesigned at £310,000 cost.
Scenario B — Compromised Agent Poisons Peer Outputs: A financial risk-assessment multi-agent system includes Agent R (risk scorer), Agent V (valuation), and Agent D (decision). Agent V is compromised through a model supply-chain attack — a malicious model weight update causes it to systematically undervalue high-risk positions by 15–40%. Agent R and Agent D continue to trust Agent V's outputs because no attestation mechanism exists to verify Agent V's governance posture or model integrity. Over 3 weeks, Agent D approves 67 positions based on understated risk assessments. The cumulative undisclosed risk exposure reaches £4.2 million before a quarterly manual review detects the discrepancy.
What went wrong: No attestation framework required Agent V to demonstrate its model integrity, last validation date, or governance compliance status before other agents accepted its outputs. Agent R and D treated Agent V's outputs as trustworthy because it was "in the system" — there was no mechanism to verify that V's governance posture remained valid. Consequence: £4.2 million in undisclosed risk exposure, regulatory finding for inadequate model risk management, 3-week detection latency.
Scenario C — Cross-Organisation Agent Trust Without Verification: Two organisations establish a multi-agent integration for automated trade matching. Organisation A's matching agent accepts trade confirmations from Organisation B's settlement agent. Organisation B decommissions the original settlement agent and deploys a replacement with different capabilities and no governance certification. Organisation A's matching agent continues to accept confirmations from the replacement because trust was established at the network level (IP allowlist) rather than at the agent attestation level. The replacement agent uses a different date format convention, causing 12% of trade confirmations to contain incorrect settlement dates over 2 weeks.
What went wrong: Trust was based on network-level identity (IP address, TLS certificate for the organisation) rather than agent-level attestation. When Organisation B replaced its agent, Organisation A had no mechanism to detect that the counterparty agent had changed. No re-attestation was triggered. Consequence: 340 trade confirmations with incorrect dates, settlement failures requiring manual intervention, counterparty dispute, estimated cost £78,000 in operational losses and penalties.
Scope: This dimension applies to all multi-agent systems where two or more agents interact — through direct messaging, shared queues, shared data stores, API calls, or any other communication mechanism. An interaction occurs whenever one agent's output influences another agent's behaviour, whether through explicit request-response, event-driven triggering, or shared-state observation. The scope includes intra-organisational multi-agent systems, cross-organisational multi-agent integrations, and hybrid systems where agents from different organisations participate in shared workflows. Single-agent systems with no inter-agent interaction are excluded. The scope extends to agents that interact indirectly through intermediaries (e.g., Agent A writes to a shared store, Agent B reads from it) — the trust verification applies to the provenance of the data, not only to direct communication channels.
4.1. A conforming system MUST establish a trust registry that records, for every agent authorised to participate in multi-agent workflows: the agent's cryptographic identity (per AG-012), its current governance posture attestation, its authorised capability scope, and its attestation validity period.
4.2. A conforming system MUST require each agent to present a verifiable attestation of its identity and governance posture before any other agent accepts its delegations, data, or outputs.
4.3. A conforming system MUST reject interactions from agents whose attestation has expired, been revoked, or cannot be cryptographically verified.
4.4. A conforming system MUST ensure that attestation verification is performed by infrastructure independent of the agents being verified — no agent can self-attest its own trustworthiness to a peer without external validation.
4.5. A conforming system MUST detect and alert when an unattested agent attempts to participate in a multi-agent workflow.
4.6. A conforming system SHOULD implement graduated trust levels based on governance posture — agents with higher attestation levels (e.g., independently audited, adversarially tested) may be granted broader interaction privileges than agents with baseline attestation.
4.7. A conforming system SHOULD re-attest agents periodically (at minimum every 24 hours for production systems) and after any configuration change, model update, or governance policy modification.
4.8. A conforming system SHOULD support federated trust for cross-organisational multi-agent systems, where each organisation operates its own trust registry and cross-organisational trust is established through mutual attestation or a shared trust anchor.
4.9. A conforming system MAY implement continuous attestation — real-time monitoring of agent governance posture with automatic trust revocation if posture degrades below required thresholds.
Multi-agent systems derive their value from cooperation between agents, but cooperation requires trust, and trust in an automated system must be established through verifiable mechanisms rather than implicit assumptions. In human organisations, trust is established through hiring processes, background checks, role assignments, and continuous supervision. The multi-agent equivalent requires identity verification, governance posture attestation, capability scope verification, and continuous re-validation.
The core problem AG-080 addresses is implicit trust — the assumption that any agent within the system boundary is trustworthy simply because it exists within that boundary. This assumption fails in practice for several reasons. First, agents are deployed and updated frequently; a governance-compliant agent today may be non-compliant tomorrow after a model update or configuration change. Second, multi-agent environments are dynamic — agents are added, removed, and replaced, and without attestation, other agents have no mechanism to detect these changes. Third, in cross-organisational systems, one organisation cannot verify the governance posture of another organisation's agents through network-level controls alone.
The Assurance control type reflects the continuous nature of trust verification. Trust is not a one-time gate — it must be maintained throughout the agent's operational lifetime. An agent that passed governance certification at deployment but has since been modified without re-certification should not be trusted at the same level. AG-080 requires that trust attestations have validity periods, that re-attestation occurs after changes, and that the trust framework provides ongoing assurance rather than a point-in-time assessment.
The requirement for infrastructure-independent attestation verification prevents circular trust: if Agent A verifies Agent B's attestation, and Agent B verifies Agent A's attestation, but both verification processes are compromised, the trust framework provides no actual assurance. External verification — through a trust registry, a certificate authority, or equivalent mechanism — breaks this circularity.
Inter-agent trust and attestation governance requires a trust infrastructure that provides identity verification, governance posture attestation, and continuous trust validation for all agents in the multi-agent system. The core components are: a trust registry, an attestation mechanism, a verification protocol, and a revocation mechanism.
Recommended patterns:
Anti-patterns to avoid:
Financial Services. Inter-agent trust maps to existing counterparty risk management frameworks. Just as financial institutions verify counterparty creditworthiness before trading, agents should verify peer governance posture before interacting. The trust registry is analogous to a KYC (Know Your Customer) database for agents. For cross-organisational trading systems, federated trust should align with existing industry trust frameworks such as SWIFT's security controls or FIX protocol authentication.
Healthcare. Inter-agent trust in clinical multi-agent systems must include verification of clinical authority scope. An agent attested for triage should not be trusted to provide treatment recommendations. Trust attestations should encode clinical scope boundaries aligned with healthcare provider credentialing frameworks. HIPAA requires verification that any entity accessing protected health information is authorised — inter-agent attestation extends this requirement to automated agents.
Critical Infrastructure. In safety-critical multi-agent systems (e.g., power grid management, industrial control), trust attestation must include safety certification level. An agent controlling physical actuators must verify that any commanding agent has appropriate safety certification. The attestation framework should integrate with IEC 62443 security level requirements and functional safety standards (IEC 61508 / IEC 61511).
Basic Implementation — The organisation maintains a list of authorised agents, and agents validate peer identity using shared secrets or API keys. Trust is binary (authorised or not) with no graduated levels. Attestation is checked at deployment time but not re-validated during operation. Governance posture is not included in trust verification — an agent with a valid API key is trusted regardless of its current configuration. This level prevents completely unknown agents from participating but does not detect compromised, misconfigured, or governance-degraded agents.
Intermediate Implementation — Agents present cryptographic attestations that include identity, governance posture level, capability scope, and validity period. Attestations are issued by an infrastructure component independent of the agents (e.g., a certificate authority or trust registry). Expired or revoked attestations cause interaction rejection. Re-attestation occurs on a defined schedule (at least every 24 hours) and after any configuration change. The trust registry is monitored for availability, and trust verification failures are logged and alerted. Graduated trust levels allow differentiated interaction privileges based on governance posture.
Advanced Implementation — All intermediate capabilities plus: continuous attestation monitors agent governance posture in real-time and revokes trust automatically if posture degrades. Cross-organisational federated trust enables multi-party multi-agent workflows with mutual verification. Attestation includes model integrity hashes — if an agent's model changes, its attestation is automatically invalidated until re-certification. The trust framework has been independently tested for resistance to attestation forgery, replay attacks, and privilege escalation. Trust metrics (attestation failure rate, re-attestation frequency, scope violation attempts) are reported to governance dashboards. Trust decisions feed into AG-028 (Active Inter-Agent Collusion Detection) to identify agents that repeatedly interact in patterns suggesting coordinated misbehaviour.
Required artefacts:
Retention requirements:
Access requirements:
Test 8.1: Attestation Requirement Enforcement
Test 8.2: Expired Attestation Rejection
Test 8.3: Attestation Forgery Resistance
Test 8.4: Scope Verification
Test 8.5: Re-Attestation After Configuration Change
Test 8.6: Trust Registry Unavailability
Test 8.7: Cross-Organisation Federated Trust
| Regulation | Provision | Relationship Type |
|---|---|---|
| EU AI Act | Article 9 (Risk Management System) | Direct requirement |
| EU AI Act | Article 15 (Accuracy, Robustness and Cybersecurity) | Direct requirement |
| SOX | Section 404 (Internal Controls Over Financial Reporting) | Supports compliance |
| FCA SYSC | 6.1.1R (Systems and Controls) | Direct requirement |
| NIST AI RMF | GOVERN 1.1, GOVERN 1.7, MAP 3.5 | Supports compliance |
| ISO 42001 | Clause 6.1 (Actions to Address Risks), Clause 8.4 (AI System Impact Assessment) | Supports compliance |
| DORA | Article 9 (ICT Risk Management Framework), Article 28 (Third-Party ICT Service Providers) | Supports compliance |
| eIDAS 2.0 | Article 45 (Trust Services) | Supports compliance |
Article 9 requires a risk management system that identifies and mitigates risks from high-risk AI systems. In multi-agent systems, the risk of rogue, compromised, or ungoverned agents participating in trusted workflows is a first-order risk. AG-080 directly mitigates this risk by requiring verifiable attestation before any inter-agent interaction. The regulation requires risk mitigation measures to be "effective and proportionate" — for multi-agent systems handling financial or safety-critical operations, infrastructure-layer trust verification is the proportionate response to the risk of implicit trust.
Article 15 requires high-risk AI systems to achieve an appropriate level of cybersecurity, including resilience against unauthorised third parties. In multi-agent systems, an unattested agent is functionally equivalent to an unauthorised third party — it can influence system behaviour without verified identity or governance posture. AG-080 implements the cybersecurity requirement for inter-agent interactions by ensuring all participants are authenticated and governance-verified.
For multi-agent financial systems, inter-agent trust is an internal control. A SOX auditor will ask: "How does the organisation ensure that only authorised, governance-compliant agents participate in financial workflows?" Without attestation, the answer is "we trust the network configuration" — an inadequate control. AG-080 provides the attestation framework that demonstrates financial agents interact only with verified, governance-compliant peers.
The FCA requires adequate systems and controls. For multi-agent deployments, this includes controls on which agents can interact and under what conditions. A multi-agent system where any deployed agent can participate in any workflow without trust verification has inadequate systems and controls. AG-080 provides the trust verification framework that the FCA would expect for multi-agent financial systems.
Article 9 requires ICT risk management frameworks that address inter-system dependencies. In multi-agent systems, agents are inter-dependent — one agent's compromise can propagate through trust relationships. AG-080 mitigates this by ensuring trust is continuously validated. Article 28 addresses third-party ICT service providers — in cross-organisational multi-agent systems, the counterparty's agents are effectively third-party ICT services, and federated trust attestation provides the due diligence mechanism.
eIDAS 2.0 establishes a framework for electronic trust services within the EU. For multi-agent systems operating across EU member states, agent attestation mechanisms should align with eIDAS trust service standards, enabling cross-border agent trust verification using recognised trust frameworks. This is particularly relevant for cross-organisational multi-agent systems in the European Single Market.
| Field | Value |
|---|---|
| Severity Rating | Critical |
| Blast Radius | Multi-agent system scope — potentially cross-organisation where trust failures propagate through federated systems |
Consequence chain: Without inter-agent trust and attestation, a multi-agent system has no mechanism to distinguish between legitimate, governance-compliant agents and rogue, compromised, or ungoverned agents. The immediate technical failure is implicit trust — any agent that can communicate is automatically trusted by all peers. The operational impact is that a single compromised or misconfigured agent can inject corrupted data, execute unauthorised delegations, or exfiltrate sensitive information through inter-agent channels without detection. The failure compounds with scale: in a 50-agent system, one compromised agent can influence 49 peers. In cross-organisational systems, a trust failure in one organisation propagates to all connected organisations. The business consequence includes regulatory enforcement for inadequate cybersecurity controls (EU AI Act Article 15 fines up to 3% of global turnover), financial losses from actions taken based on corrupted agent outputs, and systemic risk in multi-agent financial systems where trust failures can cascade through interconnected workflows. Unlike single-agent failures that are bounded by one agent's mandate, trust failures in multi-agent systems are bounded only by the system's total connectivity — every agent that trusts the compromised agent inherits the exposure.
Cross-references: AG-012 (Agent Identity Assurance) provides the cryptographic identity framework that attestations reference. AG-009 (Delegated Authority Governance) defines the authority model that trust scope should align with. AG-029 (Credential Integrity Verification) ensures the cryptographic credentials used for attestation are themselves trustworthy. AG-028 (Active Inter-Agent Collusion Detection) uses trust and interaction data to detect coordinated misbehaviour. AG-015 (Organisational Namespace Isolation) ensures trust boundaries respect organisational separation. AG-079 (Delegation Chain Provenance Governance) records the delegation chains that trust attestation enables. AG-042 (Collective Intelligence Governance) addresses governance of collective behaviour emerging from trusted agent interactions.