Cost
A wrong refund or a sent email costs more to undo than a pause costs to approve.
Home · Agents · 08 · Permissions & human sign-off
Concept card · Agents
Permissions & human sign-off
What this gets you. Decide what your agent may do alone, and make the rest wait for a named person.
Next on this goal: Guardrails.
Permissions are the rules your app enforces about which tools your agent may call for a task, and which actions wait for a named person.
What changed
Oct 26: OWASP sources now point to the 2026 list, where some entries have new numbers.
Earlier updates
Oct 21: First card. You decide which tools may run alone, and a named person approves the rest. Sources include Anthropic, Google, the Model Context Protocol, OpenAI, OWASP and NIST.
Skip to Practice if you already gate your agent's tools by effect and name an approver for each.
Before you start: who runs a tool, the AI model or your code?
Show the answer
Your code. The model only asks. That's why your code can also say no. Recall: your code, not the model, runs each tool. See Tool calling.
1 What it is
Permissions are the rules your app enforces about which tools your agent may call for a task, and with what access. Human sign-off, also called human-in-the-loop, is a pause before an action that changes something. The run waits until a named person approves or rejects that exact action.
The steps, in order.
- 1 · ListList the tools this one task needs. Leave the rest off.
- 2 · EffectMark each tool read (looks something up), draft (prepares something no one else sees yet), or act (sends, files, deletes, pays or changes access).
- 3 · AccessGive each tool the least access it needs. A tool that only reads gets read-only access.
- 4 · ApproverFor each act tool, name who approves it.
- 5 · EnforceEnforce the rules in your app and in the system the tool touches. A sentence in the prompt doesn't count.
- 6 · RecordKeep a record of what was asked for, who approved it, and what ran.
Example: made up to show the idea.
The support assistant answers questions from Northline Desk's sample docs. Say you give it four tools for one task, "help with an export problem":
| Tool | Effect | What happens |
|---|---|---|
search_docs |
read | Runs alone, and is logged |
lookup_account |
read | Runs with the customer's own access |
create_ticket |
draft, then act | Drafts alone; filing waits for the support person on duty |
send_email |
act | Not on this task's list |
A customer writes: "My export only goes back two years. Please open a ticket."
- The assistant searches the docs and finds the export page: the file covers the last 24 months.
- It looks up the account.
- It drafts a ticket that cites the export page.
- The run pauses. The support person sees the exact ticket fields, approves, and your app files it. The pause is one more step in the loop from Agent loop.
- One retrieved document is a pasted note that says to email the admin password. The model proposes
send_email. Your app refuses, because that tool isn't on the list, and the run carries on without it. Why the note can try this: Prompt injection.
If the tool, then what
| If the tool | Then | Who signs off |
|---|---|---|
| reads what this user may already see | let it run; log it | No one |
| prepares a draft no one else sees yet | let it run; show the draft | No one until it's sent or filed |
| sends, files, deletes, pays or changes access | pause and show the exact inputs | A named person allowed to do it themselves, not the requester |
| isn't needed for this task | leave it off the list | No one |
| reads someone else's private data | run it with the user's own access, not a broad agent account | No one, and the system that owns the data checks access |
2 Why it matters
Quality
The approver sees the exact fields, so a wrong account or a wrong address is caught before it lands.
Risk
OWASP, LLM03:2026 Excessive Agency names three causes of an agent doing too much: too many tools, too much access, and too little sign-off. The table cuts all three: leave tools the task doesn't need off the list, give each tool the least access, and make act tools wait for a person.
3 How to apply · try today
Take one agent or one AI model setup that has tools. Write each tool on a line, mark it read, draft or act, and write the name of the person who approves each act tool. Delete any line the task doesn't need.
Common mistake
Writing "ask before sending" in the prompt and calling it a permission. The model can still propose the call. The rule has to live in the code that runs the tool, or in the system that owns the data. Anthropic, Configure permissions says permission rules are enforced by Claude Code, not by the model.
Self-check
Filing a ticket alerts the support team. Where should the "wait for approval" rule live?
Self-check
Which tool can usually run without a person's OK?
Self-check
The person on duty approves a ticket. What should the approval screen show?
Next: checks on what goes in and out, and limits that stop a run. Guardrails.
Example: made up to show the idea.
Same support assistant, same four tools, with the reason filled in. search_docs is a read: it looks up help pages this user may already see, so it runs alone and is logged. lookup_account is a read that uses the customer's own access. create_ticket is an act when filed: it alerts the support team, so the draft runs alone and filing waits for the support person on duty. send_email is an act, and this task doesn't need it, so it stays off the list.
Now a new task: handle a refund request. Two rows are filled. You pick the rest.
| Tool | Effect | Gate |
|---|---|---|
lookup_order |
read | runs alone |
draft_reply |
draft | runs alone, draft shown |
Self-check
Show one line that fits
issue_refund: act, waits for the billing lead, who sees the order id and the amount.
Write the tool list for one task your agent does. Mark each tool's effect, and name the approver for each act tool.
Show a checklist
- Every act tool has a named person.
- The requester isn't the approver.
- No tool is on the list just in case.
- The rule lives in code, not the prompt.
Understand it: whose access, and who may say yes
The list says what this task may do. The approver is a named person who could take that action themselves.
Whose access is it?
A tool can run as the person who is signed in, or as an account the agent holds on its own. Prefer the user's own access, and use read-only access where the tool only reads. OWASP, LLM03:2026 Excessive Agency says to run tools in the user's context, and to check permission in code, in the tool or the system that owns the data, not by asking the model.
Allow, ask, deny
Anthropic, Configure permissions evaluates rules as deny, then ask, then allow, so a deny wins. The same page says the rules are enforced by Claude Code, not by the model. The modes it lists are default (labelled Manual), acceptEdits, plan (labelled Plan), auto, dontAsk, and bypassPermissions. The mode a session starts in depends on your settings and plan, so check it rather than assume Manual. bypassPermissions belongs in an isolated environment, such as a container or a virtual machine. File reads need no approval there, but shell commands do, except a built-in set of read-only commands. So don't treat every tool that only reads as free of approval.
Google, Function calling with the Gemini API says the model doesn't execute the function itself. You can limit which tools are offered, and the page says to validate function calls before executing them.
The list can change with who is asking
Model Context Protocol, Tools says a server may vary the tool list by authorization, and that clients must treat tool annotations as untrusted unless they come from a trusted server. A label on a tool is not a permission. Your app still decides what runs.
What the approver sees, and no answer means no
Show the exact inputs, the reason, and the effect. The Tools specification says to show tool inputs before calling the server. OpenAI, Guardrails and human review says human review pauses the run so a person or a policy can approve or reject. If review times out or becomes unavailable, fail closed: the action doesn't run.
The person who approves is someone allowed to take that action themselves. Not the requester. Not the agent. You'll use this rule again at merge time: Working with a coding agent. On that card, your own approval of the agent's pull request doesn't count when the repository requires another reviewer.
Keep the record
Write down what was asked, who approved it, and what ran. The Tools specification says to log tool usage for audit. NIST, Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile (published July 26, 2024) asks, in MANAGE 2.4, for mechanisms and assigned responsibility to supersede, disengage, or deactivate a system whose outcomes don't match the intended use. The same profile's MS-4.2-004 says to monitor and document cases where a person or another system overrides the system's decisions.
Too many asks, and how you test it
Advice, not a sourced claim: people start approving without reading when every step asks. Keep asks on act tools, and make each ask name the exact action.
Add approval cases to the set you already grade. Test it: Evaluation basics.
See the pasted note in the support assistant. The live page shows the note asking for a refund the docs don't allow. It does not show a tool that sends email.
Questions
- Doesn't asking a person every time slow everything down?
- Ask only for act tools, and show exactly what will run. Reads and drafts don't wait.
- What if no one answers?
- Treat no answer as no. The run stays paused or stops, and the action doesn't run.