AI Agent Authorization: Permission Tiers That Grow With Trust

AI agent authorization is the set of rules that decide what an agent may read, change and send, and who must approve each kind of action. The most dependable way to set those rules is with permission tiers: the agent starts at the lowest tier and moves up one step at a time, only when logged evidence shows it behaves reliably at its current level. Capability does not earn authority. A track record does.

Key takeaways

• Authority should follow evidence from your own environment, not the agent's reputation or raw capability.
• Define a small number of tiers, from observing to acting alone within limits, and keep a reserved list of actions that always need a person.
• Promotion needs written criteria: enough real cases, reviewed errors sorted by type, passing evaluations, complete logs and a named owner who signs off.
• Enforce tiers in credentials and the tool layer, never in the prompt alone, and give the agent its own identity.
• Plan for demotion as carefully as promotion, so a drop in authority is a routine, blameless step.

Why should authority follow evidence instead of capability?

Discussions about very capable, even superintelligent, agents often treat authorization as something to relax as the system gets smarter. The safer instinct is the opposite. The more an agent can do, the more a wrong permission costs, and the less likely a human reviewer is to catch a mistake by glancing at the output.

Capability tells you what an agent might do in general. Evidence tells you what it does with your data, your inconsistent inputs, your customers and your exceptions. A skilled new hire is a fair comparison. Nobody doubts their talent, yet they do not get payment approval rights on the first day. They earn scope as colleagues watch their work hold up.

There is also an accountability reason. When something goes wrong, someone must be able to explain who allowed the action and on what basis. A tier with written promotion criteria gives you that answer in advance. Frameworks such as the NIST AI Risk Management Framework ask organizations to assign roles and to measure and manage risk continuously, and a tier review is a concrete way to do exactly that.

What are the permission tiers?

Five tiers are enough for most roles. Name them plainly so the owner, the technical team and any auditor read them the same way.

• Tier 0, Observe: the agent reads a narrow, approved set of sources and produces nothing that anyone outside the pilot sees. Its proposed outputs are compared with what humans actually did.
• Tier 1, Draft: the agent writes drafts, summaries or proposed records into a review queue. A person sends, saves or applies everything.
• Tier 2, Act with approval: the agent prepares a complete action, such as a record update or an outbound message, and a person approves each one before it executes.
• Tier 3, Act within limits: the agent executes a defined list of low-risk, reversible actions alone, inside caps on volume, recipients and scope, and a sample of its work is reviewed afterward.
• Tier 4, Act with exception review: the agent handles a wider range of actions, and a person reviews only exceptions, flagged cases and periodic samples.

Above all of these sits a reserved list: actions that always need a person, whatever the tier. Typical entries are anything irreversible, payments or refunds above a limit you set, legal or contractual commitments, deleting records, messages to regulators, and any change to the agent's own permissions. The agent must never be able to promote itself.

Tiers apply per task, not per agent. The same agent can sit at Tier 3 for sorting incoming requests and at Tier 1 for replying to a complaint. Think of authority as a table of tasks and tiers rather than a single dial. Read access counts as a permission too, so even Tier 0 should begin with the smallest set of sources the role needs, as described in least privilege for AI agents.

What evidence should move an agent up a tier?

Promotion should be a decision with a record, not a feeling that things look fine. Before an agent enters a tier, write down what it must show in order to leave it. A workable checklist:

• Volume: a stated count of real cases handled at the current tier, chosen by you according to how varied the work is. Time passing is not evidence if few cases arrived.
• Error review: every correction by a reviewer is tagged by type, such as wrong fact, wrong tone, wrong tool, missed escalation or out of scope.
• Severity: no severe errors in the review window, and each minor error type is either gone or well understood.
• Evaluations: the agent passes a fixed set of test cases, including awkward ones, and the set grows each time a new failure is found.
• Escalation behavior: when a situation was unclear or outside scope, the agent stopped and asked instead of guessing.
• Traceability: logs show what the agent read, which tool it called, with what parameters, and who approved the step.
• Sign-off: a named business owner, not only the technical team, approves the move in writing.

Escalation behavior deserves extra weight. An agent that knows when to stop is safer at a higher tier than one that is slightly more accurate but never hesitates. For where to place those stops, see where your AI agent should stop and ask. The review rhythm itself can borrow from reviewing an AI agent like a role: goals, evidence, feedback and changes.

Promote one task and one tier at a time. If you widen the data sources, the tools and the tier together, you cannot tell which change caused a problem.

How do you enforce tiers so the agent cannot talk its way past them?

A tier that exists only in a system prompt is a request, not a control. Models can misread instructions, and text inside a document or email can try to override them. Enforcement belongs in the layers the model cannot rewrite.

• Separate identity: the agent has its own account, never a person's login, so its actions are attributable and its access can be revoked without affecting anyone else.
• Scoped credentials: grant only the scopes the tier needs. Authorization standards such as OAuth 2.0 are built around scopes, so a Tier 1 agent can receive read access and draft creation without send access.
• Tool-layer checks: every tool call is checked against the tier table for that task before it runs, and denied calls are logged.
• Hard limits: caps on volume, recipients, amounts and time windows live in the tool, not in the instructions.
• Approval gates: for Tier 2, the execute step is a separate action that only a human can trigger.
• Kill switch: one documented way to suspend the agent's credentials immediately.

This is also your defense against prompt injection and what the OWASP Top 10 for LLM Applications calls excessive agency. If a malicious instruction slips into a document, the damage is limited to what the current tier permits. OWASP's general authorization guidance recommends denying by default, enforcing least privilege and checking permissions on every request, and the same discipline applies to each tool call an agent makes.

What does promotion look like in practice? An illustrative scenario

Illustrative scenario: a distribution company wants an agent to chase overdue invoices.

At Tier 0, the agent reads the open invoice list and the customer notes. Each week, its suggested reminder is compared with what the accounts team actually sent. At Tier 1, it writes reminder drafts into a queue and the team edits them. The team tags the edits and notices that many corrections concern tone toward long-standing customers, so a rule and several new test cases are added.

At Tier 2, the agent prepares each email and the collections owner approves them one by one. After a long run of approvals with few edits, and after the agent has correctly escalated every case where a customer disputed an invoice, the owner promotes a single task to Tier 3: first reminders for invoices that are only slightly late, with a daily cap on sends. Payment plans, disputes and write-offs stay on the reserved list.

Later, a reminder reaches a contact who has left the customer's company. The owner moves that task back to Tier 2, the team fixes the contact data at its source, and the task is promoted again once the checks pass. Nobody was blamed, and the table now records why the change happened.

How do you start, and when should an agent move down a tier?

You can set this up for a single role in a short working session. Follow these steps:

• List the tasks in the role and write the worst realistic outcome if each one goes wrong.
• Mark the reserved actions that always need a person.
• Assign every task a starting tier, usually Tier 0 or Tier 1.
• Write the promotion criteria for each task before the agent starts work.
• Configure identity, scopes, limits and logging to match the table.
• Schedule a recurring review where the owner looks at errors, evaluations and the tier table.
• Record each promotion or demotion together with the evidence behind it.

Define demotion triggers up front as well: a severe error, a new tool or data source, a policy change, or a pattern of reviewer corrections that keeps returning. A change of underlying model deserves special mention. It can alter behavior without any change in your configuration, so rerun the evaluations before the agent keeps its tier. If a real incident occurs, follow a written plan such as how to respond to an AI agent incident. Demotion should feel like a routine step in the process, not a verdict on anyone's work.

How does Be Human handle permission tiers?

In a first engagement, Be Human defines one useful role together with the memory and tools it needs, the approval boundaries and an observable success criterion. The tier table is part of that definition: each task starts at the lowest tier that is still useful, and the reserved actions are written down. In managed operations, Be Human monitors the agent, runs recurring evaluations, reviews permissions, maintains integrations and handles incidents. Changes to a tier are made as controlled improvements, with the client's owner approving each one and keeping control of the human approval points.

Frequently asked questions

What is the difference between authentication and authorization for an AI agent? Authentication proves which identity is acting, and authorization decides what that identity is allowed to do. An agent needs both, and it should have its own identity so that every action can be traced and its access revoked without disturbing a person's account.

How many cases are enough before promoting an agent? There is no universal number. The reviewed sample should include routine cases and the awkward ones the task really produces. Set the count for each task before the agent starts, and raise it for actions with a higher cost of error.

Should a more advanced model get a higher tier automatically? No. A new model resets the evidence for your workflow, even if it is stronger in general. Keep the current tier, rerun your evaluations and promote only if the results and the reviewed cases support it.

Can an agent ever reach full autonomy? For narrow, reversible tasks, Tier 4 comes close, but it still includes exception review and an audit trail. Reserved actions should stay with people, and some decisions may carry legal duties for human oversight, so check the rules that apply to your company before widening scope.

Be Human editorial guidance. Examples are illustrative unless explicitly attributed. Sources provide background; implementation choices depend on your workflow.