Human Approval for AI Agents Without Slowing Everything

The two ways approval goes wrong

Ask a team how they keep people in charge of their AI agents and you'll usually hear one of two answers. Either nothing needs approval, because the agents are "only doing small things". Or everything needs approval, and a tired engineer clicks yes forty times before lunch.

Both fail. The first leaves nobody between the agent and a bad production change. The second looks like oversight but isn't, because no one can genuinely review forty requests in a morning. We've felt both while running our own agents. The answer isn't more approval. It's better-placed approval.

What do the EU AI Act and NIST say about human oversight?

Article 14 of the EU AI Act requires that high-risk AI systems are designed so people can effectively oversee them while they're in use. Not every agent is a high-risk system under the Act, so check your own use with counsel. Even so, the article works as a good checklist for anyone. It says the people overseeing a system should be able to stay aware of the tendency to rely, or over-rely, on its output, which the Act calls automation bias. They should be able to decide not to use the system in a given situation, or to disregard, override or reverse its output. And they should be able to intervene, or interrupt the system through a "stop" button or a similar procedure.

Article 14 also contains a two-person rule, though a narrow one. For certain remote biometric identification systems, no action may be taken on an identification unless at least two people have separately verified and confirmed it.

The NIST AI Risk Management Framework is voluntary but widely used. Its core document, NIST AI 100-1, asks for policies that define roles and responsibilities for human-AI configurations and oversight (GOVERN 3.2). It also asks for mechanisms to supersede, disengage or deactivate AI systems whose performance or outcomes don't match their intended use (MANAGE 2.4).

Put together, the message is simple. Oversight has to be real, people have to be able to say no, and there has to be a way to stop the system.

Which agent actions deserve a human?

Not every action does. The OWASP entry on Excessive Agency recommends human-in-the-loop control so a person approves high-impact actions before they're taken. The Model Context Protocol specification, a common standard for connecting agents to tools, says there should always be a human in the loop with the ability to deny tool calls. Simon Willison suggests treating those shoulds as musts. We agree, with one condition: point the person at the actions that matter. Attention is the scarcest thing in any approval process.

A useful rule: ask a person when an action is hard to undo, large in scope, or touches money, access or customers. Everything else should be checked automatically, then allowed or blocked without anyone waiting. In practice, the actions worth a human usually look like this:

• Deleting or changing data at scale, such as a query that would touch thousands of rows.
• Production infrastructure changes, especially anything touching access, networking or storage.
• Granting permissions, creating credentials, or changing who can do what.
• Moving money, issuing refunds or changing prices.
• Messages to many customers at once, or anything public.
• Changes to the rules that govern the agents themselves.

Two-person rules, and keeping the owner out

For the riskiest actions, one approver isn't enough. The four-eyes principle, long familiar in finance, exists for a simple reason: one person can be tired, rushed, tricked or compromised. Two independent people rarely are, all at the same moment.

Agents add a wrinkle. The person who runs an agent usually wants its work to go through. That's natural, and it's exactly why they shouldn't be the only approver for its riskiest actions. For high-stakes changes, consider keeping the agent's own owner out of the approval, so the second pair of eyes is genuinely independent.

Two-person rules have a cost, so use them sparingly. If every change needs two people, you've doubled your approval fatigue overnight. A sensible split is one approver for most held actions, and two for the short list where a mistake would be expensive, public or hard to reverse: deleting production data, granting admin access, large payments. Write that list down, name who can approve each item, and review it after the first month.

Bind each approval to one exact action

This one is easy to miss. Suppose a person approves "the agent's database clean-up", and the agent then runs a slightly different query. What exactly was approved? Approvals that cover a vague intent, a time window or a whole session can be stretched far beyond anything a person actually looked at.

A sound approval covers one exact action: this query, with these values, on this database. If anything changes, it needs a new approval. That also protects you from an attacker who has hijacked an agent, waits for an approval to land, and then swaps in a different action.

Good approval requests show the approver what matters. Not a wall of logs, but what will change, how much, where, and why the agent wants to do it. For a database change, the most useful fact is often how many rows it would affect, measured by trying it safely first rather than guessed.

How do you avoid approval fatigue?

Approval fatigue is automation bias in a different coat. When people approve everything, they stop reading. Here's what helps:

• Approve less. Turn routine decisions into clear rules, so people only see what needs judgement.
• Fix instead of asking. If a reply contains a card number, remove it and send the rest. Nobody needs to approve that.
• Make requests specific. Show the exact action and its measured effect.
• Watch approval rates. If someone says yes to every single request, either the rules are too broad or the review isn't really happening.
• Give people a real no. A rejection should go back to the agent with a reason, so it can try a safer approach.
• Keep a stop switch. A person should be able to stop one agent, or all of them, without filing a ticket.

Start in watch-only mode

The hardest part of approval design is guessing in advance which actions will be risky. You don't have to guess. Run your checks in watch-only mode first: record what would have been allowed, held or blocked, without enforcing anything.

A couple of weeks of that tells you where your agents really spend their time, which rules would have fired, and how many approvals people would have faced. Then tune the rules and switch on enforcement in stages. It's also the easiest way to win over engineers who worry that a new control will break their agents.

One honest caution. Human approval is a layer, not a cure. People can be fooled by a convincing request, and the best approval process won't help much if the agent has far more access than it needs. Pair approvals with least privilege and automatic checks.

How we do it with Cognilox

In Cognilox, the riskiest actions are held for human approval, from two people if the company wants, and the agent's own owner can be kept out. Each approval covers only that exact action. Risky database changes are tested first, tried and rolled back, so the approver sees how much they would change. Infrastructure change plans are reviewed before they're applied.

You can start in watch-only mode. One switch stops one agent, one team or every agent, and each agent's calls, usage and spend can be capped. Every decision is signed, tamper-evident evidence that holds the decision, not the content, so you can show later who approved what. Any session can be replayed. There's more on how control works, and if you'd like to see an approval flow end to end, we'll walk you through a live demo.