AI agent permissions determine whether a useful assistant remains a bounded tool or becomes an uncontrolled operator. The distinction matters because modern agents do more than generate text. They can browse, run code, open files, call APIs, send messages and change production systems. A model error that once produced a bad paragraph can now become a deleted record, leaked document or unauthorised transaction.
The safest starting point is simple: an agent should receive the minimum authority needed for one defined task, for the shortest practical time, with independent logging and a reliable stop path. “It needs access to work” is not a permission design. The operator must identify which resources, actions and destinations are genuinely required.
This checklist translates that principle into 12 controls. It complements the architectural lessons in our AI agent sandbox escape explainer and the scenario planning in the AI agent and human concierge travel disruption matrix. OpenAI’s guidance on running coding agents safely and designing agents to resist prompt injection provides useful primary context.
The 12-control decision matrix
| Control | Question to answer before launch | Minimum acceptable evidence | Stop condition |
|---|---|---|---|
| 1. Task boundary | What exact outcome may the agent pursue? | Written scope and prohibited actions | Objective is ambiguous or open-ended |
| 2. Resource inventory | Which files, systems and accounts are required? | Named resource list | “All company data” or equivalent broad grant |
| 3. Least-privilege role | What is the narrowest role that can complete the task? | Read/write operations mapped separately | Administrator access without necessity |
| 4. Time limit | How long should authority remain valid? | Expiry time or per-run credential | Long-lived reusable secret |
| 5. Approval policy | Which actions require a human decision? | Action-level approval matrix | High-impact action can execute silently |
| 6. Network egress | Which destinations may the agent contact? | Default-deny allow-list | Unrestricted internet access without justification |
| 7. Secret handling | How are credentials issued and protected? | Brokered, scoped, ephemeral credential | Secret embedded in prompt, file or log |
| 8. Data boundary | What information may enter or leave the model context? | Classification and redaction rules | Sensitive data has no handling rule |
| 9. Tool constraints | What can each tool actually do? | Narrow operation schema and input validation | General shell or browser has ambient authority |
| 10. Monitoring | Who sees unusual behaviour in real time? | Independent action, network and policy logs | Agent controls or can erase its own audit trail |
| 11. Kill and recovery | How is the run stopped and damage contained? | Tested revoke and rollback procedure | No named owner or termination path |
| 12. Post-run review | How are permissions and outcomes reconciled? | Completion receipt and access revocation | Credentials remain active after the task |
Passing the checklist does not make an agent infallible. It makes failure more visible, more contained and easier to reverse.
1. Define the task boundary
Start with an outcome that can be tested. “Manage my inbox” is too broad. “Label unread supplier messages received in the past 24 hours and draft replies without sending them” is materially safer. It establishes a time window, a data set and a boundary between reversible preparation and external action.
Write prohibited methods as well as the desired result. An agent asked to reduce cloud cost should not terminate production resources merely because that improves the metric. A research agent should not purchase access, create accounts or contact sources unless those actions are separately authorised.
The boundary belongs in machine-enforced policy where possible. Prompt instructions are useful context, but they are not a security control on their own.
2. Inventory every required resource
List the systems the task genuinely needs: one mailbox, one folder, one repository, one analytics property or one customer record set. Then list what it does not need. This negative inventory often reveals unnecessary authority.
Resource boundaries should be explicit identifiers rather than descriptions such as “the marketing drive”. If the agent needs three files, share those files, not the whole drive. If it needs one branch, avoid a token that can alter every repository in the organisation.
Dependencies deserve the same scrutiny. A tool may call a third-party search provider, package registry or storage service even when the agent does not display that connection to the user.
3. Separate read, prepare and commit
Permission systems often distinguish only read and write, but agents benefit from a three-stage model:
Read: inspect information without changing external state.
Prepare: create a draft, plan, patch or mutation preview in a controlled workspace.
Commit: apply a change to the source system or communicate externally.
Preparation makes review possible. An agent can assemble a proposed calendar change, email or database mutation without executing it. Commit authority can then be limited to cases that meet policy or receive approval.
This separation is especially valuable for payments, publication, account administration, customer communication and production deployment. A preview should show the destination, scope and expected effect—not merely ask “Allow?”.
4. Make authority expire
Persistent credentials create persistent risk. Prefer per-run or short-lived tokens issued by a credential broker after the task and policy are known. Bind the credential to a resource, operation and expiry.
A coding agent analysing a repository might receive a one-hour read token. A deployment agent may receive a write token only after tests pass and the exact target revision is fixed. An assistant scheduling a meeting may receive authority for one calendar and no permission to read private attendee notes.
Expiry is not a substitute for revocation. Operators need a way to terminate credentials immediately when behaviour changes or a device is compromised.
5. Attach approval to impact
Human approval is useful only when the person can understand the proposed action. A generic prompt after hundreds of hidden steps transfers responsibility without transferring information.
Create an approval matrix based on impact:
| Action class | Examples | Suggested policy |
|---|---|---|
| Read-only, low sensitivity | Public web research, approved documentation | May run automatically with logging |
| Reversible internal change | Draft, label, test branch, sandbox record | Automatic or batched review |
| External communication | Send email, publish post, message customer | Preview plus named approval or standing scoped policy |
| Financial or access change | Purchase, refund, role grant, key rotation | Explicit transaction-level approval |
| Destructive or safety-critical | Delete production data, disable controls | Deny by default; exceptional supervised procedure |
Standing approval can be appropriate for a tightly bounded recurring workflow. It should identify the system, action type, quality gates and failure behaviour. It should never become a blanket “do anything” permission.
6. Default-deny network access
An agent with a browser or code runner may contact destinations the operator never intended. Network egress should therefore begin denied and allow only required domains, protocols and methods.
Route outbound traffic through an inspected proxy. Record destinations, response status and transfer volume. Apply rate limits. Block cloud metadata endpoints and internal control planes unless the task specifically requires them.
An allow-list is strongest when it uses the actual service identity, not a broad wildcard. Package and content-delivery networks complicate this design, but complexity is not a reason to grant the whole internet by default.
7. Keep secrets outside the prompt
Prompts, tool output and model context may be stored, copied into logs or exposed through prompt injection. Long-lived secrets do not belong there.
Use a broker that performs the privileged call or injects an ephemeral credential without revealing it to the model. Redact authentication headers from traces. Prevent tools from reading environment variables or credential files that are unrelated to the task.
Test failure paths. A verbose error can reveal a token even when the successful response does not. Logs should retain enough evidence for audit while excluding reusable credentials and personal data that the reviewer does not need.
8. Classify data before it enters context
The agent’s data boundary is as important as its action boundary. Define which classes of information may be processed: public, internal, confidential, regulated or personally identifiable.
Apply minimisation. A travel assistant may need itinerary dates and loyalty status but not a complete passport scan for every planning step. A support agent may need one conversation, not the customer’s entire history. Replace direct identifiers when they are unnecessary.
Consider where the model and connected tools process data, how long they retain it and whether data can be used for training. These answers can differ by product tier and configuration, so verify current contractual and technical documentation.
9. Constrain tools, not just models
A narrow tool is easier to reason about than a general shell. “Create a draft in folder X” exposes less power than “run arbitrary commands with a storage token”. Tool schemas should validate destinations, identifiers, file types, size and permitted operations.
Treat browser automation as privileged. A browser may inherit sessions for banking, email, cloud consoles and social accounts. Use an isolated profile with only required sessions, and prevent access to local browser data.
Tool output is untrusted input. A webpage, document or issue comment may contain instructions intended to redirect the agent. The control plane should distinguish data from policy and prevent external content from changing the permission model.
10. Monitor independently
Record the task, model, tools, approvals, resource identifiers, actions, policy decisions and final outcome. Logs should use a shared run identity so that an external mutation can be reconciled with the instruction and review that authorised it.
Monitoring must operate outside the agent’s authority. If the same token can change a record and erase the evidence, the audit trail is not reliable.
Alert on unusual destinations, repeated denials, privilege escalation, large data transfer, action bursts and attempts to access secrets. A denied action is not merely noise; it may reveal a flawed plan or adversarial input.
11. Test the kill switch and recovery path
A stop button that has never been tested is an assumption. Verify that operators can cancel the run, revoke credentials, close sessions and isolate affected resources. Assign a person or on-call role to receive alerts.
Recovery should match the action. Database changes may require an immutable transaction log and compensating mutation. Publication may require revision history and rollback. A sent message cannot truly be recalled, which is why external communication deserves a higher gate.
Run tabletop exercises. Ask what happens if the agent sends data to an unapproved domain, receives a malicious document, loops on a tool call or acts after the user believes it has stopped.
12. Close the run
Completion is an operational phase, not the absence of more tool calls. Revoke temporary credentials, close browser sessions, reconcile intended and actual changes, preserve a redacted evidence package and schedule any performance or safety follow-up.
The receipt should say what the agent inspected, changed, skipped and could not verify. Missing source data must remain missing—not be converted into a zero or a success claim.
Review standing permissions periodically. A recurring workflow can drift as tools, schemas and business processes change. Permission that was once narrow may become broad after a new integration is added.
A practical pre-flight sequence
For most teams, the following order is workable:
classify the task and data;
identify exact resources and tools;
generate a read/prepare/commit permission map;
create expiring credentials and network allow-lists;
define approvals and stop conditions;
run in a disposable environment;
monitor actions independently;
reconcile and revoke access at completion.
If the team cannot answer one of those steps, pause before connecting the tool. The cost of clarification is usually far lower than the cost of investigating an opaque action after the fact.
The executive test
Before authorising an agent, an accountable owner should be able to answer four questions in one minute:
What exact outcome is it allowed to pursue?
Which systems can it read or change?
Which action requires a human decision?
How do we stop it and prove what happened?
If those answers are vague, the permission design is not ready. Capable agents create leverage, but leverage magnifies the quality of the surrounding operating system. Least privilege, short-lived authority, action-level approval and independent evidence are what turn autonomous capability into dependable service.
