Eighty percent of enterprise applications shipped or updated in early 2026 embed at least one agent. Almost none of those agents had their permissions designed. They inherited whatever access made the demo work, usually an existing service account with broad rights, chosen by someone trying to prove a concept rather than to survive an audit.
That is an unremarkable way for software to start. It becomes a problem because agents are different from the automation that came before them in one specific way, and the way permissions are usually assigned does not account for it.
Why an agent is not a script with better vocabulary
Traditional automation does a fixed thing. A nightly job reads a table, transforms it, writes a file. You can enumerate everything it will ever do, because the code enumerates it.
An agent decides. Given a goal and a set of tools, it chooses which tools to use and in what order, and that choice depends on input you do not control. The same agent that usually reads a record might, given unusual input, decide the sensible next step is to update several.
So the permission question changes shape. For a script you ask what it does. For an agent you ask what it could do with the access you granted, across every path it might reasonably take. Those are very different questions and the second one is rarely asked.
Least privilege gets abandoned during the pilot
The pattern is consistent and worth recognising because it is probably happening in your organisation now.
Someone builds a proof of concept. It fails with a permissions error. Rather than work out the minimum grant, which takes a day, they use an account that already has broad access, because the point of the week is to show whether the idea works at all. It works. Everyone is impressed.
Then it goes to production, and the credentials go with it. There is no moment in that sequence where anyone reviews the access, because the pilot was about feasibility and the production launch was about the launch. The permissions were decided by accident and are now load bearing.
This is worth catching precisely because it is nobody's mistake. It is a gap between two phases, and the fix is to put a review in the gap.
We have yet to review an agent deployment where the pilot permissions were narrowed before production. They are granted broadly to get something working, the demonstration succeeds, and the scope becomes permanent because nothing forces a second look.
Scope by capability, not by convenience
Start from the task rather than from the account. Write down what the agent must be able to do, phrased as verbs on specific things. Read customer records in this table. Create a draft reply. Update the status field to one of three values.
Then grant exactly that, and notice what falls away. Most agents that were given write access to a database need to write one column on one table. Most that were given a general API key need three endpoints. The gap between what was granted and what is needed is usually enormous, and closing it removes most of the risk without changing the behaviour at all.
Pay particular attention to delete and to anything that sends. Deletion is rarely required and almost always granted as part of a broader role. Sending, whether email, messages or webhooks, is how a contained problem becomes a customer facing one, and it deserves an explicit decision rather than inheritance.
Where an action is genuinely high consequence, put a person in the path. An agent that drafts and a human who sends is a completely different risk profile from an agent that sends, and for many workflows the difference in speed is negligible.
Untrusted input reaches further than you think
An agent that reads customer emails is processing text written by strangers. An agent that summarises support tickets is doing the same. If that text can influence what the agent does next, then whoever wrote it has partial influence over your system.
This is the practical reason to separate the instructions from the data. Content the agent has been asked to work on should be treated as material to analyse, never as directions to follow, and the boundary needs enforcing in how the system is built rather than assumed.
The containment that matters most is still the permission grant. An agent that cannot delete cannot be persuaded to delete, whatever appears in an inbound message. Every other control is probabilistic; that one is not.
You need a record of what it did
When something goes wrong with an agent, the first question is what it actually did, and a surprising number of deployments cannot answer.
Log the decision, not just the outcome. Which tool was invoked, with what arguments, in response to what input, and what came back. Outcome only logging tells you a record changed and leaves you unable to reconstruct why.
This matters commercially as well as operationally. When a customer asks why a decision went the way it did, an answer assembled from logs is worth considerably more than an apology. We covered the customer facing version of this in building an AI audit trail; this is the same discipline applied to actions rather than answers.
The question we ask first is what the agent did last Tuesday, and most teams cannot answer it. That is usually the finding that moves this work up the list, because it is the one nobody argues with.
A review that takes an afternoon
For each agent in production, answer four questions in writing.
What account does it authenticate as, and what can that account reach beyond this agent's task. What is the worst single action it could take with current permissions. Could untrusted input influence which tool it calls. If it behaved incorrectly for a week, how would you know.
Most teams doing this for the first time find at least one agent with far more access than its job requires, and usually one where the answer to the last question is that they would find out from a customer. Neither finding is unusual and both are cheap to fix once seen.
That same over scoped access is what an attacker inherits along with the credentials, and it is now traversed in hours rather than weeks, as we covered in the intrusion that took ten hours.
If you are putting agents into production and want the access model designed rather than inherited, our AI tools development team scopes permissions as part of the build.
Frequently Asked Questions
Is this not just standard application security?
The principles are the same and the application differs in one important way. Conventional software has a fixed set of actions you can enumerate from the code. An agent selects its actions at runtime based on input, so you are securing a range of possible behaviours rather than a known list. Least privilege matters more, not less, because you cannot fully predict the path.
How do we work out the minimum permissions?
Run the agent in a staging environment with logging on everything and deliberately restrictive access, then grant only what it demonstrably fails without. It is slower than starting broad and takes a day rather than a week. The output is a documented list of exactly what it needs, which is also what an auditor will ask for.
Should agents have their own accounts?
Yes, one per agent rather than a shared service account. Shared credentials make it impossible to tell which system took an action, and impossible to revoke access for one agent without breaking others. Separate identities cost nothing and make both investigation and revocation straightforward.
What about agents that only read?
Read access is genuinely lower risk and it is not no risk. An agent that can read every customer record can surface information to someone who should not see it, particularly if its output reaches a wider audience than its input. Scope reads to the records the task needs rather than granting the whole table because it is simpler.
How do we handle an agent that needs broad access to be useful?
Question whether it needs the access or whether the task was scoped too broadly. An agent that must reach everything is often several agents that each need a little, which is easier to secure and easier to reason about. Where broad access is genuinely required, add human approval on the consequential actions rather than accepting the exposure.
What should we log?
The input that triggered the run, each tool call with its arguments, what each call returned, and the final action taken. Retain long enough to investigate something reported weeks later, which is usually longer than default retention. Logs that expire before the complaint arrives are not much use.
Who should own this review?
Whoever owns access management for the rest of your systems, with the engineer who built the agent in the room. It fails when it is treated as an AI question rather than an access question, because it lands with people who understand the model and not the permissions model.
Talk to our team if you have agents in production and nobody has reviewed what they are allowed to do.