AI agent permissions: how to apply least privilege without slowing your team down
AI agent permissions define what each agent can read, change and execute. Learn how to apply least privilege and which actions need human approval.
On this page
The support agent was built to answer order questions. In a rush, someone connected it to the finance system “with full access, we’ll tighten it later”. Three months on, nobody tightened anything. Now there is a bot that talks to any customer on WhatsApp and can, technically, issue refunds, edit customer records and export the whole database.
Nothing has gone wrong yet. But the question is no longer “does the agent answer well?”. It is “what can this agent do if someone talks it into doing it?”.
Agent permissions are the part of governance that answers that.
What AI agent permissions are
AI agent permissions are the set of rules that define what an agent can read, change and execute in your company’s systems. Think of it as the agent’s badge: which doors it opens and which stay locked.
In practice, an agent’s permissions have three layers:
- Knowledge. Which documents and knowledge bases it can consult to answer.
- Tools. Which systems it can act on: CRM, email, spreadsheets, ERP, calendar.
- Scope inside each tool. Whether it only reads there, also writes, or can delete.
The third layer is the one people forget. “The agent has CRM access” can mean checking the status of a deal or wiping the whole pipeline. Those are very different risks hiding behind the same sentence.
There is also an important difference from human permissions. An employee with too much access still has common sense, a signed contract and a job to lose. The agent has none of that. It follows instructions, including the malicious one hidden in an email, a PDF or a customer message (the attack known as prompt injection).
It also works around the clock, at machine speed, across many conversations at once. A permission mistake on an agent scales fast.
What happens when an agent can do too much
An over-permissioned agent does things nobody asked for, and that is already the norm. In a survey by SailPoint and Dimensional Research of 353 IT and security professionals, published in May 2025, 80% of companies said their AI agents had already taken unintended actions.
What they reported:
| What the agent did | Companies reporting it |
|---|---|
| Accessed a system or resource without authorization | 39% |
| Downloaded sensitive content | 32% |
| Was tricked into revealing access credentials | 23% |
The same study shows the gap. 82% of companies already use AI agents, 98% plan to expand that use within a year, and only 44% have policies in place to secure those agents.
OWASP, the global reference in application security, named the problem in its 2025 list of risks for LLM applications: Excessive Agency. It breaks down into three root causes:
| Cause | What it means | Example |
|---|---|---|
| Excessive functionality | The agent has tools the task does not require | An agent that only needs to read email, but the integration can also send and delete |
| Excessive permissions | The tool runs with more privilege than needed | A lookup agent connected to the database with an account that can also edit and delete |
| Excessive autonomy | High-impact actions happen with nobody checking | A refund approved directly, with no person in the loop |
Notice that none of the three causes is “the model is bad”. The model can be the best on the market. The damage comes from what was left in its hands.
How to apply least privilege to AI agents
Least privilege means giving each agent only the access its task requires, and nothing more. It is an old information security principle, and for agents it comes down to five steps.
1. Write the agent’s job in one sentence. “Answer questions about order status and delivery times.” If the sentence needs three “and also”, you have two agents, not one. A clear job is what lets you say no to permissions that are not part of it.
2. List only the tools that sentence requires. For the job above: order lookup and the delivery policy knowledge base. Finance, customer records and email stay out. The right question is “what does it need for this task?”, not “what would be nice for it to have?”.
3. Inside each tool, start read-only. Most agents deliver value just by reading: they look things up, summarize, answer. Write access comes later, one action at a time, when the use case calls for it. “Update the phone number field” is one permission. “Edit customer records” is another, and a much bigger one.
4. Give each agent its own credential. Do not connect the agent with a manager’s login or the admin key “because it was already set up”. With its own credential, you can shut down one agent without taking the others down, and the logs show exactly which agent did what.
5. Separate agents by risk level. A customer-facing agent gets the tightest scope, because anyone can message it, including people who want to test its limits. An internal agent, used by a known team, can have a bit more. Merging both profiles into one agent hands the public the keys to the internal one.
The usual fear is that this slows the team down. The opposite tends to happen. A narrowly scoped agent gets approved faster, because security and legal can assess the risk in minutes. What stalls projects is the agent that “does everything” and that nobody dares to sign off on.
Which actions should require human approval
Any action that moves money, cannot be undone or leaves the company in its name should go through human approval. Everything else can run on its own.
A simple scale to classify actions:
| Type of action | Example | How to handle it |
|---|---|---|
| Read and look up | Check order status, summarize a contract | Automatic |
| Write reversible data | Create a task, log a note in the CRM | Automatic, with logging |
| Send outside the company | Customer email, proposal, bulk message | Approval until the agent proves consistent |
| Move money | Refund, discount, payment | Always approval, or a value cap |
| Delete or change in bulk | Delete records, change prices across the catalog | Always approval |
A value cap handles the gray area well. A support agent can issue refunds of up to $10 on its own and escalate anything above that. The customer with a small problem gets it solved on the spot, and the worst-case cost of a mistake stays limited and known.
The same logic applies to volume. A cap on actions per hour (ten emails, five refunds) does not prevent a mistake, but it stops that mistake from repeating a thousand times before someone notices. OWASP itself lists rate limiting and activity logging as ways to limit the damage.
Human approval has a cost. If the agent asks for an OK on everything, people start approving without reading. That is why the list of actions requiring approval should be short and reserved for what really hurts.
How to review permissions without creating bureaucracy
Agent permissions need a periodic review, because access tends to grow and never shrink. Someone enables a tool for a test, the test ends, the permission stays.
A light routine, once a quarter, covers the essentials:
- Inventory. Which agents exist, who owns each one and what it is for. An agent with no owner is the first candidate to be turned off.
- Actual use versus granted permissions. If the agent has ten tools connected and the logs show it used three this quarter, the other seven go.
- Credentials. Look for keys shared between agents, logins from people who have left the company and tokens with no expiration date.
- Denied and escalated actions. Many denials can point to a missing permission, with the team working around it. No denials for months can point to a scope that is too wide.
None of this works without logs. If the company cannot see which tools each agent called, with what data and at whose request, the review turns into guesswork. Execution logs are a prerequisite for the review.
Three signs your review is overdue:
- Nobody can say, without opening the system, what the support agent is able to change.
- Some agent is running on the admin account of a tool.
- The team built agents on different platforms, each with its own way of granting access.
The third one is the hardest to fix by hand. With agents spread across five platforms, you get five permission screens, five log formats and no single place that shows the whole picture.
To start this week, pick your most exposed agent, usually the one that talks to customers. Write its job in one sentence, compare that with what it can do today and cut the difference.
If your company’s agents are scattered and each one got access in a different way, bring them into one environment: SquadOS puts your agents in a governed internal hub, with central access, an audit trail for every conversation and native guardrails.
