What is pre-action approval?
Pre-action approval is the pattern where policy can hold an AI agent action before it executes and route the proposed call to a human reviewer for approve-or-deny. It is the operational form of the human-review principle, and a direct way to create evidence for OWASP LLM06's autonomy guidance and EU AI Act Article 14's oversight requirement.
Key facts
- Triggers on policy rules, so only the actions you mark high-impact pause.
- Fits teams running production agents with side-effecting tools they cannot afford to misuse.
- Without it, review-required actions execute as soon as the model decides on them, with no second pair of eyes.
- Veto routes pending approvals to the workspace, configured approval channel, or webhook, and logs the approver's identity on governed decisions.
In plain English
Some actions are too consequential to let an agent execute on its own: a large wire, a user account deletion, a schema migration, or an outbound email to an external auditor with attached financial data. The pre-action approval pattern keeps routine actions automatic and routes consequential actions to a human.
The reviewer's job is narrow and concrete: look at the proposed action, decide if it is right. They do not have to understand the whole agent loop, only the specific tool call. The user experience is the same as approving a deploy or merging a PR: short context, short decision.
How it works
The execution path runs through Veto's policy decision point. When a rule returns require_approval, the SDK pauses the call, creates an approval request with the decision context, and notifies the configured channels. The agent waits: synchronously if the request is short, or via callback for longer-running workflows. Once a human responds, the SDK resumes and either runs the tool or returns a structured deny to the agent.
Timeouts matter. Teams default to auto-deny after a configurable window: typically 5 to 30 minutes, because doing nothing is the default-deny option for a side-effecting action. The timeout, the approver, the rule that fired, and the final decision are recorded together.
# YAML: pre-action approval rules
- name: external_email_requires_approval
match:
tool: send_email
rules:
- if: not args.to.endswith("@approved.example")
then: require_approval
timeout_seconds: 600
on_timeout: denyOperational consequence
Destructive operations land when nothing in the agent's path requires human review before execution. Pre-action approval is the structural fix: the agent proposes the action, policy decides whether a person must review it, and the final outcome is recorded before execution. The same pattern pauses the action based on policy, approver identity, and approval outcome.
Regulators have settled on this pattern under different names. EU AI Act Article 14 calls for "effective human oversight." NIST AI RMF MANAGE-2.3 expects human authorization for material AI decisions. OWASP LLM06 mitigation explicitly recommends human review for high-impact actions. All three map onto pre-action approval queues with auditable approver identity.
Related terms
FAQ
How is pre-action approval different from logging?⌄
Logging tells you what happened after the fact. Pre-action approval decides before it happens. If you only have logs, your investigation starts after the destructive action shipped. If you have pre-action approval, the action pauses and a human can say no.
Does not this make agents synchronous and slow?⌄
Only for the calls that hit the gate. The gate fires on policy, so it triggers on the actions you decided are worth a glance. Non-gated actions flow without waiting. For gated calls, the agent waits on a long-poll, websocket, or webhook callback.
What does the approver see?⌄
The agent identity, the tool name, the arguments, the policy rule that triggered the gate, and any context the agent attached (the reason, the user it is acting on behalf of, the prior tool calls). Plus approve and deny buttons, and a free-text field for the deny reason.
Can the policy approve automatically?⌄
Yes, if you write rules that do. require_approval is the manual outcome. allow_if_recently_approved is a common variant: the agent can act on its own if a human recently approved a similar action. The policy file expresses both.
Gate the actions that need human review before execution.