- Least agency means an agent gets only the tools, permissions and autonomy the task needs.
- Sort every tool into reads, changes inside your systems, and outside or irreversible actions.
- Ask a person to approve changes and outside actions, and show the exact action.
- Checks must sit outside the model, and approvals only help if people do not click through them.
What Do Human In The Loop And Least Agency Mean?
Human in the loop means a person approves actions that matter before an AI agent carries them out. Least agency means the agent gets no more autonomy, tools and permissions than the task needs. The OWASP Top 10 for Agentic Applications 2026 introduces "Least-Agency" and advises avoiding unnecessary autonomy, because agentic behavior where it is not needed expands the attack surface without adding value.
The idea builds on least privilege, but goes further. Privilege is about what an AI agent may touch. Agency is also about how much it may decide and do without asking. OWASP names three root causes of Excessive Agency (LLM06:2025, 2025 edition): excessive functionality, excessive permissions and excessive autonomy. OWASP published a newer 2026 LLM list in August 2026, so check the IDs in your own documents against the edition you use.
Damage happens when an agent acts on "unexpected, ambiguous or manipulated outputs", as OWASP puts it. That manipulation often starts with prompt injection, and the full list of risks is in our guide to the top threats to AI agents. The checklist below is the design answer: shrink what the agent can do, then put a person in front of what is left.
Design Checklist: How Do You Limit What An Agent Can Do?
Run this list for every agent before it gets real access. Each item comes from OWASP guidance on Excessive Agency and the Agentic Applications list, plus NCSC advice on temporary credentials.
- Remove tools the task does not needOWASP says to minimize the extensions an agent can call.
- Cut each tool down to what it needsMinimize extension functionality, for example read-only queries instead of full database access.
- Avoid open-ended toolsOWASP advises avoiding open-ended extensions. Offer narrow functions instead.
- Give each tool the narrowest permissionsOWASP says to minimize extension permissions. Set scopes and a maximum rate per tool.
- Run actions as the user, not as a super accountOWASP advises executing extensions in the user's context.
- Check every downstream request against policyOWASP calls this complete mediation. The check lives outside the model.
- Require approval for high-impact actionsOWASP says to require user approval before such actions.
- Use temporary credentialsNCSC advises limiting scope and using temporary credentials for agents.
Two points deserve more detail. First, the checks must sit outside the model. OWASP says the system prompt "should not be considered a secret, nor should it be used as a security control", and that security controls should be "deterministic, auditable". An instruction such as "never delete anything" is a request, not a barrier. A tool that has no delete permission is a barrier.
Second, OWASP's Agentic Applications list asks for per-tool profiles that set scopes, a maximum rate and where the tool may send data. Its example is read-only database queries. Our article on securing MCP servers and tool access covers the same idea for tools served over the Model Context Protocol.
Which Actions Should Need A Human Approval?
The sources do not give one list, but they use the same words. OWASP asks for human approval for "privileged operations" (LLM01:2025) and for "high-impact" actions (LLM06:2025). The Agentic Applications list asks for human approval of high-impact or goal-changing actions. The Model Context Protocol specification goes further for tools: hosts must obtain explicit user consent before invoking any tool, and should provide clear interfaces for reviewing and authorizing activities.
A simple way to apply this is to sort every tool into three groups. This sorting is our practical suggestion, not a rule from those sources.
| Group | What the tool does | Approval |
|---|---|---|
| Reads | Only looks at data | Can run on its own, inside the user's own access |
| Changes inside your systems | Edits a record, opens a ticket or changes a setting | Ask first, or make sure the change is easy to undo |
| Acts outside or cannot be undone | Sends email, moves money, deletes data or contacts a third party | Always ask, and show what will happen |
Approval has limits of its own, as the next note shows.
How Do You Stop Approvals From Becoming A Rubber Stamp?
OWASP's guide to agentic threats has a playbook for protecting human oversight and preventing threats that start with human interaction. The sources do not give a full recipe, so the points below combine that guidance with our own practical advice.
- Ask rarely, about things that matter. If every read needs a click, people stop reading. Keep reads automatic and save prompts for changes.
- Show the exact action. The MCP specification is firm on this for local servers: the exact command must be shown in full, and dangerous patterns should be highlighted. Apply the same rule to any request: tool, target and the data that will be sent.
- Make "no" and "not sure" easy. A request that cannot be understood should be refused by default.
- Treat the agent's explanation as untrusted. A persuasive reason for an action is not evidence. An injected instruction can produce a convincing reason too.
- Review the approvals themselves. Log who approved what, and look for people who approve everything. More on this in monitoring and logging for AI agents.
What Does This Pattern Look Like In A Product?
Brandefense describes the same split on its MCP server page: read-only tools run directly, tools that change data ask you to confirm in the chat, and tools can only do what your own account can do. Its Odin analyst shows each step and source, and anything that changes something waits for a person. This is one example of the pattern. It is not a claim that any product meets a standard or a checklist.
What To Do Next.
- List every tool one of your agents can call. Start with the agent that has the most access. Give each agent its own identity, as described in AI agent identity and access.
- Mark each tool as a read, a change inside your systems, or an action outside or irreversible.
- Remove tools the task does not need, and narrow the permissions of those that stay.
- Add approval to every change and every outside action, and show the exact action in the request.
- Start with a small pilot. NCSC advises starting small, using agents only for low-risk tasks, and notes that "if you cannot understand, monitor or contain an agent's actions, it is not ready for deployment".
- Write the rules into a policy. Our AI agent governance policy template gives you a starting point.
Sources
- 1 OWASP LLM06:2025 Excessive Agency
- 2 OWASP LLM01:2025 Prompt Injection
- 3 OWASP LLM07:2025 System Prompt Leakage
- 4 OWASP Top 10 for Agentic Applications 2026 (PDF)
- 5 OWASP Agentic AI Threats and Mitigations (PDF)
- 6 Model Context Protocol specification: Security and Trust and Safety
- 7 Model Context Protocol: Security Best Practices
- 8 NCSC: Thinking carefully before adopting agentic AI