The approval design post built the model. The refund walkthrough showed it on real screens. Both rest on three properties.
The approval survives a restart. What was reviewed is what runs. The requester cannot approve. This post shows how to configure them and where they break down.
An Approval That Survives the Wait
Teams hold pending approvals in memory. That is the common mistake. A high-risk case can wait hours or days for approval.
A deploy, a crash, or a slow reviewer can outlast the worker process. Then the control fails. A durable workflow holds the pending action across the gap.
The dangerous gap is between approval and execution. A durable workflow holds the pending action across that gap. The decisive check happens on resume, not on click.
That check runs on resume, not on click. Token status, scope, policy, and the target object version can shift between approval and execution. A stale approval looks controlled but no longer matches reality.
That is why approvals should be short-lived. A 24-hour expiry is not bureaucracy. It limits how far reality can drift.
The same configuration supports per-action overrides. A credit and a refund under one plugin can carry different expiries and reviewer rules. No separate integrations are required.
The Requester Cannot Approve Their Own Request
Maker-checker (two-person review) must be enforced by the system, not remembered by the reviewer. In Cedar, it takes a few lines:
forbid(
principal,
action == Action::"approve_refund",
resource
)
when {
principal == resource.requestedBy
};
A system that cannot express "the person who proposed this cannot approve it" lacks a two-person review. It has a confirmation dialog with extra steps.
The same policy layer can require a specific role when an amount crosses a threshold. It can deny entire classes of requests before any human sees them.
Policy is the cheap, deterministic filter. Run it before the expensive one.
An Action You Have Not Named Is an Action You Cannot Gate
Everything above assumes the action exists as a named, controlled integration. Most do not ship that way. Plugins are how the action surface grows.
Each one adds an external effect: a refund, a customer message, an access change. The effect passes through the same role, policy, and approval checks.
A plugin is a contract, not scattered code. You, your technical team, or a coding agent can add a new high-risk action against that contract. It inherits the two-person review model the moment it is registered.
The detail of writing one (auth modes, health check, request and response shapes) is its own subject. Extensibility and control are not in tension when the extension point is the action itself.
The control does not care which model proposed the action, or whether it runs in your cloud or on-prem. The agent, the integration, and the deployment can each change without touching the control.
Measure the Gate, Not the Latency
Most teams track approval latency and approval rate. Then they stop. Neither metric tells you whether the control works.
Track these instead:
- Count high-impact actions that skipped the right checkpoint.
- Track reviewer acceptance rate. It is a fatigue signal.
- Track edit and reject rate. This is proof the review is real.
- Log revalidation failures on resume.
- Count approved actions that still caused harm.
The two that matter: the escape rate and the human cost per thousand reviewed actions. Everything else explains why they moved.
Three Problems Still Have No Clean Answer
This series kept to the tractable case: one action, one reviewer. That covers a lot of real risk. Three problems are still open.
The first is multi-agent delegation. When one agent hands work to another, the original intent, authority boundary, and approval evidence must travel with the case. The handoff cannot create a confused deputy or a hidden escalation path. Most controls are local to a single action.
The second is portable approval evidence. Tools, policy engines, workflow systems, and plugin transports each hold part of the approval meaning.
One holds who can approve. Another holds what can be edited. Another holds how long an approval stays valid. Another holds what must be revalidated.
No shared standard carries that meaning across tools.
The third is proving the reviewed action equals the executed action at scale. The simple version is a payload dialog. The hard version involves canonicalisation, hidden defaults, target-version drift, and side effects from steps that run before the checkpoint.
The operating principle holds across all three posts. Shrink the surface first. Gate what survives. Make every gated decision reconstructible.
Give the reviewer the exact payload. Keep the approval durable and short-lived. Separate the requester from the approver. Keep the request, the decision, and the execution on one case record.
That is the difference between a control that holds up in an audit and a button that means nothing.