How do I require human approval before an AI agent acts?
Updated · DBShifts
Short answer
Hold risky actions — writes, refunds, deletions, calls to sensitive agents — in a queue instead of running them. Show the approver exactly what will run, with sensitive values masked, and run it only after a person approves. Expire requests nobody answers, keep a before-image so an approved change can be undone, and log who approved what.
Key facts
- Human-in-the-loop means the agent proposes, a person decides, and only then does the action run.
- Approval belongs on actions with consequences: writes, money movement, deletions and messages sent outside the company.
- The approver must see the exact action and data, masked the same way the agent's data is.
- An approval request that nobody answers should expire, not run.
- A before-image of the changed rows is what makes an approved action reversible.
In the glossary:Human-in-the-loop
What should wait for a person
Reads inside policy can run directly; that is what policy is for. Anything that changes data, moves money, deletes or contacts a customer should be proposed, not executed. So should calls into an agent that holds especially sensitive data, even if the call itself is a read.
What the approver needs to see
The precise action — the table, the rows affected, the new values, the target agent and the message — not a model's summary of it. Sensitive values are masked in the preview exactly as they would be for the agent, so approving does not expose more than acting would.
After approval
Run the action exactly as approved, record who approved it and when, and keep enough of the previous state to reverse it. If the action was wrong, undo should be one step, not a restore from backup.
Checklist
- 1
A list of action types that always need approval
- 2
Approval requests with an expiry
- 3
A preview of the exact action, with sensitive data masked
- 4
Approvals reachable where people already work, such as chat
- 5
Before-images kept so actions can be undone
- 6
Approver, time and outcome in the audit log
Common mistakes
Approving a summary instead of the action
A model's description of a change can be wrong or manipulated. The approver should see the statement or call that will actually run.
Approvals that never expire
A request approved days later, after the data changed, can do something nobody intended.
How DBShifts does it
- DBShifts Agent Gateway lets agents propose writes that wait for an owner's approval, in the app or from Slack, within an approval window you set, and keeps a before-image so an executed action can be undone.
- Agents can ask for access to a table they cannot read; an owner grants it for 15 minutes, an hour, four hours or a day.
- In DBShifts Agent Mesh a rule can hold a call for approval: the owner sees the request masked exactly as the target would receive it, and approves or rejects it with a reason.
Questions people also ask
Should every agent action need approval?
No. Approval on every read trains people to click approve without looking. Gate the actions with consequences and let policy handle the rest.
Can approvals happen in Slack?
In DBShifts Agent Gateway, yes: new write proposals post to a Slack channel with approve and reject buttons.
Related questions
Give AI agents data access you can defend
Scoped tokens, PII masked on the server, every request audited. Free to start.
Start free28 answers in this series. See all or browse the AI agent glossary.