Approve a high-blast-radius owner action

When dual control is on, a config change waits in the change-control inbox for a second approver. Some operations are not config changes, though. Repointing where your archives are written, removing an identity provider, retiring the break-glass token or turning dual control off are all single actions with an estate-sized blast radius, and they have their own queue: the owner-approvals inbox, at /security/owner-actions.

It works the way the change-control inbox works, deliberately, so an approver has one pattern to learn rather than two: a polled list of cards, each stating in plain words what the action does, who proposed it and when, with Approve and Reject on each. What differs is who may approve, and what “approved” means for some of them.

What waits here

Seventeen operations are gated. Each is described by its effect rather than its mechanism, because the point of the card is that an approver can read what they are authorising.

Where your archives go. Set the archive destination, add or edit one, remove one, change which is the default.

Where your telemetry goes. Set the SIEM push destination, set the OTLP metrics push destination.

Who can sign in. Add an identity-provider connection, remove one, enable or disable one.

What the engine can reach. Set the account-browsing token, change which accounts are browsed, attach a source binding to the engine.

The engine’s own code. Apply an engine update, keep a promoted engine update.

The controls themselves. Retire the break-glass token, open a support-bundle pull credential, and turn dual control off.

That last one is the important entry. Turning the gate off is itself gated by the gate, so one owner cannot quietly remove the second pair of eyes and then act alone.

Who can approve, and who cannot

Approving needs the owner capability keys.ceremony, and that capability is owner-reserved: a custom role can never hold it, however it is configured. So the approver is always an owner, and the engine enforces that on the route rather than trusting the screen.

The approver must not be the proposer. On your own proposal the Approve button is not shown at all, and the card says you proposed it and it is awaiting another owner. The rule is enforced server-side; the console hides the button so it is never a dead end you press and get refused.

The consequence worth planning for: a single-owner account cannot approve anything in this queue. If you turn dual control on with one owner, every gated action queues and none can proceed. Add the second owner before arming the gate, not after.

Reading the queue is not restricted to owners. The list is readable with downpipe.read, which every authenticated role holds, and a non-owner sees only the proposals they made themselves. That is deliberate: someone whose action is waiting should be able to see that it is waiting, and on whom, without holding the capability to approve it.

Why approving sometimes arms rather than runs

Approval does not mean the same thing for every kind, and the difference shows on the card.

For an action the engine executes itself, approving runs it there and then.

For an action that has to come back through the request that started it, approving arms it. The card then shows as armed, and it runs only when the proposer re-submits the original request with a one-shot token. Two things follow. The proposer has to come back and finish it, so an armed action is not a completed one. And an owner can still reject an armed action before it executes, which is the veto that makes the arming safe rather than a rubber stamp.

If you approve something and nothing appears to happen, an armed action awaiting its proposer is the usual reason.

An action the console cannot label

Each card’s heading comes from a fixed list of the seventeen kinds. If your engine is newer than your console, it can propose a kind this console has no label for, and the card falls back to showing the raw kind identifier with the action’s own summary.

The action is never hidden and never blank, because dropping it would be worse. But treat it as what it is: you are being asked to authorise an operation your console cannot name. The console records the mismatch as contract skew in its diagnostics, and the right response is to update the console to match the engine and then read the card again, rather than approving a heading you cannot interpret.

What the card can and cannot show you

An entry carries an id, a coarse kind, a redaction-safe summary, the proposer’s email address and a timestamp. Nothing else.

Live secrets are stripped server-side, before the listing is sent, so a destination credential or a token value never reaches this screen even for an owner. That means a card can tell you a destination is being repointed, and to where, without ever showing you the key that writes there. If you need to verify a secret’s value, that is a separate deliberate action, not something the inbox will show you in passing.

Where this fits

• Four-eyes change control is the same idea over config changes, with its own inbox.
• Dual control for restores is a third gate, binding to a restore plan rather than to a config change or an owner action. It is mandatory rather than opt-in.
• Roles and capabilities covers keys.ceremony and why it is owner-reserved.
• One Owner toggle in the Security Centre arms BOTH the config inbox and this one, so they come on together. Restore dual control is not that toggle: it is always in force and cannot be switched off, so turning dual control off here never weakens a restore.

Last updated 26 July 2026.