AI agents should earn autonomy one bounded action at a time. This framework covers access levels, policy checks, promotion criteria, and production evidence.
AI agent permissions have become an operating question, not a technical footnote. On August 11, Axios reported that security practitioners who had seen agents move beyond test boundaries recommended treating them like insider threats: limit what they can access and record what they do. A second Axios report described a proposed incident-sharing framework for AI systems.
The proposal's public SAFE draft calls for preserving prompts, traces, tool calls, identities, permissions, approval events, and changed files after an incident. The point is blunt: controls must leave evidence that survives the incident itself. A successful run log is not enough when the system touches production data. That is useful guidance even if your agent is qualifying leads or updating inventory instead of running security tests. Once an agent can act, you need to know which actions were allowed, why they ran, and how to reverse them.
Teams often decide an agent's access by asking how accurate the model appears in a demo. That is the wrong variable. Permission should follow the consequence of a bad action. Drafting a CRM note and deleting a customer record may use the same model, but they should never share the same approval rule.
Start with the action, not the agent. For every tool call, record the system, data scope, allowed operation, maximum impact, approval owner, and rollback method. "Access to HubSpot" is too broad. "Read contacts created in the last seven days" is a permission. "Create a draft follow-up task without sending a message" is another.
We also separate data sensitivity from action risk. Reading a public product catalog is low sensitivity and low consequence. Reading payroll data is high sensitivity even if the agent cannot change it. Sending a customer email may touch ordinary contact data but carries reputational risk. Those cases need different controls.
Autonomy should be a sequence of earned capabilities. A practical ladder gives the agent enough access to prove useful without handing it the final action on day one.
Level | Agent capability | Example | Required control |
|---|---|---|---|
0: Sandbox | Works only with test or copied data | Classifies sample support requests | No production credentials |
1: Read | Reads a narrow production scope | Finds open orders delayed past a rule | Read-only token and access log |
2: Propose | Prepares an action for review | Drafts a reply or recommends a CRM update | Named reviewer and visible source evidence |
3: Execute reversible actions | Acts inside explicit limits | Adds a tag, creates a task, or moves a queue item | Rollback, idempotency, rate limit, and alert threshold |
4: Request consequential actions | Assembles the action but cannot finalize it | Prepares a refund, contract, deletion, or outbound campaign | Separate human approval with scoped credentials |
Level 4 is deliberately not "full autonomy." For most small and midsize businesses, final control over money movement, customer-facing commitments, mass communication, and destructive changes should remain separate from the reasoning system. An agent can do nearly all the preparation while a person retains the consequential click.
Our take is that a prompt should never be the permission layer. Telling an agent "do not issue refunds over $200" is an instruction, not a control. The refund API or policy service must reject an amount outside the approved limit even when the model asks confidently.
This separation matters because agent behavior changes with the input, surrounding context, model version, and available tools. The policy layer should be boring. It receives a structured action request and checks deterministic conditions such as customer status, amount, geography, approval state, and daily volume. Only then does it issue a short-lived credential or call the downstream system.
The same design keeps debugging manageable. If the proposed action is wrong, inspect the agent's reasoning and source data. If the action should have been prohibited, inspect the policy. Mixing those responsibilities inside one prompt makes every failure look like a model problem and every fix another sentence in an instruction block.
This is also why we recommend choosing the workflow before choosing the agent. PASMO's guide to automation prioritization explains the cost-of-error test. Apply that same test to each action the agent may take.
A useful first production version handles one narrow job at Level 1 or 2. Give it a dedicated identity, not a shared employee login. Separate read and write credentials. Log the requested action, policy decision, downstream response, and resulting record ID under one run identifier.
Before promotion, test the cases that should be denied. Try an out-of-scope customer, an amount one unit above the limit, a duplicated request, missing evidence, an expired approval, and a retry after a timeout. A system that handles the happy path but cannot prove its denials is not ready for more authority.
Promotion criteria should be written before the pilot starts. Use a review sample large enough to expose the common exception types in your workflow. Track incorrect proposals, prohibited actions caught by policy, reviewer overrides, duplicate attempts, and rollback success. Do not collapse them into one accuracy percentage. A harmless classification miss and an unauthorized send are not equivalent.
When the evidence supports promotion, add one capability at a time. Moving from draft creation to task creation is a bounded change. Adding CRM writes, email sending, and billing access in the same release removes your ability to identify which permission caused the new failure.
Over the next 6 to 12 months, our view is that agent identity will become a normal part of business-system architecture. Teams will stop treating an agent as a feature inside an app and start treating each deployed agent as a worker with an owner, purpose, credential set, action budget, and expiration date.
We would also expect more just-in-time access. An agent will request a narrow capability for one run, the policy service will evaluate the context, and the credential will expire after the action. That model is easier to audit than placing a permanent all-purpose token inside an automation platform.
The businesses that prepare now do not need a large governance program. They need an inventory of agent identities, a permission record for every connected system, an approval path for consequential actions, and evidence that survives beyond the workflow log. Start there. More autonomy can follow when the system has earned it.
PASMO builds operational AI agents with scoped access, approval gates, audit records, and failure handling designed into the workflow. If you have an agent pilot that works in a demo but still feels unsafe in production, the permission model is usually the right place to look first.