Require two approvers when an agent action is destructive, hard to reverse, touches production or customer data, or spends money above a set limit. Everything else should run on a single approval or policy check, so that people keep taking the two person review seriously.
What four eyes means
Four eyes, or two person approval, means one person requests or reviews an action and a different person confirms it. It is old practice for payments and production changes. It fits agents because an agent can issue a destructive command in under a second, and a single tired approver is a thin barrier.
Choose triggers, not blanket rules
Two approvers on every action will be bypassed within a week. Pick triggers narrowly.
| Trigger | Example | Two approvers? |
|---|---|---|
| Deletes or overwrites data | Dropping a table, deleting a bucket | Yes |
| Changes access | Granting a role, editing a policy | Yes |
| Touches production configuration | Changing a deployment setting | Yes |
| Moves data outside the company | Sending an export to an external address | Yes |
| Spends above a limit | Purchases, paid API usage | Yes, above threshold |
| Reads internal non sensitive data | Searching a wiki | No |
| Writes to a sandbox | Creating a test record | No |
OWASP's guidance says to use human approval for high impact actions, and to put that approval in a downstream system or inside the extension that performs the operation, not in the model's reasoning. Two person approval is the strongest version of that for the highest impact set.
Design points
- The second approver must be independent: not the requester, not the sponsor acting alone, not the agent.
- Show both approvers the same concrete details: tool, target, parameters, and the expected effect. A vague prompt invites a reflex yes.
- Tie each approval to one action. It expires after use or a short window.
- Block the action in the tool or downstream service until both approvals exist, so no code path skips the check.
- Log both approvers, the details they saw and the timing.
- Provide an on call route so approvals are not delayed for hours. Slow approval leads to workarounds.
Avoid approval fatigue
If approvers see dozens of requests an hour, quality drops. Reduce volume before adding people: remove the need for approval where a deterministic rule can decide, such as allowing writes only to a named test resource. Batch similar low risk requests. Track approval times, since a median of two seconds suggests nobody is reading.
Handle the small team problem
A team of three may not have enough people for every shift. Define a fallback, such as a second approver from another team for production deletes, rather than allowing a single approver to proceed.
Test it
Ask an agent in a safe environment to perform a destructive action. Confirm that it cannot complete with one approval, that the same person cannot approve twice, and that an expired approval is rejected.
Safeguard offers policies, gates and guardrails for enforcing approval rules, and a free scan is available at https://gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen. Watch how a gate holds a change until the required checks pass.
Quick check
Can the same person approve twice?
No. The two approvers must be different people, and neither is the requester.
What if approvals are too slow?
Set an on call route and reduce approval volume with deterministic rules instead of relaxing the two person rule.
Sources
Last reviewed: 19 October 2026.
