Glossary entry

What is a human veto button?

A human veto button is a deliberate control point in an AI agent's execution path that lets a designated person stop an action before it runs. Policy decides when the button is offered; the human decides whether the action proceeds. The button is the difference between an agent acting and an agent asking permission.

Key facts

  • Triggers on policy-defined high-impact actions, not on each governed tool call.
  • Fits teams running production agents that touch money, identity, infrastructure, or external recipients.
  • Without it, review-required actions execute as soon as the model decides to call them, with no second pair of eyes.
  • Veto delivers the veto button through the workspace, configured approval channel, or webhook destination.

In plain English

Most agent actions should not need a human. They are reads, lookups, calculations, low-stakes writes. A small percentage are different: wire transfers, deletes against production, emails to external recipients, schema migrations. For those, human review is the control. The veto button makes that review executable before the action runs.

The button is named after what it does. The agent proposes the action; the human can veto it. If the human approves, the action proceeds. If they deny, it stops with a structured reason that the agent can use to plan its next step. If they ignore it past a timeout, the action auto-denies and the agent moves on.

How it works

Mechanically, the button is a policy outcome. A YAML rule says require_approval for the matching action. When that outcome fires, Veto creates an approval request, posts it to the configured channels with the agent identity, the tool, the arguments, and the rule that matched. The agent waits on a long-poll or webhook until the approver responds, then proceeds.

The user experience for the approver is intentionally narrow: see the action, see the context, hit approve or deny. The decision is recorded with reviewable provenance: who approved it, when, the policy snapshot at that moment, the decision context. Review teams get the decision records without doing anything special.

# YAML: a veto button for outbound payments
- name: payment_requires_human_approval
  match:
    tool: payment.send
  rules:
    - if: args.amount_cents > 25000
      then: require_approval
    - if: args.recipient_country not in trusted_countries
      then: require_approval

Operational consequence

The textbook reason is destructive execution during a freeze. A veto button on schema-modifying SQL forces the agent to propose DROP TABLE before execution, gives a human the decision context, and preserves the denial as evidence. The button is an execution boundary, not a prompt reminder.

The veto button also creates evidence for EU AI Act Article 14 ("effective human oversight") and the OWASP LLM06 mitigation that calls for human review for high-impact actions. Both frameworks want a checkable claim: when does a person see the agent's actions? The veto button gives a concrete answer: when policy says they do.

Related terms

Pre-Action Approval

The wider pattern the veto button implements.

Maker-Checker for AI

The banking pattern the veto button borrows from.

AI agent guardrails

The broader category of agent oversight tooling.

EU AI Act evidence

Article 14 asks for effective human oversight. The veto button is one concrete implementation.

FAQ

Is the human veto button the same as a kill switch?⌄

Related but different. A kill switch stops the whole system. A human veto button stops a specific action before it executes. The kill switch is for emergencies; the veto button is for routine sensitive operations where a human should sign off.

Will not constant approvals slow my agent to a crawl?⌄

Only if you wire it up wrong. The veto button should fire on actions whose impact justifies human review. Veto policies say which calls require approval; everything else stays on the automatic path.

Where does the approval happen?⌄

Wherever your team works. Veto pushes approval requests to the configured channel, workspace, or webhook target. The approver sees the agent, the tool, the arguments, the policy that triggered the gate, and the decision controls.

What if the approver is offline?⌄

You set the timeout. If nobody responds within the window, the call either auto-denies, escalates to a backup approver, or queues for later. Teams default to auto-deny because doing nothing is the default-deny option for a side-effecting action.

Put a veto button on the actions that deserve one.

Sign upInstall the SDK