Two People for the Irreversible

Before the detail — Artifact: two tokens on two keys, bound to one plan, refused as a pair the moment either is missing or both share a key. Status of what follows: binding, enforced in code rather than left to a reviewer’s judgment call.

Prompt first: count credentials, not approvals

List every action in your own agent's plan that would be genuinely
unrecoverable if it ran on bad input - not "annoying to fix," no
inverse at any price. For each one, answer:
  1. Does anything today require two DIFFERENT people to authorize
     it, or does one approval - one click, one "yes" in chat - let
     it proceed?
  2. If two approvals are required, are they checked against two
     distinct credentials, or could the same person hold both
     without anyone noticing?
Name the action that fails question 1 first. That is the one worth
fixing before any of the others.

An assistant can enumerate the actions and draft the two questions. It cannot tell you whether the “second approval” on file today is a second person or the same person’s second login — that fact lives in whoever issues the credentials.

One approval is not enough, whatever it says

MU-AI-011 (Meridian’s crew-dispatch agent)‘s committed nine-call run reaches exactly this moment at call six: crews are staged, the operator wants the dispatch notice sent, and one approval has been obtained. The guard’s own line is unambiguous: “‘send_dispatch_notice’ is class=irreversible and needs 2 valid approval(s) from 2 different people signed with 2 distinct keys; 1 person(s) (p.velasquez) and 1 key(s) (a) presented.” The request is refused, exit 4, before the notice reaches a single handset. The approval that was presented is not defective — it is valid, current, and bound to the right plan. It is simply one, and the envelope declared this action needs two before it means anything.

That refusal is not a special case bolted onto one action. It is what the class “irreversible” means in this training’s own register: no inverse exists, so the only thing standing between a mistake and a crew standing in the wrong place is agreement between two people who cannot both be one person. An irreversible action that only ever asks one person is an irreversible action with a single point of failure.

Two names on one key is one approver, not two

The deeper trap is a second signature that looks like a fix and is not one. If both tokens are signed with the same key, the approval tool itself refuses to produce them: “refused: both tokens would be signed with key ‘a’. Two tokens from one key are one key holder, whatever names are typed on them — distinct keys stand in for distinct authenticated people here.” That refusal happens before a bad bundle can even be minted. But the training does not rest on the issuing tool’s good behavior alone — a fixture built specifically to sign whatever it is told, bypassing that check, exists to prove the guard makes the same call independently at execution time: two approver names bound to one signing key is still refused, exit 4, because the guard counts keys, not names typed into a form.

Distinct keys stand in for distinct authenticated people — whether a key really belongs to the person named on it is Zero Trust 2.4’s subject, a separate training in this series. This lesson owns only the execution-time check that two approvals trace to two credentials.

The signed register row

Every irreversible action in this training’s policy file carries a row that answers the same five questions a compliance reviewer will ask: what the action is, what class it belongs to, whether an inverse exists, how many signers it needs, and who is accountable for the agent at all. For the dispatch notice, that row reads:

verb          send_dispatch_notice
class         irreversible
compensator   none declared
signers       2, on 2 distinct keys
autonomy      L0-never-autonomous
zone          it-data
owner         Distribution Operations (Mgr. L. Tran)

This row is not new work invented for this lesson — 1.3’s rule: classify before the first run built the register this row lives in, and every entry in it answers to the same named owner. What is new here is what the row is for: it is the artifact a reviewer opens to answer “does this action require two-person authorization” without reading a line of code. The policy names an accountable owner, but this lab does not implement a separate owner signature on the register and should not describe the row as cryptographically signed. An ownerless handoff is refused at STEP 0 with exit 2 and writes a prerequisite-refused receipt routing the request back to AI Assurance.

The seam: two keys, then a change-authorization standard

The commercial starting practice is two approval tokens from distinct signing keys, checked before an irreversible action executes. The federal delta is North American Electric Reliability Corporation CIP-010-4 R1.2, which applies to covered baseline changes on applicable High- and Medium-Impact Bulk Electric System Cyber Systems and associated systems and requires organizations in that population to “authorize and document changes that deviate from the existing baseline configuration,” with evidence including “electronic authorization (performed by the individual or group with the authority to authorize the change).” The handoff artifact is the register row, which supports evidence for CM-3 — the change-control family covering approval, documentation, and retained decisions — by naming an owner and signer count; it does not satisfy that control or authorize a grid-system change. What is not equivalent: a single-use action approval is not that baseline-change authorization. This training’s seventh invariant denies operational-technology zones, Zero Trust 3.4’s rule for those zones is “fence it, don’t patch it,” and Guarded Automation stops at the information-technology/data-zone boundary.

Stop and escalate when a two-person requirement is satisfied by anything short of two distinct keys behind two separately authenticated people — a shared account, a delegated login, or a second click from the same session does not count, whatever the receipt’s name field says. Route the exception to the accountable owner.

Practice status — authorizing an irreversible agent action, commercial and federal

Scale: required | common baseline | strong optional | reference-shop (seen only at organizations that publish their own practice) | emerging

Key takeaway

An irreversible action gets two signatures from two distinct keys or it does not run — one valid approval is refused by name, and two names sharing a key are refused by name too, because the guard counts credentials, not text fields. The register row that proves this exists is real evidence for a change-authorization control, and it is not a substitute for one on a system CIP-010 actually governs — this training never reaches that system at all. The next module picks up where a signed approval starts: how long it lives, and what makes it stop being good.

LEADERSHIP DECISION   every irreversible action requires two
                      approvals from two distinct signing keys,
                      enforced in code, with no shared-key exception
PRACTITIONER ACTION   issue approving roles their own key material,
                      never a second login to a shared key, and keep
                      the register row current per action class
SUCCESS MEASURE       zero irreversible actions in the receipt chain
                      with a single approver or a shared-key pair -
                      audit finding avoided