Gate High-Impact Agent Actions
Require a server-verified human decision before an agent can send, export, delete, refund, or change access.
A model can propose a refund, deletion, permission grant, data export, or outbound message. It must not decide that a person has approved the effect. The action gate belongs in the application controller or tool server, where it can classify the proposed effect and enforce policy before anything external happens. OWASP's excessive-agency guidance supports keeping this control outside model text.
Decide which actions need approval
Classify tools by consequence, not by whether an API method is named read or write. Consider financial loss, sensitive data exposure, tenant reach, external publication, reversibility, and the number of affected people. A read that exports many records may need approval; a bounded internal status read may not. Document the default for every new tool before it becomes available to an agent.
| Action class | Default | Approval trigger |
|---|---|---|
| Bounded owned read | Permit after normal authorization | None |
| Sensitive read or export | Hold | Broad scope or external destination |
| Message or publication | Hold | External recipient or public audience |
| Permission or credential change | Hold | New authority or access path |
| Destructive or financial action | Deny until enabled | Deletion, refund, payment, or bulk change |
| Unknown tool or effect | Deny | Policy owner must classify it |
Set thresholds for bulk work and rate of change. A series of small actions can have the same impact as one large action, so classify the full requested job, not only one tool call. Assign a policy owner who can approve new action classes. Do not let the model relabel an action as low risk.
Put the gate before the effect
Run the gate when the controller receives a proposed tool action, before it schedules or sends that action to an external system. The gate checks the action class, caller authorization, tenant scope, policy state, and whether the required human review occurred. If a job waits in a queue, run the gate again at worker dispatch because authority or policy may have changed. A model sentence such as "the user approved" is not evidence of human review.
The review screen should show the real effect, including recipient, target, amount, or data scope when applicable. Denial, unavailable review, or an unclassified effect must stop execution. Keep the execution path closed while the review is pending. The controller must wait for the human decision before it releases the job.
Test a bounded read that proceeds without a prompt, then a sensitive export that pauses before any transfer. Test a bulk request that crosses the threshold, a declined request, an unknown new tool, and a queued job whose caller loses access before dispatch. In each denied case, confirm that no external effect occurred. Record the policy class, gate point, decision, and result without logging private payloads.
Know what your agents can reach
Map data access, tool actions and approval boundaries before testing. Use the scope guide, or discuss a review of your AI application.