AI Agent Permissions Matrix for the First Production Workflow
A five-level AI agent permissions matrix sets read, prepare, write, approval and action limits before the first production workflow can go live safely.
Aug 11, 2026
Insight
AI Agent Permissions Matrix for the First Production Workflow
An AI agent permissions matrix needs five levels for production: read, recommend, prepare, write with approval, and act within limits. Set the level separately for every system and action before the agent touches live customer, financial, or operational records.
That distinction matters because access is not binary. An agent may safely read an order status but still need a person to approve a refund. It may prepare a support reply but never send one when identity, policy, or account history is uncertain. The practical question is not whether the agent is autonomous. It is exactly which action it may take, on which record, under which conditions, with which evidence, and who can stop it.
Use the matrix below to scope one first workflow before comparing tools or requesting a build proposal. If you want to turn the boundary into a scoped release, Map the first AI workflow milestone.
The five-level AI agent permissions matrix
| Level | Agent authority | Human role | Suitable first use | Release evidence |
|---|---|---|---|---|
| 1. Read | Retrieve only the fields required for the task | Review access scope and unusual lookups | Order status, policy lookup, account summary | Field allowlist, identity test, access log |
| 2. Recommend | Produce a suggested decision without changing a system | Accept, edit, or reject the recommendation | Ticket routing, lead priority, next action | Evaluation set, reason code, human feedback |
| 3. Prepare | Create an unsent or uncommitted object | Inspect the exact object before commitment | Reply, quote, task, refund request | Preview, source links, edit history, expiry |
| 4. Write with approval | Commit a specified change after named approval | Approve the proposed change within a time limit | CRM update, ticket status, payment exception | Before and after values, approver, timestamp, rollback |
| 5. Act within limits | Complete a reversible, bounded action automatically | Review exceptions and periodic samples | Low-risk reminder, internal task, known-status update | Policy check, limit check, result read-back, alert |
The matrix should be applied per action, not per agent. One agent can sit at Level 1 for billing data, Level 3 for customer replies, and Level 5 for internal follow-up tasks. A single label such as "read and write access" hides too much.
Start with one outcome and one system boundary
Choose a workflow with one measurable operating result and a named owner. Good first candidates are narrow enough to observe end to end: route an inbound ticket, prepare a renewal reminder, enrich a qualified lead, reconcile a known invoice field, or assemble an account summary before a call.
Write the outcome as a state change. "Help the support team" is vague. "Prepare a reply for delivery-status tickets and attach the source order record" can be evaluated. The second version identifies the user, trigger, data source, proposed output, and point where a person remains responsible.
Then name the system boundary. Record the objects the agent may access, the fields it needs, the actions exposed through tools, and the actions that remain unavailable. If the first release needs three CRMs, two helpdesks, broad file storage, unrestricted email, and finance access, it is not one first workflow.
The AI agent pilot plan can help sequence the workflow after this permission boundary is clear.
Level 1: read only what the task requires
Read access still needs design. A customer-support agent may need order number, fulfilment status, promised date, and approved policy text. It may not need full payment details, every prior conversation, internal margin, or records from other customers.
Give the agent its own identity where the platform supports it. Avoid sharing a broad employee account or long-lived credential. Bind the identity to the minimum systems, objects, fields, tenants, and time window needed for the task. Microsoft describes agent identities as specialized identity accounts for AI agents and highlights the need for right-sized access across systems.
Define the read-back evidence too. Every lookup should identify the agent, requesting workflow, target object, fields returned, time, and outcome. Sensitive lookups should be reviewable even when no write occurs.
The separate AI agent security checklist covers broader security testing. This matrix stays focused on action authority for one workflow.
Level 2: recommend with a reason and evidence
At Level 2, the agent may classify, prioritise, or suggest, but the business system remains unchanged. This is often the safest place to evaluate whether the agent understands the workflow before adding action authority.
Require a structured recommendation rather than a free-form answer. A lead-priority recommendation might include the proposed status, permitted reason code, source fields used, missing evidence, confidence policy, and next human action. A support-routing recommendation might include the queue, urgency, cited policy, and why another queue was rejected.
Do not turn a numeric confidence value into automatic permission. Confidence can support routing, but the release rule should also consider action impact, data completeness, policy coverage, customer state, and whether the result can be reversed.
Sample normal, ambiguous, and adversarial cases. Record accepted, edited, and rejected recommendations. Repeated edits in the same category usually mean the task definition, source data, or decision policy needs work.
Level 3: prepare the exact change without committing it
Preparation is the bridge between advice and action. The agent can assemble an email, CRM note, quote, task, or refund request, but the object remains unsent or uncommitted until a person sees the exact change.
The preview must show more than polished prose. Show the target account, destination, source records, selected policy, changed fields, amount or quantity where relevant, and any missing evidence. Make stale proposals expire so yesterday's context cannot be approved after the underlying record changes.
Use code to supply values the application already knows. OpenAI's function-calling guidance recommends making invalid states difficult to represent and not asking a model to fill arguments already known by the application. That principle reduces the space in which a model can invent an identifier, recipient, or amount.
A prepared action should be editable. Capture what the person changed and why. That feedback is useful evidence for narrowing the instruction or deciding that the workflow is not ready for more authority.
Level 4: write only after named approval
At Level 4, a person approves a specific proposed change. Approval should bind to the exact object, values, destination, policy version, and time window shown in the preview. A general approval to "handle these tickets" is not the same control.
Separate the person who configures the workflow from the person who approves sensitive actions where the business impact requires it. Define which roles may approve which action classes and thresholds. Expire an approval when the source record changes, the policy version changes, or the time window closes.
Before commitment, check that the approver is authorised, the target still exists, the proposed value remains valid, and the action has not already happened. After commitment, read the record back and compare it with the approved change. Keep the prior value or a compensating action when rollback is possible.
The human-in-the-loop approval framework explains where human checkpoints belong when an incorrect action is expensive.
Level 5: act automatically only inside explicit limits
Automatic action is suitable when the action is low impact, repeatable, reversible, and supported by complete evidence. The agent still needs a policy boundary. Define permitted action types, field values, recipients, amounts, frequency, hours, volume, customer state, and stop conditions.
For example, an agent may create an internal follow-up task for an existing account when the owner field is present and no open task exists. It should not assign a new owner, email the customer, alter an opportunity value, or create duplicate tasks. Each additional action is a separate permission decision.
Use transaction controls where possible. Idempotency prevents a retry from repeating the same action. Rate limits contain volume. Allowlists constrain destinations. A policy service can reject disallowed combinations before the tool runs. Read-back confirms the intended state actually changed.
Route uncertainty and tool failures to a defined exception path. The AI exception-handling workflow shows how to assign exceptions, retries, fallbacks, and ownership without hiding failure.
Apply the matrix to three common workflows
| Workflow | Read | Recommend | Prepare | Write with approval | Act within limits |
|---|---|---|---|---|---|
| Customer support | Order status and approved policy | Queue, urgency, resolution path | Customer reply and internal note | Update case status or approved exception | Create a low-risk internal follow-up task |
| Sales operations | Account and activity fields | Lead priority and next action | CRM note and follow-up task | Update stage after owner review | Enrich approved fields from an allowed source |
| Finance operations | Invoice, purchase order, receipt fields | Match result and discrepancy reason | Reconciliation entry or exception request | Commit an approved correction | Mark an exact match within defined tolerances |
These are examples, not universal permissions. The same action can carry different impact in different businesses. A status change that is reversible in an internal queue may trigger customer communication, billing, or fulfilment elsewhere.
If your first workflow crosses several systems or contains sensitive writes, Map the first AI workflow milestone before choosing an implementation sequence.
Define identity, data, action, and approval together
A useful permission decision has four connected parts. Identity defines which agent or delegated user is acting. Data defines which tenant, object, record, and field it may use. Action defines the tool, operation, parameters, and limits. Approval defines when a person must inspect and authorise the exact change.
If one part is missing, the boundary is incomplete. A tool allowlist without field restrictions can still expose unnecessary data. Role-based access without action limits can still permit a broad write. A human checkpoint without a clear preview can become a blind confirmation step.
NIST's AI Risk Management Framework organises work across Govern, Map, Measure, and Manage. For this first workflow, translate that into named ownership, mapped context and impact, measured behaviour, and managed response. The matrix is not a substitute for the wider framework. It is a concrete release artifact inside it.
Nine release tests before the agent can act
| Test | Required evidence | Stop condition |
|---|---|---|
| Identity | A distinct agent or delegated identity with a named owner | Shared broad credential or unknown owner |
| Data scope | Allowed systems, tenants, objects, records, and fields | Unbounded search or cross-tenant access |
| Tool scope | Exact tool and operation allowlist | Generic tool with unrelated actions exposed |
| Parameter rules | Types, required values, ranges, and allowed destinations | Free-form identifiers, recipients, or amounts |
| Approval | Named role, exact preview, expiry, and revalidation | Blanket confirmation or stale proposal |
| Reversibility | Prior value, rollback, or compensating action | Irreversible high-impact action in the first release |
| Duplicate control | Idempotency key and state check | Retry can repeat a payment, message, or update |
| Audit evidence | Identity, input references, policy result, tool call, approval, outcome | Action cannot be reconstructed |
| Stop and recovery | Rate limit, kill switch, exception owner, and recovery procedure | Failure can continue without an alert |
Run the tests with normal cases, missing fields, conflicting records, stale data, denied permissions, duplicate events, tool timeouts, malformed outputs, and attempted instruction injection. The goal is to prove the boundary holds when the workflow is incomplete or under pressure, not only when the demonstration is clean.
Monitor both the business result and the control result after release. Track how often the agent recommends, prepares, acts, requests review, receives edits, hits a policy denial, retries, fails, or is rolled back. The production AI monitoring guide provides a wider operating view for quality, latency, cost, exceptions, and ownership.
What the first scoped milestone should contain
A strong first milestone names the workflow, user, trigger, systems, agent identity, allowed data, allowed tools, permission level per action, approval path, evaluation set, exception path, logs, rollback, operating owner, and release evidence. It should also state what the agent will not do.
This boundary lets a delivery partner estimate integration, application, policy, evaluation, and operating work without hiding risk inside a feature list. It also gives a finance or operations leader something concrete to compare across proposals. KUMO's AI workflow automation service connects that boundary to implementation, integration, evaluation, and release work for the first production milestone.
KUMO builds production AI and custom software for growing businesses. For an example of milestone-led product delivery and ownership, read the Volopay case study. To discuss a first workflow that can be tested without granting broad authority, Map the first AI workflow milestone.
Frequently asked questions
Should an AI agent start with read-only access?
Usually, yes. Read-only access gives the team a way to test retrieval, identity, field scope, tenant boundaries, and audit evidence before the agent can change a system. A narrow preparation step can follow once the read boundary is reliable.
Is human approval enough to make an agent action safe?
No. The person needs an exact, current preview plus authority to approve that action. The system should also validate parameters, prevent duplicates, expire stale proposals, record the decision, read the result back, and support recovery.
Can one AI agent have different permission levels in different systems?
Yes. Permission should be assigned per system and action. The agent may read customer history, prepare a reply, update an internal task after approval, and remain blocked from payment or identity changes.
When can an AI agent act without approval?
Use automatic action only when the task is low impact, bounded, reversible, observable, and supported by complete evidence. Set limits for destinations, values, frequency, volume, customer state, and stop conditions.
What should a buyer ask an AI development partner to deliver?
Ask for the action matrix, identity design, tool and data allowlists, parameter validation, approval flow, evaluation set, audit evidence, duplicate control, rollback, exception ownership, and operating runbook for the first workflow.
Sources
NIST AI Risk Management Framework Playbook
Microsoft guidance on least privilege for AI agents