AI agent permissions should give an agent enough access to complete a defined job, with human approval for consequential actions and technical limits on what it can do. A support agent might retrieve an order and draft a reply automatically. Sending that reply, issuing a refund and changing the customer’s account are separate decisions.
For a business connecting AI to email, a CRM or a booking system, this is where the implementation becomes serious. A plausible answer can be corrected before anyone uses it. An incorrect action may already have reached a customer, changed a record or moved money.
Start by defining the job and its boundaries. Then choose how much freedom the agent needs inside them.
AI agent permissions cover more than access to an app
“Connect the agent to our CRM” leaves several questions unanswered. Can it see every customer? Can it edit contact details? Export the database? Delete records? Use the information in an email?
Separate the permission decision into three parts:
- Read: which information can the agent retrieve, and for whom?
- Prepare: which drafts, recommendations or proposed changes can it create?
- Act: which changes can it commit, messages can it send or transactions can it initiate?
Reading a refund policy does not authorise a refund. Drafting a quote does not authorise offering that price to a customer. AI agent permissions should distinguish each step.
Our article on RAG, fine-tuning and live business integrations explains how company knowledge and operational tools serve different purposes. Permissions determine which parts of those systems an agent may actually use.
Decide what runs automatically, needs approval or stays unavailable
A useful starting point is to classify individual actions by their consequences. Consider who could be affected, whether the result can be reversed and how far one mistake could spread.
The following is an illustrative policy for a customer-support agent, rather than a universal rule for every business.
| Action | Starting permission | Boundary |
|---|---|---|
| Retrieve an order | Automatic | Only orders the authenticated user is entitled to access. |
| Draft a customer reply | Automatic | Keep the draft internal and use approved sources. |
| Send a personalised reply | Human approval | Show the recipient and complete message before sending. |
| Issue a refund | Human approval initially | Validate eligibility, amount and original transaction. |
| Export customer records | Unavailable | Bulk export is outside this support workflow. |
| Delete an account or change staff permissions | Unavailable | Use a separate authorised process. |
These decisions can change as a workflow proves itself. A standard acknowledgement may be suitable for automatic sending from the outset. A message interpreting a complaint or promising compensation deserves more scrutiny.
Likewise, automatic refunds can make sense when eligibility is checked by software, amounts are capped and repeat transactions are prevented. The permission should describe those conditions. “Allow refunds” is too broad.
Enforce AI agent permissions outside the model
An instruction saying “never delete customer records” is useful guidance. It does not remove the ability to delete them.
If deletion is outside the job, remove that operation from the available tools and deny it in the connected system. If the agent only needs order status, expose a narrowly defined order lookup instead of unrestricted database access.
OWASP’s guidance on excessive agency recommends limiting tool functionality and permissions, requiring approval for high-impact actions and enforcing authorisation in downstream systems.
In practice, that means a refund tool should check the order, permitted amount and approval before processing the transaction. It should reject a request that breaks those rules, even if the model confidently supplies a reason to proceed.
Check how your chosen platform enforces AI agent permissions. Anthropic’s current Managed Agents documentation, for example, distinguishes automatic execution, human approval and server evaluation. It also states that these permission policies do not govern custom tools executed by your application. Those tools need their own controls. The product is currently in beta.
Read-only access still needs boundaries
An agent that cannot edit anything may still expose information to the wrong person. A sales assistant should not retrieve another team’s confidential contracts simply because its connector has access to them.
Keep the user’s identity attached to the request and check access before retrieving the data. Where the workflow runs without a signed-in user, give it a dedicated identity with access limited to its assigned job.
Microsoft’s Copilot Studio guidance makes this distinction explicit: user authentication is appropriate when tools must access information restricted to particular groups or individuals, or perform work on their behalf.
Running AI inside your own infrastructure changes where processing happens. It does not decide which employee or customer should be allowed to see a particular record.
Approval should show exactly what will happen
A prompt asking “Allow the agent to continue?” gives a reviewer very little to assess.
A useful approval request shows the proposed action: the recipient, message, record changes or payment amount, together with the information supporting the decision. For a refund, that might include the original order, the applicable policy and whether a previous refund exists.
Approval should apply to the action shown. If the recipient, amount or message changes materially, request approval again. A person agreeing to one customer reply has not authorised every subsequent message in the session.
There is also a cost to asking too often. In its account of agent containment, Anthropic describes approval fatigue and explains why enforced environmental boundaries complement supervision.
Reserve human attention for decisions that need it. Let routine preparation happen within a limited scope, then bring the reviewer a complete proposal. If nobody is available to approve a consequential action, the workflow should wait or escalate.
Test AI agent permissions against misleading inputs and mistakes
Useful testing goes beyond checking whether the agent completes a normal request. Check whether it stays inside its permissions when the information is incomplete, contradictory or malicious.
Indirect prompt injection can place malicious instructions inside content an agent reads, such as an email or document. Connecting a trusted application does not make every piece of content inside it trustworthy.
For a support workflow, test situations such as:
- A customer message asks the agent to ignore its rules and export account information.
- Two customers have similar names, but only one matches the authenticated request.
- A refund request is repeated after a timeout, creating a risk of paying twice.
- The order changes after a person approves an action but before it executes.
- The agent asks another tool or agent to perform an action it cannot perform directly.
The important result is whether the system prevents an unauthorised action. A model politely declining one test request is encouraging, but it does not establish that every route to the same action is blocked.
Also decide how operations staff can stop the workflow. They should be able to revoke its access and identify which actions completed. Keep an audit record of the relevant request, proposed action, approval and outcome, while limiting sensitive information retained in logs.
Expand permissions one workflow at a time
Begin with a job that has a clear owner and a result you can evaluate. Preparing support replies is a more manageable starting point than giving an agent responsibility for the whole customer relationship.
Before expanding AI agent permissions, examine the errors, corrections and exceptions. Does the agent select the right customer? Apply the current policy? Recognise when information is missing? Can the business detect and recover from an incorrect action?
Sometimes the next step is ordinary automation. If a rule can be checked reliably in software, that software can enforce it while AI handles variable language or prepares a recommendation. Our guide to what to automate before building custom software explores that division.
The right amount of autonomy depends on the job. Give an agent a defined responsibility, make its limits enforceable and expand its authority when the evidence supports doing so.
