Human approval checkpoints
Who may approve this particular mutation?
An approver role is often too broad on its own. Check the target, operation, organisational scope and any separation-of-duties rule for the actual proposal.
In this article
Start with the proposal's consequence
A team lead may approve a delivery-note change for their team's orders but not a refund or another region's account update. Model approval authority around the operation and target rather than treating every decision as equivalent.
Resolve the target's organisation and ownership from trusted records. The proposal may contain identifiers, but it should not define its own authority scope. An attacker or mistaken model should not be able to label a target as belonging to the approver's team.
Document whether the requester can approve their own proposal. If the business requires a second person, enforce that rule on the server using authenticated identities.
Check authority when the decision is made
Load current reviewer permissions at the decision endpoint. Hiding an approval button from unauthorised users is useful interface behaviour, but it does not secure the endpoint.
If approval links are sent through notifications, ensure the link identifies the proposal without acting as unrestricted authority to approve it. The recipient should authenticate and satisfy the same policy as someone opening the review screen directly.
Consider delegated or temporary authority explicitly. Record its scope and expiry so a decision can be explained later. Avoid a broad shared reviewer account that makes it impossible to identify the person responsible.
Limit what the reviewer can inspect
Reviewers need enough evidence to make the decision, but approval access should not automatically expose unrelated source material or the entire conversation. Show the target, proposed effect and relevant supporting information.
Where the proposal includes sensitive attachments, verify that the reviewer may read them. If they cannot, the workflow needs a suitable reviewer or a different evidence package. A person cannot meaningfully approve hidden consequences merely because the button is available.
Protect decision history as well. It may reveal business relationships or personal details even when the main proposal view has been restricted.
Revisit authority before delayed execution
Define whether a decision remains valid after a role change or long delay. For some workflows, the authority at decision time is sufficient. Others require a current check at execution. The policy should be explicit and reflected in tests.
Exercise cross-team targets, self-approval, expired delegation and a revoked reviewer role. Inspect the saved decision and final mutation. A dependable approval system can explain why this person was allowed to authorise this action on this record, rather than merely showing that someone with a generic role clicked approve.
Primary sources
OWASP: authorisation guidanceOWASP: transaction authorisationReferences checked 11 September 2026.