Which AI agent actions should wait for a human: a checklist from OWASP and MCP

An agent action should wait for a person when it is hard to undo, when it reaches people or systems outside your control, when it moves money or grants access, or when the agent decided to do it after reading content you did not write. Everything else can usually run on its own.

That rule is short, but applying it to a real tool list takes some care. This guide builds it from three primary sources, turns it into four questions you can ask of any tool, and runs an inbox agent's tools through them.

What the sources say

OWASP. The OWASP Top 10 for LLM applications calls this risk Excessive Agency (LLM06:2025). It names three root causes: excessive functionality (tools the agent does not need), excessive permissions (tools that can do more than the task requires), and excessive autonomy (high-impact actions with no independent check). Its mitigations include giving agents the smallest set of tools, avoiding open-ended tools such as "run any shell command" where a narrow one would do, and requiring a human to approve high-impact actions. It also says authorization belongs in the downstream system, not in the model's judgment.

Anthropic's computer use guidance. The computer use documentation recommends asking a human to confirm decisions that may have meaningful real-world consequences, and any task that needs affirmative consent, naming accepting cookies, completing financial transactions, and agreeing to terms of service. It also warns that instructions found on web pages or in images can override yours.

The Model Context Protocol. MCP lets a tool server describe each tool with annotations: readOnlyHint (does not modify its environment), destructiveHint (may perform destructive updates rather than only additive ones), idempotentHint (repeating the call with the same arguments has no extra effect), and openWorldHint (interacts with an open world of external entities). The defaults are cautious: a tool with no annotations is assumed to write, to be destructive, to not be idempotent, and to reach the open world. The spec is also explicit that annotations are hints, and that clients should never make tool-use decisions based on annotations from untrusted servers.

Four questions for every tool

The MCP annotations map closely onto the questions that matter for approval. Ask them of each tool, and of the specific call when the arguments change the answer.

1. Does it change anything? Reading a calendar, searching mail, or listing files changes nothing. Read-only tools are the safest to allow, with one exception covered below.
2. Can it be undone? Archiving an email can be reversed. Sending one cannot. Deleting may or may not be recoverable, depending on the system.
3. Does it reach outside? A draft saved in your account stays inside. A message to a customer, a post on a public channel, or a form submitted on someone else's site goes out into the open world, where you cannot take it back.
4. Would doing it twice double the effect? Setting a label twice is harmless. Paying an invoice twice is not. Non-idempotent actions need approval tied to the exact call, so that a retry after a timeout does not quietly repeat it.

Two categories should always ask, whatever the answers above: anything that spends money, and anything that changes who can access what (sharing a document, adding a forwarding rule, inviting a user, creating an API key). Those are how a small mistake becomes a large one.

Worked example: an inbox agent

Here is a typical tool set for an agent that triages email, run through the questions.

A pattern falls out of the table: the agent can do almost all of the tedious work without asking. It reads, sorts, archives, and writes drafts. The person only sees the handful of actions that leave the inbox. If every label change needed a click, people would either turn the agent off or start approving without reading, which is worse than no approvals at all.

The exception: read-only is not always safe

Reading is safe for your data's integrity, but not always for its confidentiality. Simon Willison describes the lethal trifecta: an agent that has access to private data, is exposed to untrusted content, and can communicate externally can be tricked into sending that data to an attacker.

OWASP's own example scenario is the inbox case. An assistant that only needed to read and summarise mail was given a mail plugin that could also send. A crafted incoming email told it to search the mailbox for sensitive information and forward it to the attacker.

The practical consequence for approvals: an outbound action deserves more scrutiny when the agent read untrusted content earlier in the same task. A reply drafted from your own notes is low risk. A reply whose recipient or content came from a web page the agent has visited is exactly what the attack looks like. If your approval system can show the person where the instruction came from, show it.

Make approvals specific

A good approval request names the exact action, not a category. "Send email" is not reviewable. "Send this reply, with this text, to nora@example.com in the renewal thread" is.

Three details make a real difference:

• Bind the approval to the arguments. If the agent changes the recipient or the amount after approval, that is a new action and needs a new approval.
• Check each action in a batch. Anthropic's documentation notes that a model can return several actions in one turn, and that a confirmation check has to run before each one, because a batch can complete a multistep action within a single turn.
• Offer "allow once" and "always allow" at the right scope. "Always allow" should attach to a specific tool or connector, such as archiving in this mailbox, rather than a broad category like "email". Broad grants are how excessive autonomy creeps back in.

If you use an automatic reviewer, a second model that approves routine cases, decide what happens when it is unsure. It should fall back to asking a person, never to acting. An uncertain "yes" is the failure you are trying to prevent.

Where the rules should live

The MCP spec's warning about untrusted annotations points at a broader principle that OWASP also states: enforce permissions outside the model. The agent can propose an action and even explain why it is safe, but the decision to run it should come from rules the agent cannot edit, checked by code that sits between the agent and the tool.

In practice that means:

• A rule store keyed by tool, connector, or category, with an effect of "allow" or "require approval".
• A default of "require approval" for anything unknown, matching MCP's cautious defaults.
• Credentials scoped to the user the agent acts for, as OWASP recommends, so a misfired action cannot reach other people's data. Browser logins count as credentials too; see sharing one browser login between agents.
• A record of every approval and every action, so you can see what ran and who allowed it.

Tenslo Bot follows this shape: approval rules match a tool, a connector, or a category and either always allow or require approval, and the optional automatic review sends an action to a person when it flags it, or when its check fails on a consequential one.

A starting policy you can copy

If you are setting up an agent today and want a sensible default before you have data:

• Run without asking: reads, searches, labels, moves within your own systems, drafts, notes, and anything in a sandbox the agent owns.
• Ask every time: messages to people, posts, form submissions on external sites, deletions, and anything the agent decided to do after reading untrusted content.
• Always ask, never allow permanently: payments, purchases, sharing and permission changes, forwarding rules, new credentials, and accepting terms or agreements.

Then watch what people approve. When someone approves the same narrow action twenty times without changing it, offer to allow it for that tool. When someone rejects an action, look at why the agent proposed it. Approvals are a policy you refine, not a setting you choose once.