Dual Control for Model Actions That Can Move Money or Change Policy

Banks already know dual control. Two keys on a vault. Two signatures on a payment. Two people to change a production firewall rule. Then a model arrives, and the same institution lets a single operator publish a prompt that rewrites how contracts are redlined.

We refused that split. If an action can move money, notify a counterparty, change a limit, or alter the policy that governs future invocations, Eridian requires two named humans. The model does not count as a human.

What counts as a high-risk action

We classify actions at the workflow node, not at the chat window.

• Publish or roll back a prompt template version
• Edit a routing chain or residency pin
• Raise a workflow cost envelope above the project soft cap
• Resume a paused legal or risk run after a human gate
• Export raw (non-redacted) invocation payloads
• Purge records inside a retention hold
• Bind a production project to a new model that is not on the approved list

These are gateway checks. A compromised session that can call the API still cannot complete them alone.

{
  "dual_control": {
    "action": "template.publish",
    "requester": "usr_legal_ops_04",
    "approver": "usr_gc_deputy",
    "window_minutes": 30,
    "binding": "this_version_only"
  }
}

Approvals are single-use. They expire. They bind to a content hash of the change. Approving "whatever is in staging" is not a control.

The model never approves

We have been asked, more than once, to let a second model act as the second key. The answer is no. A model can draft the change request. A model can summarize the diff for the approver. A model cannot satisfy dual control.

That is not a philosophical position. It is an examination position. A supervisor who asks "who approved this template" is entitled to two staff identifiers, two timestamps, and a hash. "The reviewer agent agreed" is not an answer we will put in a pack.

Failure mode we already saw

An early design allowed project admins to disable dual control for "developer convenience" on non-prod. One institution copied a production template into a workspace where dual control was off, published a change, then promoted the template ID back. We closed that path. Promotion into production re-checks the action class. The origin workspace's flags do not travel.

If you need speed, shorten the approval window and staff the second key. Do not turn the control off and hope the audit trail looks the same.