Agent Security › Approval check
Not every agent action needs a human, and approving everything just creates approval fatigue. A practical way to decide, action by action, where the human actually belongs.
Not every AI agent action needs a human. Some definitely do. The difficult part is knowing where to draw the line. If you approve everything, your agent isn't very autonomous. If you approve nothing, you may discover the boundary only after something has gone wrong.
This tool helps you decide, for a given action: should the agent act, should a human approve, or should the action be blocked completely? It reflects where current guidance is heading. OWASP recommends human approval for high-impact actions, while NIST's agentic identity work highlights the opposite problem too: too many approvals create consent fatigue, so oversight should be risk-based.
Imagine an agent that needs your approval to read a webpage, open a document, analyse some data, create a draft, save a file or check another source. You haven't really automated the job. You've created an assistant that constantly asks permission. And too many approval requests create another problem: approval fatigue. When humans are asked to approve routine actions again and again, approval becomes automatic. Click, approve, click, approve. The human is technically in the loop, but may no longer be meaningfully controlling it.
The question isn't "should humans supervise AI agents?" It's "where does human judgement actually matter?"
Describe what the agent is about to do, for example "send a reply to an existing customer support ticket", then work through these.
1Does the action affect another person?
Could it communicate with a customer, employee or supplier; change somebody's account or access; make a decision affecting somebody; send personal information; or affect somebody's employment, finances, education, health or other significant interests?
2Does it create a financial consequence?
Could it make a payment, issue a refund, place an order, buy advertising, increase cloud or API spend, enter a subscription, or commit the business financially? If yes, what's the maximum financial consequence?
3Does it communicate externally?
Send an email, reply to a customer, submit a form, send a message, contact a new recipient, or send information to another organisation?
4Does it make something public?
Publish a webpage or article, post on social media, issue a public statement, or change public product information or pricing?
5Does it change important data?
Change customer, financial, employee, production records or configuration; modify or deploy code?
6Can it delete anything?
Delete a file, a customer record, production data; remove an account or infrastructure; cancel a resource? If yes, can it be recovered easily?
7Does it involve sensitive information?
Access, transform or send personal, financial, employee, customer or health information, credentials or secrets, confidential business information or source code?
8Is the action easily reversible?
Imagine the agent gets this completely wrong. Can you undo it quickly? An incorrect draft can be discarded; an email already sent cannot be unsent from the recipient's inbox; a deleted database may or may not be recoverable; a public post may already have been seen; a payment may already have left the account.
9Is the destination already known?
Pre-approved (an existing customer ticket, an approved supplier, a known system, an approved publishing account), new (a destination not already approved), or dynamic (the agent decides the destination itself). New and dynamic destinations generally deserve more scrutiny.
10Is the action inside a predefined limit?
For example: refund up to £20; send to existing support customers; publish to staging only; modify assigned CRM records only; spend up to £10 per day; create files inside one project folder.
11Has this exact type of action been approved before?
A routine action inside a defined policy is different from an agent inventing a new course of action.
12Is the agent changing its own authority?
Add a tool or integration, create credentials, increase permissions, change an approval requirement, disable monitoring, alter its own boundaries, or create another agent with greater authority? If yes: human approval recommended. An agent should not normally be the sole authority deciding whether its own authority should increase.
13Is another agent involved?
Could this cause another agent to access information, send something, spend money, change a system, publish, delete, or use authority the first agent doesn't have? If yes: check delegated authority. Approval shouldn't disappear simply because the work passed from one agent to another.
The result falls into one of four categories.
Low consequence, reversible, inside known systems and predefined limits, no unusual sensitive data, no significant external consequence, no authority escalation, no unexpected delegation. Example: research five public competitor websites and prepare an internal summary. Control: ALLOW, monitor normally, verify the expected outcome.
The agent can act independently, but only inside explicit boundaries. Example: a support agent may refund up to £20 for an existing authenticated customer, through the approved payment system only, every transaction logged, with a daily total limit and unusual patterns triggering review. The point isn't "agent may issue refunds", it's defining how much, to whom, through what system, how often and under what conditions.
The agent can prepare the action, but a person approves execution. Reasons: significant financial consequence, sensitive information, a new external recipient, public publication, a production change, a difficult-to-reverse or unusual action, a high-impact decision, authority escalation, or an action outside normal boundaries. Example: a finance agent reads the invoice, checks the purchase order, compares supplier details and prepares a £4,500 payment, then STOPS and a human approves execution.
Some decisions shouldn't merely receive an approval popup after an agent has effectively made them. Where the action creates particularly significant consequences for people, rights, safety or the organisation, the agent may gather evidence, analyse, summarise and prepare information, but the human makes the substantive decision. The agent assists; the human decides.
Imagine an AI agent decides "Employee X should be dismissed", then asks "approve?" Technically a human is involved, but the AI has already framed the decision. For particularly consequential decisions, the better structure is "agent: here is the relevant information; human: I decide what happens", rather than "agent: here is my decision, click approve".
Think of agent work as a chain: READ, ANALYSE, RECOMMEND, PREPARE, ACT. The human doesn't need to sit at the beginning. Often the best place is immediately before the consequence. Let the agent do the work leading up to the boundary, then involve the human where judgement genuinely matters.
| Content Agent | Control |
|---|---|
| Research topic, analyse sources, draft article, prepare CMS entry | Autonomous |
| Publish to staging | Autonomous with limits |
| Publish publicly | Human approval |
| Delete existing article | Human approval or deny |
One human decision, not six interruptions.
| Finance Agent | Control |
|---|---|
| Read invoices, match to PO, flag discrepancy, prepare payment | Autonomous |
| Pay £18 recurring approved software invoice | Autonomous with limits |
| Pay £8,000 to established supplier | Human approval |
| Pay £8,000 to new bank account supplied by email | Human approval + additional verification |
| Change supplier bank details | Human approval + independent verification |
| Customer Support Agent | Control |
|---|---|
| Read incoming ticket; draft response | Autonomous |
| Retrieve customer's relevant account details; send routine response; refund £10 | Autonomous with limits |
| Refund £500 | Human approval |
| Export entire customer database | Deny |
| Coding Agent | Control |
|---|---|
| Read repository, create branch, write code, run tests, open pull request | Autonomous |
| Deploy staging | Autonomous with limits |
| Deploy production | Human approval |
| Disable security controls to complete deployment | Deny |
In each case, don't decide whether the agent is autonomous. Decide which actions are autonomous.
Avoid blanket approval. If an agent needs the CRM and a human clicks "allow CRM", you may have approved far more than the job required when the agent only needed READ on an assigned contact. Approval should apply to action plus resource plus context, not simply a system.
Don't approve vague actions. "Agent wants to update CRM, approve/deny" is weak. "Support Agent wants to change Customer #4821 status from ACTIVE to CANCELLED following support request #9218" is better. Better still, show why, what changes, who is affected, whether it can be reversed, which agent requested it and what authority it currently has. The human needs enough information to make a meaningful decision.
Don't let approval become a reflex. If the same safe action needs approval 300 times a day, your approval design may be wrong. Define a narrow policy, set a limit, approve the category and monitor exceptions. Instead of approving every £5 refund: "support agent may refund up to £20 to an existing customer's original payment method", so an £8 or £17 refund is autonomous, a £70 refund needs approval, a new bank account needs approval and a £2,000 refund is denied. Put humans where consequences change.
An action doesn't become safe merely because somebody clicked APPROVE. You may also need identity, least privilege, hard boundaries, transaction limits, destination restrictions, monitoring, verification, logging, recovery and containment. Human approval is one control, not the entire security architecture.
What happens if nobody responds? Never assume no response equals approved. Choose wait, cancel, expire or escalate to another approver. For consequential actions, silence should not silently become permission.
Approval should expire. An approval given yesterday shouldn't necessarily authorise an action tomorrow. Where appropriate, bind approval to one action, one amount, one recipient, one task, one deployment, one session or one time window. After that, authority expires.
The agent shouldn't approve itself. As systems get more complex this gets murky: Agent A requests an action, Agent B approves it, but who authorised Agent B to approve? If Agent B is simply another model inside the same workflow, you may not have added meaningful independent control. For consequential actions, know where the authority ultimately comes from.
| Field | Example |
|---|---|
| Agent / Action | Invoice Agent / execute supplier payment |
| Consequence / Reversible | Financial / limited |
| Destination | Existing approved supplier |
| Normal limit / Requested | £500 / £2,750 |
| Recommendation | Human approval (exceeds autonomous financial limit) |
| Agent may autonomously | Read invoice, verify supplier, match PO, prepare payment |
| Human controls | Execution |
| Additional boundary | Agent cannot modify supplier bank details |
| Verification | Payment record must exist in approved payment system after execution |
| Approval expires | After this transaction |
This result can be added directly to your AI Agent Authority Profile or your Agent Register, so the approval rule isn't forgotten after today's conversation.
After deciding where human approval belongs: how will you know the approved action actually happened correctly? Because approval isn't verification. A human may approve "send the newsletter". That doesn't prove the newsletter was sent. The agent may still fail after approval.
PREPARE, then APPROVE, then EXECUTE, then VERIFY. Approval controls permission. Verification confirms outcome. You need both for important actions.
With one agent, remembering these rules is easy. With five, ten, twenty or fifty, it becomes much harder: which actions require approval, which are waiting, which expired, which executed, which actually completed? That's one of the problems we're working on with Agent Control. Know what your agents can do, see what they actually do, verify that the job got done.
If you're still unsure where to put the human, ask: what happens if the agent is confidently wrong? If the answer is "not much", autonomy may be appropriate. If the answer is "something meaningful, expensive, public, sensitive or difficult to reverse", consider human approval. And if the answer is "a human should make this decision", keep the decision human.
Don't put humans everywhere. Put them where consequences begin.