Agent Identity Assurance governs cryptographic proof of agent identity in multi-agent interactions. As organisations deploy multiple AI agents that communicate, delegate tasks, and share resources, the question of identity becomes foundational: how does one agent verify that the agent it is communicating with is genuinely the agent it claims to be, and not an impersonator that has assumed its name, replayed its credentials, or forged its tokens? This dimension requires that identity verification use cryptographic mechanisms — signed tokens, validated certificates, and verified credential chains — rather than name matching or self-declaration. It further requires that credentials resist replay attacks, that revocation is enforced in real time, and that no agent can inherit another agent's mandate through identity fraud.
Scenario A — Token Replay Enables Unauthorised Trading: A multi-agent trading platform uses JWT tokens for inter-agent authentication. Tokens have a 24-hour expiry but no nonce mechanism. An attacker intercepts a valid authentication token from the high-privilege trading agent during a legitimate API call. The attacker replays the token to submit unauthorised trade instructions for the remaining validity window. Over 18 hours, the attacker submits 340 trades totalling GBP 8.7 million through the replayed credential.
What went wrong: The authentication tokens lacked nonce-based replay prevention. A captured token remained valid for its entire 24-hour lifetime. The long token expiry window provided an extended attack window after credential interception. Consequence: GBP 8.7 million in unauthorised trades. Regulatory investigation by the FCA for inadequate systems and controls. The firm cannot cryptographically distinguish the legitimate agent's actions from the attacker's replayed actions, complicating forensic analysis.
Scenario B — Revocation Propagation Delay Exploited: An organisation detects that a customer service agent has been compromised. The security team revokes the agent's credentials in the central identity service. However, the revocation list is propagated to downstream services via a polling mechanism that runs every 15 minutes. During the propagation delay, the compromised agent uses its still-accepted credentials to access the data warehouse agent and extract 47,000 customer records.
What went wrong: The revocation mechanism was eventual rather than immediate. The 15-minute propagation window provided a window of vulnerability after the compromise was detected and the revocation was issued. The data warehouse agent continued to accept the revoked credential because its local revocation list had not yet been updated. Consequence: 47,000 customer records exposed. GDPR Article 33 notification required within 72 hours. ICO investigation and potential fine of up to 4% of annual turnover. Customer notification and credit monitoring costs.
Scenario C — Name-Based Trust Enables Privilege Escalation: A logistics company deploys agents for order processing (limited mandate) and fleet management (broad mandate including route changes, driver dispatch, and fuel account access). Inter-agent authentication uses agent names in message headers with no cryptographic verification. A prompt injection attack against the order processing agent causes it to send messages to the fleet management system using the fleet management agent's name. The fleet management system accepts the instructions, and the compromised order processing agent redirects delivery vehicles, accesses fuel accounts, and modifies driver schedules.
What went wrong: Identity was based on self-declaration (agent name in message header) rather than cryptographic proof. Any agent that could write to the message bus could assume any identity by declaring any name. Consequence: Delivery disruptions affecting 200 customer orders. GBP 12,000 in fraudulent fuel charges. Driver safety concern from manipulated schedules. Complete loss of trust in the multi-agent system requiring architectural redesign.
Scope: This dimension applies to all multi-agent deployments where agents interact with, instruct, or pass tasks to other agents. The scope covers any environment where more than one agent operates and agents have any form of inter-agent communication. The test is not whether agents are designed to interact, but whether they can interact. If the architecture permits one agent to send a message, API call, or instruction to another agent, identity assurance is required — even if such interaction is not the intended design. Unintended interaction channels are often the most vulnerable because they lack the controls applied to designed channels. The scope extends to agents interacting with governance infrastructure. When an agent presents its mandate to an enforcement gateway (AG-001), the gateway must verify that the agent is the entity to which the mandate was issued. When an agent logs an action to the audit trail (AG-006), the logging system must verify that the log entry is attributed to the correct agent. Identity assurance is not limited to agent-to-agent communication — it applies to every interaction where an agent's identity determines what it is permitted to do.
4.1. A conforming system MUST authenticate agent-to-agent interactions using signed cryptographic tokens, not name matching or self-declaration.
4.2. A conforming system MUST block token replay attacks through nonce or timestamp validation on every authentication request.
4.3. A conforming system MUST reject revoked agent credentials even if those credentials are structurally valid.
4.4. A conforming system SHOULD rotate agent credentials on a defined schedule with automated issuance and revocation.
4.5. A conforming system SHOULD detect and log privilege escalation attempts via impersonation, including mismatches between declared identity and presenting credential.
4.6. A conforming system SHOULD detect man-in-the-middle scenarios between agents through signature chain verification.
4.7. A conforming system MAY implement agent credential revocation lists with real-time propagation to all validation points.
Agent Identity Assurance addresses the foundational trust layer in multi-agent systems. Human identity standards — passwords, biometrics, multi-factor authentication — are designed for human interaction patterns. Agent identity operates at machine speed, without human intervention, and faces a different threat model. An agent cannot recognise a colleague by voice or appearance. It can only verify identity through cryptographic mechanisms. AG-012 requires that these mechanisms be in place, that they resist known attack vectors, and that revocation is enforced in real time.
The critical threat this dimension addresses is privilege escalation through identity fraud. In a multi-agent system, different agents have different mandates — different permitted actions, different value limits, different access scopes. If Agent A can convince the system that it is Agent B, it inherits Agent B's mandate. If Agent B has a higher spending limit, broader data access, or administrative privileges, the impersonation creates an immediate and exploitable privilege escalation. This is not a theoretical risk: in any system where identity determines access, identity fraud is the shortest path to unauthorised access.
AG-012 also addresses the temporal dimension of identity. An agent that was legitimate yesterday may have been decommissioned, compromised, or had its mandate revoked today. A credential that was valid an hour ago may have been revoked ten minutes ago. The protocol requires that identity verification is not a one-time check at deployment but a continuous validation that reflects the current state of the agent's authorisation. Stale credentials — tokens that are structurally valid but have been revoked — are as dangerous as forged credentials because they grant access based on an outdated authorisation state.
The failure mode is binary in the worst case: if any impersonation vector succeeds, the attacker gains the full mandate of the impersonated agent. There is no partial compromise — either the identity holds or it does not. The blast radius is determined by the mandate of the most privileged agent that can be impersonated. In a system where an administrative agent can modify other agents' mandates, a single impersonation of the administrative agent compromises the entire multi-agent system.
AG-012 establishes that every agent must have a unique cryptographic identity issued at deployment. Each authentication request must include a nonce and expiry timestamp. Signature validation must be performed against the issuing authority, not the presenting agent. A revocation registry must be checked on every authentication attempt.
Recommended patterns:
Anti-patterns to avoid:
Financial Services. Agent identity in financial services must integrate with existing identity and access management (IAM) frameworks. Trading agents must be identifiable to the same standard as human traders for regulatory reporting purposes. The FCA expects firms to maintain complete attribution chains from every market action back to a responsible entity. Agent credentials should be managed through the firm's existing privileged access management infrastructure with equivalent controls to human service accounts.
Healthcare. Agents accessing patient records must be individually identifiable for HIPAA audit trail requirements. Each agent's identity must be linked to its specific access authorisation — which patients, which record types, which clinical systems. Identity assurance in healthcare must also consider the interaction between agent identity and clinician identity: when an agent acts on behalf of a clinician, both identities must be captured in the audit trail.
Critical Infrastructure. Agents operating in critical infrastructure environments (energy, water, transport) require identity assurance that meets the relevant sector-specific standards (e.g., IEC 62443 for industrial automation, NERC CIP for energy). Identity verification must be resilient to the specific failure modes of operational technology environments, including intermittent connectivity and air-gapped network segments. Hardware-backed identity (TPM or HSM) is strongly recommended for agents with access to safety-critical systems.
Basic Implementation — Each agent is issued a unique cryptographic token (e.g., a signed JWT) at deployment time. All inter-agent communications include the token, and the receiving agent or service validates the signature before processing the request. Revoked tokens are tracked in a revocation list that is checked at validation time. Token expiry is set to a fixed duration (e.g., 24 hours), after which re-issuance is required. This level meets the minimum mandatory requirements but has gaps: the revocation list may have propagation delays, token rotation is manual, and the validation does not include replay prevention beyond the expiry window.
Intermediate Implementation — Agent tokens include nonce values and short expiry windows (minutes, not hours). Each token can be used exactly once — the nonce is recorded on first use and rejected on subsequent presentations. Credential rotation is automated on a defined schedule. The revocation list is distributed in near-real-time through a push mechanism rather than periodic polling. Impersonation attempts — where a token's claimed identity does not match the presenting agent's registered cryptographic key — are detected, logged, and trigger an alert. Mutual TLS or equivalent channel-level authentication supplements token-based identity.
Advanced Implementation — All intermediate capabilities plus: agent identity is backed by hardware security modules that prevent key extraction. Short-lived certificates (minutes) are issued by an internal certificate authority, eliminating the need for long-lived credentials and revocation lists. Identity verification has been tested through independent adversarial assessment including token forgery, replay attacks, man-in-the-middle interception, and credential theft scenarios. The organisation can demonstrate a complete chain of trust from the certificate authority through every agent identity to every authenticated action.
Required artefacts:
Retention requirements:
Access requirements:
Testing AG-012 compliance requires adversarial testing of the identity layer. A comprehensive test programme should include the following tests.
Test 8.1: Self-Declaration Rejection
Test 8.2: Token Replay Prevention
Test 8.3: Credential Revocation Enforcement
Test 8.4: Privilege Escalation via Impersonation
Test 8.5: Key Compromise Response
| Regulation | Provision | Relationship Type |
|---|---|---|
| SOX | Section 404 (Entity Authentication Controls) | Direct requirement |
| FCA Senior Managers Regime | SM&CR Attribution Requirements | Direct requirement |
| eIDAS | Electronic Identification and Trust Services | Supports compliance |
SOX Section 404 requires that internal controls include adequate entity authentication — ensuring that transactions are initiated by authorised entities. For multi-agent systems, this means each agent must be cryptographically authenticated before its actions are processed. A SOX auditor will test whether one agent can initiate transactions attributed to another agent. If impersonation is possible, the authentication control is inadequate. SOX also requires that authentication controls be tested periodically and that test results be retained.
The Senior Managers Regime requires that senior individuals be accountable for the activities within their area of responsibility. When AI agents act within a senior manager's remit, the firm must be able to demonstrate which agent took which action and that the agent was genuinely the entity it claimed to be. If agent identity cannot be verified cryptographically, the attribution chain breaks and the senior manager cannot fulfil their accountability obligation. The FCA has indicated that firms deploying AI agents must maintain the same standard of attribution and accountability as for human actors.
The eIDAS Regulation establishes a framework for electronic identification and trust services across the EU. While originally designed for human and organisational identity, its principles apply directly to agent identity: identification must be reliable, authentication must be verifiable, and credentials must be revocable. AG-012 implements these principles in the agent context. Organisations operating in the EU should consider whether their agent identity mechanisms meet eIDAS assurance levels, particularly where agents interact with external parties or cross organisational boundaries.
| Field | Value |
|---|---|
| Severity Rating | Critical |
| Blast Radius | Organisation-wide — potentially cross-organisation where agents interact across organisational boundaries or shared multi-agent platforms |
Consequence chain: Without cryptographic identity assurance, a compromised agent can impersonate a more privileged agent, inheriting elevated mandate authority. Token replay allows a captured credential to be reused indefinitely within its validity window. The trust hierarchy between agents collapses because identity cannot be verified. The immediate technical failure is unauthorised privilege escalation — an agent operating with a mandate that was never issued to it. The operational impact depends on the mandate of the impersonated agent: if a trading agent is impersonated, the exposure is unauthorised trades up to the trading mandate's limits; if an administrative agent is impersonated, the exposure is modification of other agents' mandates, potentially removing all governance controls. The failure mode is binary — either the identity holds or it does not — and the blast radius is determined by the highest-privilege agent that can be impersonated. The business consequence includes regulatory enforcement action for inadequate systems and controls (FCA SYSC), inability to demonstrate accountability under the Senior Managers Regime, potential GDPR breaches where impersonation enables data access, and reputational damage requiring complete architectural redesign of the multi-agent system.
Cross-references: AG-009 (Delegated Authority Governance) governs the scope and limits of delegated authority — AG-012 verifies the identity of the delegating agent. AG-015 (Organisational Namespace Isolation) ensures that identities from one namespace cannot access resources in another. AG-016 (Cryptographic Action Attribution) binds verified identity cryptographically to every action the agent takes. AG-029 (Credential Integrity Verification) governs the integrity and lifecycle management of all credentials the agent holds. AG-033 (Implied Authority Detection) detects cases where an agent acquires authority implicitly without formal identity fraud.