← All articles

Approval gates: five agent actions that should never run unattended

The Guildwise HQ team · 4 November 2026 · 5 min read

• AI agents
• How-to

Why a short, fixed list matters

Most agent tools can now pause and ask before they act. The weak point is the setting, not the feature. A team starts by gating everything, gets tired of the prompts, and adds a broad allow rule that covers more than it meant to. After a few weeks the approval step protects very little.

A fixed list avoids that drift. It is short enough to remember, and it is defined by what an action can do to people, money, data or the agent's own limits. It does not depend on how a particular task was phrased.

The list below is a practical starting point for a small team. It is not a legal standard. Where a system is regulated, the rules are stricter, and the last section covers that case.

Five actions that always need approval

1. Sending anything outside the organization

This covers emails to customers, chat messages to partners, public posts, and webhooks to third-party services. Once a message is sent, it cannot be recalled. The approval should show the exact recipient and the full text, not a summary written by the agent.

2. Deleting or overwriting data

This covers dropping tables, removing files, force-pushing a branch, purging a queue and bulk-editing records. Ask for the exact target, such as a path pattern or a filter, and the number of items it matches. If the tool supports soft delete or versioned storage, prefer that and gate only the permanent step.

3. Spending money or changing a payment setup

This covers purchases, plan upgrades, refunds, new API keys with billing attached and changes to a subscription. The approval should state the amount, the vendor and the reason. A spend cap should still apply after approval, so one yes does not open an unlimited budget.

4. Changing access or credentials

This covers creating accounts, granting roles, rotating secrets, editing CI variables and changing firewall or network rules. An agent that can grant access to itself has escalated its own permissions. Where the team is large enough, the person approving should not be the person who asked for the change.

5. Deploying to production or editing the agent's own rules

This covers production releases and changes to the files that define what the agent may do: its permission settings, its prompts, its approval list and its tool configuration. An agent that can edit its own guardrails can switch the gate off. Treat those files as code that goes through review, and do not let the agent write to them without approval.

What an approval has to show

A prompt that says only approve or reject does not give the person enough to decide. Each approval request should include:

• The exact action, with all arguments written out in full.
• The target: recipient, file path, account, database or environment.
• The agent's reason, in one sentence, and the task it belongs to.
• What happens on rejection. The agent should stop or hand the task back, not retry with a slightly different action.
• A record of who approved, when, and what was run.

For example, suppose an agent asks to delete the files matching a report folder from last quarter. A useful request reads: delete 214 files under the reports path for 2025-Q3, matched by the pattern shown, reason: the retention task in the ticket, rejection: the agent lists the files it would keep and stops. A useless request reads: clean up old reports, approve yes or no. The first lets the reviewer check the count and the path in half a minute. The second invites a yes without looking.

Where the rule should live

Do not rely on one layer. Use three.

First, the agent's own permission rules. Claude Code's permissions documentation describes allow, ask and deny rules for tool use. Use ask for the actions above that are sometimes needed, and deny for actions the agent should never take in that workspace. Keep the rules short and review them when they change.

Second, the tool wrapper. The OpenAI Agents SDK human-in-the-loop guide describes marking a tool as requiring approval, pausing the run until a person approves or rejects the call, and then resuming. Any framework that offers a similar pause can do the same job. The key property is that the run waits. A notification that arrives after the action has happened is a log, not an approval.

Third, the systems outside the agent. Database roles, cloud identity policies and repository branch protection should block the dangerous action even if the agent's own rules are wrong. The agent should not hold a credential that can do what the approval list forbids.

When the rules are legally required

If a system falls under the EU AI Act as a high-risk system, Article 14 requires that it be designed so that people can oversee it. The text asks that overseers be able to understand the system's outputs, decide not to use it in a given case, and interrupt it through a stop control or a similar procedure. Most small-team agents will not be high-risk systems, but the article is a useful design check. Ask whether a reviewer can stop the agent mid-task, and whether the stop works.

A checklist for your own gate

• List the actions in the five groups above and mark which ones your agents can reach.
• For each reachable action, choose ask, deny or hard-block, and record the choice.
• Check that every approval request shows the exact target and the agent's reason.
• Confirm that rejection stops the task and does not trigger a retry.
• Confirm that the agent cannot write to its own permission files without approval.
• Test the gate once a month with a harmless version of each action.

Key takeaways

• Keep a short, fixed list of actions that always need approval: external messages, data deletion, spending, access changes, and production or self-rule changes.
• An approval is only as good as what it shows. Show the exact action, target, reason and rejection path.
• Enforce the rule in three places: the agent's permission rules, the tool wrapper that pauses the run, and the systems the agent calls.
• Test the gate on a schedule. A gate that has never been exercised is an assumption.

This article was written with AI assistance and researched from the sources listed.

Sources

1. Claude Code permissions
2. Human-in-the-loop guide for the OpenAI Agents SDK (JavaScript)
3. Article 14: Human oversight (EU AI Act)

This article was written by an AI agent for Guildwise HQ (Guildwise blog writer, claude-haiku-5-5) and is reviewed against its sources.