Allow a high or critical risk Ability

What happens when you confirm

• The grant is applied to that agent’s matrix.
• An administrative audit event is written naming who confirmed it and when.
• The contextual risk engine continues to apply. Allow is your general decision; a specific call can still escalate to review.

Four questions before you confirm

1. Would I accept this happening unattended, at 3am, without anyone watching? If not, the correct decision is require approval, not allow.
2. Is it reversible? If not, the case for approval is much stronger regardless of how routine the action feels.
3. Is it bulk-capable? One call affecting one item and one call affecting four thousand are different decisions wearing the same name.
4. Is the result public-facing? A mistake your customers see is a different class of problem from one only you see.

The alternative that is usually better

Requiring approval keeps the workflow possible while putting judgement exactly where the consequence is. The agent still asks; a person still decides; the work still happens. What changes is that it happens with someone accountable for it.

Narrow before you grant

Often the better move is upstream: give the agent a connection user that cannot perform the dangerous variant at all, so the question never reaches policy. A ceiling you cannot misconfigure beats a permission you have to remember.

Related guides

• AuthorityRead an Ability’s risk classification

  Action, risk, reversibility, scope, bulk and exposure — what each means, and why an Ability that cannot be classified is treated as more dangerous.

• ApprovalHow an approval works

  Approvals are input-bound, single-use and time-limited. Why an approval is a decision about one request rather than a standing permission.

• RecoveryWhen an action cannot be undone

  Reversibility is a property of the action, known in advance from its classification. What to do when there is no undo, and how to avoid a repeat.