"Keep a human in the loop" is the most repeated advice about AI agents and one of the least specific. An AI agent autonomy tier is a defined level of how much an agent may do without a person's approval, granted only with evidence that the agent is reliable at that level. Which actions need a person? What should that person see? When can an agent be trusted with fewer approvals? Without answers, a human in the loop becomes a person clicking "approve" on summaries they cannot check.
AELSHA™ ASTRA, the framework we use to deliver every agent engagement, answers those questions with four autonomy tiers and one rule: autonomy is earned through demonstrated reliability. This note sets out the tiers, the evidence we expect before an agent moves up, and how to design an approval step that is a real control.
Why a click is not a control
OWASP's Top 10 for Agentic Applications (2026) lists Human-Agent Trust Exploitation as a risk in its own right, and ranks Excessive Agency third in its 2026 Top 10 for LLM applications. Both describe the same gap. An agent that can act beyond what its task requires, overseen by people who approve what they cannot see, is not supervised. It only looks supervised.
The same OWASP agentic document introduces "least agency": give an agent no more autonomy than the job needs. Tiers make that principle operational.
Four tiers, each earned with evidence
These four tiers are the AELSHA™ ASTRA model, not an industry standard. Other published schemes define levels differently: Feng, McDonald and Zhang's paper Levels of Autonomy for AI Agents, for example, describes five levels of escalating agent autonomy, each characterised by the role the user takes: operator, collaborator, consultant, approver and observer.
Each tier includes everything in the tier before it. No tier is "safe"; each one states what evidence supports the autonomy granted.
| Tier | The agent may | Evidence expected before operating at this tier |
|---|---|---|
| T0 Assist | Suggest. A person performs every action. | A threat model for the use case. Retrieved content and tool output handled as data, never as instructions. Prompts and responses traced. No write access issued to the agent. |
| T1 Supervised | Act, with a person approving each consequential step. | Its own identity with scoped, short-lived credentials. An explicit allow-list of tools with argument validation. Approval screens that show the concrete action. Adversarial test results recorded. |
| T2 Conditional | Act alone within defined limits, and escalate outside them. | Limits enforced outside the model: spend, volume, scope and time. Sandboxed execution. Behavioural monitoring with alert thresholds. A tested kill switch and rollback. A release gate re-run on every model or tool change. |
| T3 High | Act with broad independence and review after the fact. | Continuous adversarial evaluation before production. A tamper-evident audit trail reviewed on a schedule. An independent review of the threat model. Defined criteria that return the agent to a lower tier when the evidence weakens. |
Promotion from one tier to the next is a recorded human decision, supported by evidence, never a configuration change made because an agent "seems fine".
How the tiers map to published guidance
The tiers and the evidence for each are our proposal. The table maps each control to the nearest item in three documents of different kinds: the OWASP agentic Top 10, which is community security guidance; NIST's voluntary AI Risk Management Framework (AI RMF 1.0) and its Generative AI Profile, NIST AI 600-1; and Article 14, "Human oversight", of the EU AI Act, Regulation (EU) 2024/1689, which is law. It is our mapping, not a conformance or certification claim.
None of the three defines autonomy tiers. The closest ideas are the AI RMF's note that human-AI configurations "can span from fully autonomous to fully manual", and Article 14(3), which makes oversight measures commensurate with the risks, level of autonomy and context of use.
Article 14 applies only to AI systems classified as high-risk under Article 6 of the Act, and it is written largely as a design requirement on the provider. For an agent that is not high-risk, read that column as a design reference, not an obligation. If a system is high-risk, T3's broad independence must still let people, as appropriate and proportionate, override or reverse its output and stop it in a safe state, under Article 14(4)(d) and (e).
ASI codes are OWASP's entry IDs. NIST entries are AI RMF subcategories, such as MAP 3.5, or AI 600-1 suggested-action IDs, such as GV-1.7-001. Where we found no direct counterpart, the cell says so.
| Tier and control | OWASP Agentic Top 10 (2026) | NIST AI RMF 1.0 and AI 600-1 | EU AI Act Article 14 |
|---|---|---|---|
| T0: threat model; retrieved content and tool output handled as data | ASI01 Agent Goal Hijack: treat natural-language inputs as untrusted. ASI06 Memory & Context Poisoning | GV-3.2-005 threat modelling. MAP 5.1 likelihood and magnitude of impacts | No direct counterpart |
| T1: own identity with scoped, short-lived credentials; tool allow-list with argument validation | ASI03 Identity and Privilege Abuse: task-scoped, time-bound permissions. ASI02 Tool Misuse and Exploitation: least agency and least privilege for tools, policy enforcement middleware | MEASURE 2.7 security and resilience. MS-2.7-001, which lists autonomous agents among threats to assess | No direct counterpart; cybersecurity is Article 15 |
| T1: a person approves each consequential step on a screen that shows the concrete action, with the agent's explanation last | ASI02 action-level authentication and approval, with a dry-run or diff preview. ASI09 Human-Agent Trust Exploitation: explicit confirmations, and a plain-language risk summary rather than model-generated rationales | MAP 3.5 human oversight processes. GOVERN 3.2 roles for human-AI configurations and oversight | 14(1) human-machine interface tools. 14(4)(c) interpret the output correctly. 14(4)(d) disregard, override or reverse it |
| T1 and T2: designing against approval fatigue | ASI09 adaptive trust calibration, and human-factors and UI safeguards | AI 600-1 Human-AI Configuration risk: automation bias and over-reliance. MP-3.4-005 track outcomes of human-GAI configurations | 14(4)(b) awareness of automation bias |
| T1 to T3: adversarial testing, continuous at T3 | ASI01 periodic red-team tests of goal override | MEASURE 2.7. MS-2.7-007 AI red-teaming, including prompt injection | No direct counterpart |
| T2: limits on spend, volume, scope and time enforced outside the model; sandboxed execution | ASI02 adaptive tool budgeting and execution sandboxes. ASI05 Unexpected Code Execution: sandboxed containers. ASI08 Cascading Failures: independent policy enforcement, blast-radius guardrails | MAP 1.5 documented risk tolerances. MEASURE 2.6 the system can fail safely | 14(3) oversight measures built into the system by the provider |
| T2: behavioural monitoring with alert thresholds; release gate re-run on every model or tool change | ASI10 Rogue Agents: monitoring and detection. ASI04 Agentic Supply Chain Vulnerabilities: staged rollout with differential tests | MEASURE 2.4 behaviour monitored in production. MANAGE 4.1 post-deployment monitoring and change management | 14(4)(a) monitor operation and detect anomalies |
| T2: tested kill switch and rollback | ASI10 kill switches and credential revocation. ASI04 supply chain kill switch | MANAGE 2.4 supersede, disengage or deactivate. GV-1.7-001 able to deactivate | 14(4)(e) interrupt the system so it halts in a safe state |
| T3: tamper-evident audit trail; independent review of the threat model | ASI08, ASI09 and ASI10 each call for tamper-evident or immutable logs | MEASURE 1.3 independent assessors. GV-3.2-001 independent evaluations proportional to risk | No direct counterpart |
| T3: criteria that return the agent to a lower tier | ASI09 adaptive trust calibration: adjust autonomy and oversight to contextual risk | MG-2.4-004 deactivation criteria set against risk tolerance | 14(3) oversight commensurate with the level of autonomy |
Decide what needs approval before the agent runs
Start by listing every action the agent can take and classifying it: read-only, reversible write, irreversible, financial, external-facing, or privilege-changing. Irreversible, financial, external-facing and privilege-changing actions need a person's approval at T1 and T2; at T0 the person performs them.
The classification belongs in policy outside the model. If the agent can decide that an action does not need approval, the approval step is advisory.
Show the action, not the agent's summary
An approval screen should let a person check what will happen, not what the agent says will happen:
- The concrete action. The tool, the target and the exact arguments, or a diff of the change.
- The source. Who or what requested it, and which content triggered it, for example "while reading document X".
- The consequence. Amount, recipients, records affected, and whether it can be undone.
- Untrusted text as quoted data. Content from documents or tools must never be styled like a system message.
- The agent's explanation last, labelled as the agent's account and placed below the action itself.
The Model Context Protocol applies the same idea to tools: its security best practices require a one-click local server installation to show the exact command before it runs.
Bind approval to the action
An approval is only as strong as what it is attached to:
- It binds to the exact action and arguments shown. If the arguments change, the approval is void.
- It expires after a short, defined time. The default is deny, and a timeout denies.
- The approver is authenticated and authorised for that class of action. For the highest risks, add step-up authentication and separate the requester from the approver.
- Each record holds the approver, the time, the exact action, a trace ID and the decision, and is tamper-evident.
Design against approval fatigue
People approve what they see most often without reading it. Measure approval volume, and treat a rising rate as a signal to move low-risk actions into enforced limits so that approvers see fewer, more meaningful requests. Sample whether approvers read the screen by seeding harmless test requests into the real flow, and report the results without blame.
Test the approval flow for real
Run the approval flow end to end before production, with real identities. Confirm that changed arguments void an approval, that expiry works, that what the screen showed matches what was executed, and that untrusted content cannot restyle the screen. A mocked approval service proves none of this.
If you are deciding where people should approve your agents' actions, our agent security work starts with a threat model and ends with evidence for each tier. The AELSHA™ ASTRA framework describes the full lifecycle the tiers sit in.
Further reading
- Top 10 for Agentic Applications 2026, OWASP GenAI Security Project: The risk list behind least agency and human-agent trust exploitation, and a sound place to start the threat model every tier needs.
- Levels of Autonomy for AI Agents, Feng, McDonald and Zhang: A different five-level scheme, useful for testing whether your own tiers draw their lines in the right places.
- Security best practices, Model Context Protocol: Concrete consent rules for agents that reach tools through MCP, including showing the exact command before a local install runs.
- Human in the loop for AI agents: HITL in practice, AELSHA™ NEHEMVIX: Where one agent's code makes a person approve, and where a person only supervises.
OWASP's lists, the MCP specification and NIST's frameworks change between editions, and EU regulations can be amended, so check the linked documents for the current version before you build on them.