Build an approval matrix for AI employees: set limits by action, amount, risk and confidence, add four-eyes and segregation of duties, with a sample.
Every finance team already has a rule for who can approve what. A clerk releases payments up to one number, a manager up to the next, and anything larger needs two names. The moment an AI employee starts preparing or releasing those same transactions, that rule has to cover it too, in writing, and in a form the agent can actually follow. This guide shows how to build the matrix: which dimensions to use, how to set the limits, how to apply four-eyes and segregation of duties, and what a sample looks like.
Our guide to 12 controls for governing AI agents says three things that apply here. Control 4 says high-risk actions should stop for human approval. Control 5 says the agent that prepares a transaction cannot also approve it. Control 10 says an incident playbook should exist. That post tells you the gates must exist and what evidence to keep.
This one covers the next step: deciding where each gate sits. It sets out how to pick the numbers, how to tier them, how to use two approvers, and how to change them as the agent earns trust. For the incident side, see our guide on AI agent incident response.
Four dimensions do most of the work. Use all four, because each one catches cases the others miss.
Action type: Start by splitting what the agent does into reading, preparing, and committing. Reading and drafting are low risk and usually need no approval. Committing actions are where the matrix earns its keep: releasing a payment, issuing a refund, changing master data, writing off a balance, sending a message to a customer, filing a report. Some commits should never belong to the agent at all. Changing a vendor's bank details and then paying that vendor is the classic pair to keep apart.
Amount: Set value bands in the currency of the transaction, and base them on your existing human limits. A sensible starting point is to give the agent less authority than a junior employee in the same role and widen it with evidence. Bands should be per transaction and also cumulative, so an agent cannot split one large payment into five small ones that each fall under the limit.
Risk: Amount alone misses risky small actions. Add a risk tier based on things like a new payee, a changed account, a sanctioned or high-risk jurisdiction, a first-time vendor, or a customer in a protected status. A $400 refund to a new bank account is riskier than a $4,000 refund to the original card.
Confidence: The agent's own certainty about a case is the fourth input. Set a threshold below which the agent stops and routes the case to a person, whatever the amount. Treat confidence as a way to move a case up the matrix, never down. A high score does not authorize an action the amount or risk tier forbids.
The table below is illustrative, using US dollars and a generic payments and refunds role. Replace every number with figures from your own authority policy.
Action | Agent alone | One human approver | Two approvers | Agent never does |
|---|---|---|---|---|
Read, match, classify, draft | Always | Not needed | Not needed | Nothing blocked |
Vendor payment release | Up to $2,500, low risk, above the confidence threshold | $2,500.01 to $25,000, or any medium-risk case | Above $25,000, or any high-risk case | Release a payment after changing the payee's bank details |
Customer refund | Up to $250 to the original payment method | $250.01 to $2,000, or any refund to a new destination | Above $2,000 | Approve its own exception |
Vendor master data change | Never | Always, with out-of-band verification | Bank detail changes above your risk line | Change data it also uses to pay |
Write-off | Never | Up to $1,000 | Above $1,000 | Post the write-off itself |
Customer or regulator communication | Draft only | Human sends | Legal review for regulatory filings | File a report or send a notice |
Two rules sit beside the table. First, low confidence, a missing document or an unfamiliar pattern moves any row one column to the right. Second, any case that touches two rows, such as a refund that also changes a payee, takes the stricter outcome.
Four-eyes means a second, independent person reviews a consequential action before it takes effect. With an AI employee, the agent is usually the preparer and a human is the checker. For the highest tier, require two humans, so the agent's output is never one of the two sets of eyes.
Segregation of duties is the wider principle: no one actor holds incompatible roles in the same process. Agents can break it quietly, because one agent with broad access can initiate, approve and record a transaction in seconds. Apply four checks:
On the compliance side, keep the claims general. The Sarbanes-Oxley Act requires management of public companies to assess internal control over financial reporting, and external auditors review that assessment. It does not prescribe an approval matrix or set dollar limits. The COSO Internal Control framework, which many companies use for that assessment, treats segregation of duties as one kind of control activity. Your matrix is evidence that you designed the control. It is not a statutory template.
Begin tighter than feels necessary. Run the agent with most actions routed to a person, and record how often reviewers agree with it, override it, or change the outcome. Those rates, by action type, are the evidence for loosening a limit. When the override rate on a band stays low for a period you chose in advance, move that band up one step and write down who approved the change and why.
Version the matrix like any control document, with an owner, an effective date and a review cycle. Test it before release with cases on each side of every threshold, including cases that sit exactly on a boundary. Review it whenever the agent's scope, a policy, a system or the transaction mix changes, and at least on a fixed schedule. When an incident happens, the matrix is the first document to check: either the limit was wrong or the gate did not enforce it.
In Zamp, the matrix lives inside each AI employee's agent operating procedure. The AOP holds the policies, tolerances, approval limits and escalation paths for one role, written by the process owner and not by an engineer. Each AI employee has its own identity with least-privilege access, so an action that is not in its scope is not available to it, whatever a document or a user asks for.
Confidence works the way the matrix says it should. When a case falls outside a tolerance, or the agent has no precedent, it assigns Needs Attention and routes the case to a person with the context already assembled. Our own illustrative example: an AOP allows a 2% invoice variance, an invoice arrives at 4%, and the agent escalates instead of improvising. The reviewer approves it, writes down why, and that note is kept as a scoped precedent.
Before a case closes, the validate step of the PEV loop checks the result against what the agent expected, which is where limits get re-checked. Every action logs the input, sources, action, result and approval state, so an auditor can see which gate a case passed and who approved.
Loosening a limit goes through the same path as any change. The process owner edits the AOP on a new branch, the branch runs against evals including a golden set, and it merges after review, with no engineering ticket. The change history shows who changed what and which version is live. Process owners can tighten or loosen gates as trust builds, much as a manager gives a new hire more independence.
The best evidence is a deployment. In a biopharma procurement deployment, the agent sent 64% of purchase requests to manual review in week one, and that high rate was the safety mechanism. After the team restructured how it worked through the procurement rules, its decision rate rose to 85% and manual review fell to 15%. The agent also wrote its reasoning inside SAP Ariba. Regulated buyers most often pick BYOC or on-prem deployment so these logs stay in infrastructure they already audit. See our trust and security page.
