AI agent approval workflows require a human to review and authorise an agent action before execution when the action meets a defined risk condition. They are useful when an autonomous agent can make decisions that have financial, operational, legal, security or reputational consequences.
FirstHelm implements approval gates as constraints. When an agent proposes a gated action, execution pauses and an approval request is presented to an authorised operator. The operator can approve, reject, or edit and approve the request. The decision, identity, timestamp and relevant action information are recorded in the activity history for later review and audit.
What Is an AI Agent Approval Workflow?
An AI agent approval workflow is a runtime process that holds an agent's proposed action until a human with the right authority reviews it and explicitly authorises it.
The mechanism has three moving parts:
- The gate: a rule that marks certain actions as requiring approval before execution.
- The request: the information an approver needs to make an informed decision — which agent, which mission, what action, why it was proposed, which rule triggered the hold.
- The decision: an explicit approve, reject, or edit-and-approve, recorded with the approver's identity and timestamp.
Approval workflows are what make human-in-the-loop oversight operational. Without them, "a human reviews important actions" is a policy statement; with them, the agent physically cannot proceed until a person decides.
When Should an Agent Require Approval?
Not everything should be gated. Approval works best when it is targeted at actions where human judgement genuinely adds value. Common triggers:
- Financial thresholds: transactions or refunds above a defined amount.
- Irreversibility: actions that cannot easily be undone, such as deletions or external communications.
- External impact: anything that reaches customers, suppliers, regulators or the public.
- Data sensitivity: access or transmission of regulated, confidential or personal data.
- Production systems: changes to infrastructure, security configuration or business-critical records.
- Novelty: actions outside the agent's demonstrated, trusted pattern, such as a new vendor, new recipient or unusual tool use.
- Policy exceptions: situations the agent itself flags as outside its normal operating rules.
Conversely, low-risk, reversible, internal actions are usually better left automatic. Gating everything produces approval fatigue, where humans rubber-stamp requests without reading them — which is worse than no gate at all, because it creates the appearance of oversight.
Approval Gates
An approval gate is the technical rule that pauses execution. In practice a gate is a specialised constraint: instead of allowing or blocking an action outright, it suspends it pending review.
A gate evaluates the proposed action against its conditions — amount, action type, destination, data class, tool, timing — and if the conditions match, the action enters a pending state rather than executing.
Three properties matter:
- Gates are evaluated at runtime, not at design time. The rule fires on the action the agent actually proposed, not the one you expected it to propose.
- Gates hold execution, not just warn. A gated action cannot complete while it is pending.
- Gate decisions are recorded. Every evaluation — matched or not — leaves a trail.
Risk Thresholds
Risk thresholds turn approval from a binary on/off into a graduated control system. A common pattern:
Thresholds are usually expressed in the dimensions that matter to your business: money (£500, £5,000), volume (requests per hour), data (any record flagged restricted), blast radius (production vs staging), or timing (outside maintenance windows).
The right threshold is an organisational judgement, not a technical one: set it where the cost of a wrong action exceeds the cost of a human's attention.
Approve, Reject or Edit
A well-designed approval workflow gives the human three meaningful options, not one:
- Approve: the action proceeds as proposed.
- Reject: the action does not proceed, and the agent learns the outcome so it can adapt its plan.
- Edit and approve: the approver modifies the action (for example, reduces a payment amount) and approves the corrected version. This is often the most valuable option: the human doesn't just say yes or no, they steer.
The reject path deserves design attention. What should the agent do — retry with modifications, escalate to a person, or stop the mission? Deciding this in advance prevents an agent from endlessly re-proposing a rejected action.
Approval Timeouts
What happens when nobody is watching? An approval request that waits forever is a silent failure mode — the mission stalls and nobody knows.
Mature workflows define a timeout policy:
- Escalation: after N minutes, notify a second approver or a channel.
- Default-deny: after the timeout, the action is rejected and the agent is informed.
- Default-approve: for carefully chosen low-risk gates only, and rarely advisable.
Default-deny is the safest general policy: an organisation that was going to allow consequential actions unattended should not have gated them.
Approval Permissions
Who can approve what? Approvals should follow least privilege too:
- Approvers are authorised per agent, per action type or per risk tier — not a single global "approver" role that can authorise anything.
- The set of approvers is small enough that responsibility is real.
- Approvers can see the action's full context, but cannot edit the underlying policy from the approval screen (separation of duties).
- Some organisations require two-person approval for the highest tier — proposed by one operator, authorised by another.
Approval Audit Trails
Every approval decision — approved, rejected, edited, expired — should be recorded with:
- which agent and mission
- the proposed action and its parameters
- the rule that triggered the gate
- who decided and when
- what the approver changed if they edited
- the outcome of the action after release
This record is what an auditor or investigator later uses to answer "who authorised this?" It is also what makes approvals count as evidence of human oversight under frameworks that expect it.
Designing Safe Approval Workflows
- Gate by consequence, not by fear: target actions where judgement matters.
- Give approvers context, not just buttons — mission, reasoning, rule, impact.
- Keep request volume low enough that each one gets real attention.
- Define timeout and escalation behaviour before the first gate fires.
- Revisit thresholds as agents prove reliable: autonomy should be earned.
- Record everything, and make the records exportable.
Example Agent Approval Workflow
An operations agent with payment authority:
- Agent proposes a £2,300 payment to a new vendor.
- Gate matches: amount > £1,000 and vendor is new.
- Execution pauses; a request goes to the on-duty operator showing agent, mission, payee, amount and triggering rules.
- Operator verifies the vendor, edits the amount to £2,150 (matched invoice), approves.
- Payment executes; the edit, the decision and the approver's identity are recorded.
- The next monthly audit export shows the full chain: proposed → gated → edited → approved → executed.
Total human time: ninety seconds. Control retained: complete.
Frequently asked questions
Q: How do I require human approval before an AI agent acts?
A: Define an approval gate on the action type or threshold, so that when the agent proposes a matching action, execution pauses until an authorised approver decides.
Q: How do approval gates work?
A: A gate is a runtime rule that suspends a proposed action, presents it to an approver with full context, and only executes on an explicit decision. Every evaluation and decision is recorded.
Q: How can I put a human in the loop?
A: Risk-based approval gates: automate low-risk actions, gate the consequential ones, and record every decision. Human attention goes where judgement matters.
Q: Can AI agents ask for permission?
A: Yes — agents can be designed to request approval when they encounter ambiguity or situations outside their rules, in addition to hard gates that pause them automatically.
Q: How do I approve AI agent actions?
A: Through an approval inbox or request that shows the agent, mission, proposed action, triggering rule and potential impact, with approve, reject and edit options — every decision logged.
Q: What happens if no one approves a request?
A: Define a timeout policy before deployment: escalate to another approver, then default to deny. Never let requests wait silently.
Q: How do I avoid approval fatigue?
A: Gate fewer, better-chosen actions. Volume is the enemy of attention: if approvers stop reading requests, the gate is decorative.
Keep humans where judgement matters
Approval workflows are the operational core of human-in-the-loop AI. They let agents do real work autonomously while keeping a named human's decision — and identity — attached to every consequential action.
Done well, they are cheap: a handful of well-placed gates, good context, and clean records. Done badly — everything gated, nothing explained — they become a rubber stamp that adds latency and proves nothing.
See FirstHelm, the docs, pricing and compliance.