What is an agent approval policy?

An agent approval policy is the list of everything an agent may do. Each item gets one of three outcomes: go ahead, wait for a named person, or never. Most companies have a paragraph that says "a human reviews high-risk decisions". That's a principle. A policy is something the system can check before the action runs.

/01The three outcomes

Every action an agent can take ends up in one of three columns.

• Proceed. The agent acts. The record shows which rule allowed it. A supplier invoice matched to a purchase order and a goods receipt, all three within tolerance, is a typical proceed.
• Hold. The agent stops. It packages the evidence and sends it to one named person. That person approves or declines. An invoice where the supplier's bank details changed last week is a typical hold.
• Refuse. The agent may not do this at all, whoever asks. Adding a new supplier to the vendor master is a common refuse for an AP agent. That job belongs to someone else.

The third column is the one teams skip. It does the most work. Every refusal in the record is proof the boundary exists.

/02Write it per action, not per agent

"The AP agent needs approval above 10,000" sounds like a policy. It leaves out almost everything. The agent reads invoices. Matches them. Flags exceptions. Drafts emails to suppliers. Schedules payments. Each carries a different risk.

A usable policy is a table with one row per action. An illustrative version for an accounts payable agent:

Thresholds are illustrative. Yours come from your own delegation of authority.

Two things fall out of writing it this way. First, the same action can land in different columns depending on the facts. That's the whole point. Second, it surfaces actions nobody decided about. Can the agent send email? Then someone has to decide what it may say. And to whom.

/03What every hold rule needs

A hold that goes to "finance" goes to nobody. Each hold rule needs four things.

1. /01

   A trigger you can test. "Unusual invoices" is not a trigger. "Amount more than 3x this supplier's 12-month average" is.

2. /02

   One named approver. A person. Teams and channels don't approve anything. Our note on human in the loop explains why shared queues stall.

3. /03

   A named cover. People go on leave. The rule says who gets the hold when they do.

4. /04

   A time limit and a default. Nobody answers in 24 hours. Then what? The safe default for money is "stays held and escalates". Never "goes ahead".

The EU AI Act points the same way for high-risk systems. Article 26 asks deployers to give oversight to people "who have the necessary competence, training and authority"². Article 14 expects those people to be able to decide not to use the output, or to override or reverse it¹. A named approver with real authority is how you meet that in practice. Those duties apply to high-risk uses from 2 December 2027. Many back-office agents won't be high-risk under the Act. The design is sound either way.

/04Where the policy has to live

This is where most policies fail. They live in the system prompt: "Never pay an invoice over 10,000 without approval." That sentence is a request to a model. It can be forgotten over a long run. Argued around by a clever invoice (see prompt injection in accounts payable). Lost in a model upgrade.

A policy is enforced when the check sits outside the model. The agent proposes an action. A separate layer compares it against the rules. It returns proceed, hold or refuse. The model never gets to decide whether its own action needs approval.

Test it the plain way. Ask to see a run where the agent tried something the policy refuses. Ask for the record of it being stopped. No such run? Then you don't yet know the policy works.

/05Changing the policy

Policies change. Thresholds move after a quarter of data. New actions get added. Money limits get their own rules (see how to set a spend limit). Two rules keep that safe.

• Every change is versioned and recorded. Each run says which version of the policy was in force. Someone asks why an invoice went through in March. The answer includes the March rules.
• Loosening is harder than tightening. Raising a limit, or moving an action from hold to proceed, takes a second person. Lowering a limit doesn't. This is ordinary separation of duties. NIST's AC-5 control says the point is to reduce "the risk of malevolent activity without collusion"³.

The same logic covers overrides. An approver wants to push through something the policy refuses? That takes two names, not one.

/06How Gatehouse holds the policy

In Gatehouse, the policy is a signed rules file. Each action is checked against it before it runs. Holds go to one named approver. Overriding a block takes two names. Every decision is saved in the record, with the rule version that applied. Approver decisions are kept as labelled examples. That shows you where a threshold is too tight or too loose.

You don't need our product to start. You need an afternoon and a spreadsheet.

/07Start here

List every action your agent can take, one per row. Give each a column: proceed, hold or refuse. For every hold, write the trigger, the approver and the cover. Then ask your engineer or vendor one question per row. Where is this enforced? Any row answered "in the prompt" goes on the risk register. Want help with that exercise on a live process? book a teardown.