How to require approval before an AI makes changes in your systems

Acutis Gate · guides for IT directors · updated October 2026

Short answer: decide which actions need a second person, write them down as rules, and put one gate in front of every system the AI can reach. When the AI tries one of those actions, the call is held with its exact arguments, an approver looks at it and confirms with an authenticator code, and only then does it run, as the person who asked. Reads keep flowing; changes wait for a yes.

Decide what needs a second person

Treat it like change control you already run. Good first candidates:

• Finance: approving a payment, changing a vendor's bank details, issuing a refund.
• HR: changing pay, ending someone's employment, editing a personnel record.
• Customer data: bulk updates or deletes in the CRM.
• IT: firewall commits, account and group changes, anything in production.

A simple house rule covers most of it: reads are allowed for the people who need them, and every write or execute waits for an approver.

Why the AI app's own "ask before acting" setting is not enough

Many AI apps can pause and ask the user "run this tool?". That is a prompt for the same person who made the request, inside software they control. It is a convenience, and it leaves no independent record. An approval worth showing an auditor needs a different person, a record of exactly what was approved, and enforcement outside the AI app.

Set it up in Acutis Gate

Acutis Gate is the one tool server your AI apps connect to, so every action passes through its rules. A rule can say allow, deny, approve (hold for an approver) or break-glass (run now with a stated reason, flagged for review).

1. Open Guardrails. On a fresh Gate, let people work for a few days first, then click Build rules from the trail: reads people actually did become allow rules, and writes and executes become approval rules with admins as approvers.
2. Edit the approvers on any rule (for example, the Finance managers group for payments).
3. Turn on Dry run and save: everything still runs, and the trail shows what each rule would have done. When it looks right, turn dry run off.
4. Approvers open Approvals, read the exact arguments the AI wants to send, and approve with their authenticator code, or reject.

The same rule, as Gate stores it:

{
  "id": "finance-payments-approved",
  "who": ["group:Finance"],
  "effect": "approve",
  "do": ["write", "execute"],
  "on": ["finance://tools/**"],
  "approvers": ["group:Finance-Managers"]
}

What happens when the AI tries it

1. The AI calls the tool. Gate checks the rules and holds the call, with its exact arguments, as approval #n.
2. The AI is told plainly: staged for approval, and it will run as the person who asked once approved. The person can carry on with other work.
3. An approver who is not the requester, and who is named on the rule, reviews it and enters an authenticator code.
4. Gate runs the call as the original person, with their own login to the app, so the app's own permissions still apply. If that person has left in the meantime, the approval fails safely.
5. The request, the approval, who approved it and the result all land in the hash-chained audit trail and stream to your SIEM.

An approver can review what is waiting from the command line too:

Command line

# list pending approvals (admins see everyone's; others see their own)
curl -s https://gate.corp.example/api/v1/gate/approvals \
  -H "Authorization: Bearer $GATE_TOKEN"

Frequently asked questions