Governance

Approvals

This is one policy kind in the ADR-014 governance engine. Policies resolve most-specific-wins with deny-wins at a tie, across scopes that run agent → user/role → workspace → team → org. Rules of the same kind combine rather than replace, so what matters is which rules exist, not which policy row holds them.

What it does

An approval policy makes a tool call wait for a human. When an agent reaches a write-tagged or destructive operation, the run parks at awaiting_approval and a card appears in the inbox (and in Slack/Teams, if connected). Approve and the run resumes and executes exactly once; deny and the model gets a tool error it can react to.

Additive over the baseline

Writes need confirmation by default. An approval policy is additive over that baseline — it can require approval for more, never quietly remove the baseline for a destructive action.

Edit before approve, and bulk

An approver can edit the tool's arguments before approving; the run executes the edited arguments exactly once, and both the original and the edit are audited. Approvals can be actioned in bulk, and a stale one in a batch conflicts in place rather than failing the whole set.

Resume is exactly-once A parked run serializes its loop state. Approve, deny, a TTL expiry, or an agent kill each resolve it once — a double click can never execute a write twice.