Action Reversibility and Settlement Integrity requires that every AI agent action has a defined, executable reversal path, and that partial execution does not leave orphaned liabilities. While other dimensions focus on preventing bad actions from occurring, AG-011 addresses the equally important question of what happens when actions fail partway through, when correct actions need to be unwound, or when retry logic creates duplicate effects in downstream systems. The protocol introduces settlement idempotency to ensure that retried actions do not double-execute, and ghost position detection to ensure that assets in transit between systems are never invisible to reconciliation. This dimension applies to all agent actions with external effects: financial transactions, data modifications, communications sent, and system changes.
Scenario A — Double Payment Through Non-Idempotent Retry: An AI agent processes supplier payments for a manufacturing company. The agent submits a payment of GBP 180,000 to a supplier's bank via API. The API returns a timeout error after 30 seconds. The agent's retry logic submits the payment again with a new request identifier (not an idempotency key). The bank processes both requests as separate payment instructions. The supplier receives GBP 360,000 — double the intended amount. The duplicate is discovered during the weekly payment reconciliation, five days later.
What went wrong: The retry mechanism did not use idempotency keys. Each submission was treated as a new, independent payment instruction. The agent had no way to determine whether the original request had been processed before retrying. Consequence: GBP 180,000 overpayment. Recovery requires the supplier's cooperation, which takes three weeks. Cash flow impact during the recovery period. The firm's auditors flag the incident as a material control weakness.
Scenario B — Ghost Position from Partial FX Settlement: An AI settlement agent executes a foreign exchange transaction: sell USD 5 million, buy EUR at the agreed rate. The sell leg executes successfully — USD 5 million is debited from the firm's USD account. The buy leg fails due to a connectivity issue with the EUR correspondent bank. The agent logs the failure and moves to the next transaction without triggering a reversal of the sell leg. The firm now has a ghost position: USD 5 million has been sold but the corresponding EUR has not been received.
What went wrong: The action was not wrapped in a saga or two-phase commit pattern. The failure of the second leg did not automatically trigger reversal of the first leg. The agent treated the two legs as independent operations rather than as an atomic composite action. Consequence: USD 5 million ghost position. FX exposure during the period between the sell and eventual resolution. Potential regulatory finding under FCA CASS rules for inadequate client asset reconciliation. Manual intervention required to resolve, which takes 48 hours due to correspondent banking timelines.
Scenario C — Cascading Rollback Failure: An AI operations agent performs a system migration: it updates a database schema, migrates data to the new format, and updates application configuration to point to the new schema. The configuration update fails. The agent triggers a rollback, but the data migration reversal handler has a bug — it restores the data to the old format but misses a newly added column, leaving records in an inconsistent state. The schema rollback then fails because the data no longer conforms to either the old or new schema.
What went wrong: The reversal handlers were defined but not tested under realistic failure conditions. The data migration reversal handler had an untested code path. The cascading failure — where one rollback failure causes subsequent rollback steps to fail — was not anticipated. Consequence: Production database in an inconsistent state requiring manual recovery. Eight hours of downtime. Data integrity issues requiring record-by-record validation. Post-incident review reveals that reversal handlers were registered but never tested through failure injection.
Scope: This dimension applies to all agent actions with external effects: financial transactions, data modifications, communications sent, and system changes. Any action that changes state outside the agent's own memory is within scope. The key criterion is external effect — if the action modifies state in a system other than the agent's own runtime context, it is within scope. This includes obvious cases like payment initiation and database writes, but also less obvious cases: sending an email (which cannot be unsent), publishing content (which may be cached or indexed), modifying a configuration file (which may immediately influence system behaviour), and calling an API that triggers downstream processing. The scope extends to composite actions where the agent orchestrates multiple steps across different systems. A single logical action from the agent's perspective may involve three, five, or ten distinct system interactions. AG-011 requires that the entire composite action be treated as a unit for reversibility purposes — either all steps complete successfully, or all completed steps are reversed. Partial completion is not an acceptable end state.
4.1. A conforming system MUST register a reversal handler for every action type before that action type is permitted for agent execution.
4.2. A conforming system MUST detect partial execution of multi-step actions and roll back all completed steps atomically — ghost positions are not permitted.
4.3. A conforming system MUST enforce settlement idempotency such that retried actions do not double-execute, using idempotency keys on all external system interactions.
4.4. A conforming system SHOULD stage reversal procedures before action execution begins, confirming the reversal path is available.
4.5. A conforming system SHOULD require elevated authorisation for actions with no reversible path, escalating per AG-019.
4.6. A conforming system SHOULD use two-phase commit patterns or saga-based compensation for cross-system actions.
4.7. A conforming system MAY implement automatic rollback triggers for actions that exceed post-execution validation criteria.
Action Reversibility and Settlement Integrity governs the recovery dimension of agent operations. While AG-001 prevents actions that exceed mandate limits, AG-011 provides the recovery mechanism when permitted actions fail during execution. The critical distinction is between recoverability and auditability. AG-006 (Tamper-Evident Record Integrity) governs whether you can prove what happened. AG-011 governs whether you can undo what happened. These are complementary but fundamentally different capabilities. A perfect audit trail of an irrecoverable failure is still an irrecoverable failure.
The protocol addresses a risk that is unique to machine-speed operations. When an agent initiates a multi-step action — for example, debiting one account, converting currency, and crediting another account — the action is not atomic from the perspective of the downstream systems. If the process fails after step two but before step three, the funds have been debited and converted but not credited. This creates a ghost position: an asset that has left one system but not arrived at another. Ghost positions are particularly dangerous because they may not appear in any single system's reconciliation — each system's books balance internally, but the overall position is inconsistent.
Settlement idempotency addresses the reality that distributed systems experience network failures, timeouts, and retries as normal operating conditions. When an agent's action request times out and the agent retries, the downstream system must recognise the retry and not double-execute. Without idempotency enforcement, every retry is a potential duplication of the original action — a double payment, a double trade, a double data modification. At machine speed, an agent might retry dozens of times in the seconds it takes a human to notice, creating exponential exposure from what appears to be a single action.
The severity of failure scales with the agent's transaction volume and the number of systems involved. An agent processing ten transactions per day across two systems has limited ghost position risk. An agent processing ten thousand transactions per day across five systems has substantial risk — and the reconciliation complexity grows combinatorially with the number of systems. Without this protocol, infrastructure failures during action execution create irrecoverable states, retry logic causes double-execution, and partial transactions leave permanent inconsistencies in downstream systems.
AG-011 establishes the concept of the reversal handler as the central recovery artefact. Before executing any action, the system must verify that a reversal handler is registered for the action type. Idempotency keys must accompany all external API calls to prevent double-execution. Two-phase commit or saga-based compensation must be used for any action that touches more than one system. A ghost position is defined as any state where an asset has been debited from one system but not credited to another.
Recommended patterns:
Anti-patterns to avoid:
Financial Services. Settlement integrity is a core regulatory requirement. FCA CASS rules require that client money and assets be reconciled at least daily. For AI agents processing financial transactions, the reversal handler registry should align with the firm's existing settlement failure procedures. Idempotency keys should be compatible with existing payment messaging standards (e.g., SWIFT unique transaction references). Ghost position detection should integrate with the firm's existing reconciliation infrastructure.
Healthcare. Reversibility in healthcare contexts includes clinical actions: medication orders, test requests, referrals, and care plan modifications. A partially executed medication change — where one medication is discontinued but the replacement is not activated — creates a patient safety risk. AG-011 requires that such composite clinical actions be treated atomically. The reversal handler for a failed medication change must restore the original medication order, and the ghost state (patient with neither old nor new medication active) must be detected and resolved in real time.
Critical Infrastructure. Actions on industrial control systems may have physical consequences that are not reversible in the software sense. Opening a valve, increasing a temperature setpoint, or activating a mechanical process may not be reversible by simply issuing the opposite command — physical systems have inertia, thermal dynamics, and mechanical constraints. AG-011 requires that reversal handlers for physical actions account for the physical reality of the system, including safe reversal sequences and confirmation that the physical state has actually returned to the pre-action condition.
Basic Implementation — The organisation has defined reversal handlers for each action type that agents can perform. Idempotency keys are included in external API calls. Partial execution is detected through post-execution reconciliation that runs on a scheduled basis (e.g., hourly or daily). Reversal procedures exist as documented runbooks that require manual execution. This level meets the minimum mandatory requirements but has operational weaknesses: the reconciliation delay means ghost positions can persist for hours before detection, manual reversal execution introduces latency and human error, and the idempotency implementation may not cover all downstream systems.
Intermediate Implementation — Reversal handlers are registered programmatically and verified at startup. Every action request is wrapped in a saga pattern or equivalent compensation mechanism that automatically detects partial completion and triggers reversal. Idempotency is enforced at both the agent layer and the downstream system layer using globally unique idempotency keys. Ghost position detection runs continuously, not on a schedule. Reversal execution is automated for all standard action types. Actions that have no automated reversal path are flagged at registration time and require elevated authorisation per AG-019. Cross-system actions use two-phase commit or equivalent coordination protocols.
Advanced Implementation — All intermediate capabilities plus: reversal handlers have been verified through chaos engineering and failure injection testing. The platform can demonstrate recovery from any single-point failure during any stage of any action type. Idempotency enforcement has been tested under concurrent load with duplicate request injection. Ghost position detection operates in real time with sub-second latency. The organisation maintains a reversal coverage matrix showing that every action type, at every stage of execution, has a tested reversal path. Settlement finality is tracked and actions that have passed the reversal window are flagged as irreversible with appropriate risk classification.
Required artefacts:
Retention requirements:
Access requirements:
Testing AG-011 compliance requires systematic failure injection across all action types and execution stages. A comprehensive test programme should include the following tests.
Test 8.1: Reversal Handler Coverage
Test 8.2: Partial Execution Rollback
Test 8.3: Idempotency Under Concurrent Retry
Test 8.4: Ghost Position Detection
Test 8.5: Reversal Execution Integrity
Test 8.6: Elevated Authorisation for Irreversible Actions
| Regulation | Provision | Relationship Type |
|---|---|---|
| FCA CASS | Client Asset Sourcebook (CASS 6, CASS 7) | Direct requirement |
| SOX | Section 404 (Internal Controls Over Financial Reporting) | Direct requirement |
| EU AI Act | Article 9 (Risk Management System) | Supports compliance |
The FCA's Client Asset Sourcebook (CASS) imposes detailed requirements on how firms hold and account for client money and assets. CASS 6 (custody rules) and CASS 7 (client money rules) require firms to maintain accurate records and perform regular reconciliations. For AI agents executing transactions involving client assets, AG-011 directly implements the controls that prevent ghost positions — situations where client assets are in transit between systems and do not appear in any single system's records.
CASS 7.15.5R requires that a firm perform internal reconciliations of client money at least every business day. An AI agent operating at machine speed can create hundreds of ghost positions between reconciliation cycles if partial execution is not detected and reversed in real time. AG-011's requirement for atomic rollback and continuous ghost position detection goes beyond the CASS minimum but reflects the operational reality of autonomous agent settlement.
Section 404 requires that internal controls ensure the completeness and accuracy of financial records. For AI agents executing financial transactions, AG-011 addresses two specific SOX control objectives: completeness (every initiated transaction is fully settled or fully reversed — no ghost positions) and accuracy (no action executes more than once due to retry duplication). A SOX auditor assessing an AI agent deployment will specifically test whether partial failures can create off-book positions and whether retry logic can create duplicate entries.
Article 9 requires risk management measures for high-risk AI systems. For AI agents executing actions with financial or operational consequences, the risk of partial execution and retry duplication is a foreseeable risk that must be mitigated. AG-011's requirements — reversal handlers, atomic rollback, and idempotency — constitute the technical risk mitigation measures for these specific risks. The regulation requires that these measures be tested, which maps to AG-011's Score 3 requirement for independent failure injection testing.
| Field | Value |
|---|---|
| Severity Rating | Critical |
| Blast Radius | Organisation-wide — potentially cross-organisation where agents settle transactions with external counterparties or shared clearing infrastructure |
Consequence chain: Without structural reversibility and settlement integrity controls, infrastructure failures during action execution create irrecoverable states, retry logic causes double-execution, and partial transactions leave permanent inconsistencies in downstream systems. The failure mode is particularly insidious because it may not be immediately visible. A ghost position — funds debited but not credited — may not appear on any single system's exception report because each system's internal records are consistent. The inconsistency exists only in the gap between systems. Detection requires cross-system reconciliation, which in many organisations runs on a daily or weekly cycle. During that gap, the exposure is invisible. At machine speed, an agent can create hundreds of ghost positions between reconciliation cycles, and each retry without idempotency doubles the exposure. The immediate technical failure is orphaned liabilities or duplicated transactions. The operational impact is financial loss, regulatory exposure under FCA CASS and SOX Section 404, and inability to demonstrate accurate records to auditors. The business consequence includes regulatory enforcement action, material financial loss from irrecoverable ghost positions, and potential personal liability for senior managers under regimes such as the FCA Senior Managers Regime.
Cross-references: AG-006 (Tamper-Evident Record Integrity) governs the immutable record of what happened, including reversals and their outcomes. AG-008 (Governance Continuity Under Failure) governs what happens to the entire governance framework under infrastructure failure, including whether reversal mechanisms remain available. AG-019 (Human Escalation & Override Triggers) defines the escalation path for actions flagged as irreversible. AG-001 (Operational Boundary Enforcement) prevents actions that exceed mandate limits; AG-011 provides the recovery mechanism when permitted actions fail during execution. AG-016 (Cryptographic Action Attribution) provides the cryptographic attribution mechanism for reversals.