AI Agent Permissions Matrix: Five Levels from Read-Only to Controlled Execution

AI agent permissions are often framed as a switch: the agent either recommends an action or runs autonomously. That model breaks down in real work.

The same agent may read an approved knowledge base and draft a customer response without being allowed to send it. It may update an internal task status without being allowed to change payment data. Permission belongs to a specific action, resource, audience, impact, and recovery path—not to a vague “agent role.”

The five-level matrix below is a working framework for permission reviews, not an external standard. It helps a team answer three questions: What is allowed now? What evidence justified it? Which signal immediately removes it?

Define a permission with four fields

Before choosing an autonomy level, describe each tool action:

1. Data scope: Which systems, fields, customers, and time ranges can the agent read?
2. Action type: May it retrieve, draft, write, send, delete, approve, or pay?
3. Affected party: Is the result internal, or can it affect a customer, contract, money, or public record?
4. Recoverability: Can the action be reversed, how quickly, and who owns recovery?

“Can use the CRM” is not a permission definition. “May read basic fields for assigned accounts, may not export contacts, and may draft a follow-up that requires business-owner approval” is much closer.

A five-level AI agent permissions matrix

Level	Default agent action	Human control	Typical boundary	Evidence to advance
L0 — Observe	Read approved sources, retrieve, and summarize	A person performs every business action	No write, send, or state change	Reliable sources, complete citations, no unauthorized reads
L1 — Draft	Prepare candidate content, fields, or task cards	A person edits and approves every output	No automatic send or external commitment	Stable acceptance and correction cost; zero severe errors
L2 — Approved execution	Run one reversible action after approval	A person checks parameters and approves	No payment, signature, master-data deletion, or self-escalated access	Stable execution and rollback; actionable handoff
L3 — Controlled automation	Run normal, low-risk, reversible internal actions	People handle exceptions and sample normal work	No irreversible action or unscripted external commitment	Normal-case threshold met; controlled exception and recovery rates
L4 — Bounded external execution	Act externally within allowlists, templates, and limits	People approve high-impact actions and govern the boundary	No contracts, payments, legal commitments, or access changes	Quality, customer outcomes, and audit evidence hold over time

A higher level does not mean the agent is “smarter.” It means one defined action has more authorization. An agent can be L3 for internal status synchronization and L1 for a customer quote.

Least privilege does not mean permanent read-only access

Least privilege means granting only the smallest permission required and supported by current evidence. It does not require every production agent to remain at L0.

Advance one action at a time:

• from one approved source to specific fields within that source;
• from a draft to an approved write-back;
• from mandatory approval to normal-case automation;
• from internal action to a template-based action for an allowlisted recipient.

Do not open an entire tool or account because one task performs well. Tool-level access is too coarse. Resource, field, object, action, and limit controls are the useful unit.

Every permission increase needs four controls

1. Observable failure signals

Define failure before launch: missing fields, conflicting rules, an unknown recipient, a limit breach, duplicate action, customer complaint, or output that cannot cite the current rule version.

2. An audit trail

Record the original input, source and version, material decisions, action parameters, approver, execution result, and later correction. Logging only the model response does not audit the business action.

3. Rollback or remediation

Every write or send action needs a recovery path: undo, restore a prior version, send a correction, freeze the permission, or return the task to a person. An irreversible action should not be approved by model confidence alone.

4. A human owner

Permission is not an engineering-only decision. The business owner accepts the trade-off, the process owner maintains rules and exceptions, the system owner controls access and audit, and the exception owner receives out-of-bound work.

A tool-level review table

Tool or system	Resource scope	Read	Draft	Write	External send	Delete/payment	Owner	Handoff trigger
Knowledge base	Published SOPs	Allow	N/A	Deny	Deny	Deny	Process owner	Two active rule versions match
CRM	Basic fields for assigned accounts	Allow	Allow	After approval	Approved template only	Deny	Business owner	Unknown contact or sensitive field
Ticketing	Current queue	Allow	Allow	Reversible state update	Internal reminder	Deny	System owner	Duplicate ticket or state conflict
Email	Allowlisted domains and templates	Restricted read	Allow	N/A	After approval	Deny	Business owner	Unknown recipient or unscripted commitment

“Allow” still requires identity, field, and limit controls. The table is an input to a review, not a permanent access token.

A synthetic freight-inquiry example

This example explains the method and does not represent a real customer or transaction.

At a freight inquiry entry point, an agent may begin at L0 by reading submitted fields and the current SOP. At L1 it can prepare a missing-field list and response draft. At L2 an operator can approve creation of an internal task. Only after field validation, duplicate detection, audit, and rollback are stable should a low-risk internal status update move to L3.

Rates, service commitments, unusual customer identity, contracts, and money remain at L1 or L2. The boundary is not “95% model accuracy.” The useful questions are whether failure is visible, whether the action can be recovered, and whether the owner can intervene before impact spreads.

Immediate downgrade triggers

Pause the affected action and move it down at least one level when any of these occurs:

• a rule or version conflict;
• missing audit fields;
• duplicate execution or failed rollback;
• unknown object, cross-tenant access, or sensitive-data exposure;
• a sustained increase in exceptions;
• a customer complaint or false external commitment;
• a material business-rule, policy, or interface change.

A downgrade is not project failure. It is the permission system working. Continuing at the same boundary after a material anomaly is the real failure.

Download the worksheet

Download the AI agent permissions matrix (CSV). Start with one workflow and three concrete actions rather than scoring an entire role or system.

Then check three linked decisions: who should be the human owner?, is the SOP executable?, and what context must reach a person during handoff?. The complete sequence is in AI Agents Owning Real Work.

Evidence boundary

• Current status: a working framework for permission reviews and bounded pilots, not legal, audit, or industry certification.
• Demonstrated use: separating data, action, impact, recovery, and ownership turns abstract autonomy debates into reviewable controls.
• Still being tested: sample thresholds, acceptable exception rates, and review periods across different workflows.
• Not appropriate for automatic approval: payments, contracts, legal commitments, security configuration, and other irreversible high-impact actions.