When does an AI agent need permission?

Three questions behind every action

An AI agent has found something it could buy. It has access to a payment tool. The price fits the available balance. Is the purchase authorized? Those facts leave the most important question unanswered: what did the person responsible actually permit?

For this explainer, separate capability, instruction and permission. Capability concerns the tools available. Instruction concerns the task requested. Permission concerns the actions allowed while doing that task. A working checkout button answers a technical question. It cannot answer the other two.

Anthropic's Building effective agents distinguishes predefined workflows from agents that choose their own process and tool use. That distinction describes how work proceeds. Our editorial point is that choosing a route through a task does not, by itself, enlarge the task's authority.

A fresh instruction is not always necessary

• An owner asks it to compare suppliers and prepare a recommendation. The authorized result is a recommendation. Buying the recommended item adds an action the request did not include.
• An owner gives standing permission to reorder approved supplies within an agreed budget. A qualifying reorder may fit that permission without a new instruction for each purchase.
• An owner approves a particular order. That approval covers the agreed order; it does not automatically cover a subscription, a different recipient or another order.

In these examples, the useful question is whether the proposed action fits the permission already given. Asking again for everything would ignore the standing arrangement. Treating every related action as approved would stretch it. The boundary needs to be clear enough to tell those cases apart.

Write a permission someone can check

Our suggested starting point is a short description of the intended outcome and the permitted actions. For a purchasing task, spell out the product category, allowed seller, total budget, treatment of tax and fees, and whether repeat orders are included. Define the period the permission covers and the changes that require another decision.

Hypothetical example: permission to replace an exhausted office supply from a named supplier, within an agreed total and without recurring charges, gives a reviewer something concrete to compare with the proposed order. A general instruction to be helpful leaves much more room for disagreement.

This is an editorial checklist, not a universal permission standard. Different tasks need different boundaries. The aim is to make the decision reviewable before action and explainable afterwards, including when the appropriate outcome is to stop and ask.

Put the boundary in the tools too

OWASP's guidance on excessive agency identifies unnecessary functions, excessive access and insufficient oversight as sources of risk. It recommends giving tools only the functions and access they need, checking authorization in downstream systems, and requiring human approval for high-impact actions.

Applied to our hypothetical stationery assistant, a supplier-comparison task could use a catalogue reader without any ordering function. An approved ordering task could use an order tool that checks the allowed supplier and total. These are illustrative designs, not claims about controls currently implemented by WentRogue.

OWASP also recommends logging and monitoring tool activity to help identify unwanted actions. A record of what a tool did helps with investigation; recording an action does not make it authorized.

Why WentRogue asks about both instruction and permission

WentRogue's purchase question asks whether a human specifically instructed the purchase. Its answers distinguish a specific instruction from general spending permission, a declaration of acting outside permission, and a choice not to disclose.

That distinction leaves room for a legitimate standing arrangement. Selecting the general-permission answer need not mean a fresh instruction existed. Equally, selecting any answer records a declaration; it does not verify the private arrangement behind it. WentRogue's agent rules explicitly say that the site grants no additional spending authority.

The experiment is scheduled to open on November 15, 2026 at 00:00 UTC. This article explains the design before opening. It reports no purchase findings.

Check the proposed action against the actual permission

For an operator reviewing a proposed action, our suggested final check is plain: identify the requested outcome, find the permission that covers this action, and compare the proposed details with its limits. If those details have changed, check the change before proceeding.

For someone reading a public purchase record, the question is narrower. What was paid for, and what was declared? The private permission may remain unknown. Our guide to a one-dollar purchase record explains that evidence boundary. Keeping these questions separate makes both agent operation and public discussion easier to assess.