Article · Guide

Designing consent, revocation and rollback for AI agents

Authorization boundaries, irreversible actions and recovery for AI agents, worked through as state transitions using the mechanisms AXI specifies.

By Yeluri S. D. S. Sri VardhanPublished 9 October 20265 min read

An agent that can act is only as trustworthy as its rules for when it may act, how that permission ends, and what happens when permission ends halfway through a task. This article works through those rules as state transitions, using the mechanisms the AXI v2.0 paper specifies: the Consent Broker, irreversible-action confirmation, the mandate envelope and the Mandate Rollback Protocol (MRP).

These mechanisms are specified in the AXI v2.0 paper, and its conformance tests check them against event logs.

Why this is an engineering problem

In July 2025 an AI coding agent ran destructive commands that deleted a live production database, during an explicit code and action freeze and against the user’s instructions (Fortune). The operator’s response, as the AXI paper records it, was to separate development from production data and add a planning-only mode. Both are authorization boundaries that were missing before.

The lesson generalizes. Telling an agent “don’t touch production” in natural language is an instruction, not a boundary. Boundaries have to live outside the model, in a component that the model cannot talk its way past.

AXI’s Consent Broker holds records bound to a subject, purpose, scope and validity period. A record missing any of the four cannot authorize anything.

            grant (subject, purpose, scope, validity)
   (none) ───────────────────────────────────────────▶ CURRENT
                                                         │  │
                     revoke (takes effect ≤ 1 cycle) ◀───┘  └───▶ expires_at reached
                                 │                                       │
                                 ▼                                       ▼
                             REVOKED                                  EXPIRED
     revocation propagates to every record, cached permission
     and mandate listing this record in depends_on

The rule at the action boundary is short: every action event must be preceded by a Broker check that resolves to granted, current and granular, or the action does not execute. The paper adds three points that are easy to get wrong:

Revocation has a deadline. It must take effect within one Bridge cycle (100 ms p95 in the paper’s budget), not “at the next session”. Cached permissions are the usual culprit.
Revocation cascades. Records declare dependencies; revoking a parent invalidates everything that depends on it, including mandates.
Consent to process data is not authorization to act. One click can create both, but they are separate records with separate lifecycles. And a biometric confirmation proves who agreed, not that they were informed.

A minimal broker check, as an illustration (not a reference implementation):

const CYCLE_MS = 100;

function mayAct(records, { subject, purpose, scope }, now) {
  return records.some((r) =>
    r.subject === subject && r.purpose === purpose && r.scope === scope &&
    r.granted && r.granular &&
    (r.expires_at == null || now < r.expires_at) &&
    (r.revoked_at == null || now <= r.revoked_at + CYCLE_MS));
}
// Fail closed: if the broker is unreachable, the answer is "no".

Conformance tests C-01 (no action without a current record; refusal logged) and C-02 (revocation honoured within one cycle) check exactly this. Both can be checked on your own event logs recorded in the conformance trace format.

State machine 2: an irreversible action

Some actions cannot be undone: dropping a table, sending money, issuing a ticket. AXI requires that irreversible actions halt output, show the intended action, and wait for an explicit confirmation that is recorded before execution (conformance test C-03).

 PROPOSED ──▶ INTENT_SHOWN ──▶ AWAITING_CONFIRMATION ──confirm──▶ EXECUTING ──▶ COMMITTED
                                       │
                                       └──decline / timeout──▶ CANCELLED (logged)

Three design choices make this work in practice:

Make the intent concrete. “Drop table users (48,210 rows) in production. This cannot be undone.” beats “Proceed with cleanup?”. The user is confirming an action, not a mood.
Make the confirmation specific. Ask for a phrase that names the action, not a generic “yes”, so a reflexive approval does not authorize something unexpected.
Re-query irreversibility at each step. Some flows become irreversible partway through, for example when a ticket is issued. AXI asks such flows to expose a current_irreversibility_class that the Bridge checks before every sub-step.

State machine 3: a delegated mandate

Background agents act while their principal is absent (“book my flights while I sleep”). AXI handles this with a mandate envelope: a signed, non-repudiable grant listing allowed action classes (purchase:airline_ticket), hard bounds (never above $1,500), notification triggers and a duration. The idea generalizes to every action class what the Agent Payments Protocol does for payments.

Outside the envelope, the action does not execute and the principal is notified (conformance test C-04). Inside it, the agent proceeds. The harder question is what happens when the envelope stops being valid mid-task.

The Mandate Rollback Protocol

When a mandate expires or is revoked while an action is running, the Bridge:

checks whether the action is at an atomic safe point;
if not, allows a grace period (default 300 s) to reach one;
if none is reached, invokes registered rollback handlers, or for irreversible classes records the inconsistent state as a high-priority Trust Ledger entry;
notifies the user on next contact.

 RUNNING ──mandate ends──▶ SAFE_POINT_CHECK ──at safe point──▶ STOPPED ──▶ NOTIFIED
                                  │
                                  └─not at safe point─▶ GRACE (≤ 300 s) ──reached──▶ STOPPED ──▶ NOTIFIED
                                                              │
                                                              └─timeout─▶ ROLLBACK or LEDGER_INCONSISTENT ──▶ NOTIFIED

The most common bug this catches is the agent simply finishing the task after its permission ended.

The paper names three edge cases worth designing for up front:

Cascading mandates. Revoking a parent terminates its sub-mandates, and a sub-mandate may never exceed its parent’s scope. This matters as soon as agents delegate to other agents.
Safety-critical mandates. Where stopping would itself cause harm (monitoring a medical device), termination is blocked until a successor mandate exists or a human accepts handoff.
Rollback can fail too. Document, per mandate class, the safe points, rollback handlers, irreversibility transitions and how rollback itself fails.

What a mandate is not

The paper is careful here, and implementers should be too. The mandate envelope is an experience-and-accountability construct, not a security control. An agent whose instructions are hijacked through prompt injection can act against its principal while staying inside a perfectly valid mandate. Build envelopes on authenticated-delegation infrastructure (South et al., 2025) and deploy them alongside defences against prompt injection and excessive agency (OWASP).

Testing it

Log the events the state machines above produce, then check them. The conformance trace format covers consent, revoke, action, intent_shown, confirmation, mandate, action_started, mandate_revoked and the MRP steps; the docs list every field. A trace like this fails C-02 because an action executes four seconds after revocation:

{ "events": [
  { "t": 0,    "type": "consent", "id": "c1", "scope": "calendar.write", "granted": true, "granular": true },
  { "t": 5000, "type": "revoke",  "consent": "c1" },
  { "t": 9000, "type": "action",  "id": "a2", "scope": "calendar.write", "executed": true }
] }

Specified and implemented

Mechanism	Specified in AXI v2.0	Open implementation
Consent gate and revocation	Yes (§4.3.6)	Trace checker (C-01, C-02)
Irreversible-action confirmation	Yes (§4.2, C-03)	Trace checker (C-03)
Mandate envelope	Yes (§4.6)	Trace checker (C-04)
Mandate Rollback Protocol	Yes (§4.6)	Trace checker (C-05)
Action-gateway interlock	Yes (§4.3.1, C-10)	Trace checker (C-10)

The checkers verify that a log is consistent with the rules. The evidence page covers how these mechanisms map to documented real-world failures.

Sources

Related on this site

The AXI Bridge specification
Deception Guardrails and conformance tests
Developer docs
AXI v2.0 paper, §4.3.6, §4.6, Appendix C: full text · DOI 10.21203/rs.3.rs-9717445/v2