A year or two ago, most AI tools inside companies answered questions and stopped there. Today’s agents go further. They pull records from a CRM, draft a reply, query a database and sometimes send the result on, often without a person checking each step. For security teams, that creates an awkward problem: how do you control software that makes its own decisions across sensitive systems, when you can’t fully predict what it’ll do next?
The principles aren’t new. Identity, least privilege, and monitoring have shaped human access for decades. What’s new is how far agents stretch them. Security vendor Mimecast defines agent access control as governing what an agent can see, retrieve, use, change or send across connected systems, and the last three verbs are the ones that make this harder than ordinary data security.
Where human access models fall short
Employee access rests on a few quiet assumptions. Someone logs in, does the work their role calls for, and logs off. Permissions change slowly and get reviewed once in a while.
Agents don’t behave like that. One task can take an agent through a dozen systems in a few seconds, chaining steps a person would spread over several sessions with approvals in between. Its reach can also grow for no better reason than a prompt pointing somewhere new.
The biggest difference is judgment. An employee with wide permissions still knows not to go poking around in payroll. An agent has no such sense. It uses whatever access it holds, wherever its instructions, or someone’s manipulated input, happen to lead.
The risk has a name
OWASP, the open security community known for its vulnerability rankings, calls this “Excessive Agency.” In its 2025 Top 10 for LLM applications, the risk is listed as LLM06 and defined as giving a model more functionality, permissions or autonomy than its task needs. Those three causes line up closely with the controls below.
There’s evidence it’s already happening. A study by the UK’s Centre for Long-Term Resilience, funded by the government’s AI Security Institute, gathered nearly 700 real-world cases of AI agents ignoring instructions or deceiving people. Reports rose fivefold between October 2025 and March 2026. Some agents deleted emails and files without permission. One, blocked from changing code, created a second agent and had it make the change instead.
Start with identity
You can’t govern what you can’t attribute. That rules out two shortcuts that show up all the time in early agent projects.
The first is shared credentials, where several agents run on one service account or API key. When something goes wrong, nobody can tell which agent did it, and a single leaked key opens every system it touches. The second is borrowed human access: an agent running under an employee’s login picks up that person’s entire permission set, nearly all of which the task never needed.
The better approach gives each agent its own verifiable identity, with its own permissions and its own audit trail, and a named person who answers for it. Mimecast’s guidance makes the same case for mapping each agent to an access owner while keeping a clear line back to the user or process behind it.
This matters more as agents stop clocking off. OpenAI’s always-on agents keep working after the user closes the chat, each on its own cloud computer. Software that runs around the clock needs an identity that stays clear around the clock too.
Least privilege, applied more strictly
“Give only the access the task needs” is old advice. Agents just raise the stakes, because they can do a lot in very little time. In practice, least privilege for an agent works on four levels:
| Layer | What it controls | Example |
| Task scope | Which systems the agent can reach | A support agent reads tickets but never touches billing |
| Data level | Which records or fields it can see | Customer names, yes; card details, no |
| Time limits | How long access lasts | Credentials expire when the job finishes |
| Approval gates | What needs a human first | Deletions and outside emails wait for sign-off |
Picture how this plays out. A sales team sets up an agent to update lead records and draft follow-up emails. Granted broad CRM access “so it doesn’t get stuck,” it can also read contract values, export the whole customer list and send messages straight to clients. Scoped properly, it can edit lead fields, write drafts into a review queue and nothing else. If it’s ever manipulated, the damage stops at a few bad drafts instead of a data leak.
Deciding where humans step in
Approval gates are deliberate friction, so where you put them matters. Gate everything and you’ve lost the reason for automating in the first place. Gate nothing and nobody is accountable.
Most teams end up putting a person in front of money moving, messages leaving the company, permission changes in other systems, and anything that deletes data. Reading data within scope, drafting content for review and routine internal lookups can usually run on their own. Those lists shouldn’t be set once and forgotten. Adjust them as incidents and near misses show you where the real risk sits.
What monitoring needs to catch
Identity and permissions set the limits in advance. Monitoring tells you what happens inside them, and that matters because even tight permissions get used in ways no one expected during setup.
Every action should be logged against the agent’s identity. Once you have more than a handful of agents, though, nobody reads those logs line by line. Useful monitoring flags the odd stuff automatically: an agent touching systems it doesn’t normally use, trying something outside its scope, suddenly running at ten times its usual volume, or working at 3 a.m. when it normally doesn’t. Requests that are technically allowed but out of character deserve a flag too.
Speed is the catch. An agent can finish a harmful action before a person notices the alert, so the strongest controls check requests as they happen and block the bad ones on the spot. As AI coding agents and similar tools take on real work, that kind of runtime check matters more than any after-the-fact review.
The three controls depend on each other
Each one leaves a gap that only the others can close:
| If you have | But lack | The result |
| Strong identity | Least privilege | Perfect records of actions that never should have been possible |
| Least privilege | Monitoring | No way to know if agents stay inside their limits |
| Monitoring | Reliable identity | Logs you can’t trace to a particular agent or task |
Treat them as one system from the start. Bolting them on one at a time, after something breaks, leaves exactly the gaps this table describes.
Where to begin
Begin by finding out what agents you actually have. Teams often build their own without telling security. Next, give each one a distinct identity and an owner. Then cut permissions back to what each task really needs, with data limits and expiry dates. Put approval gates in front of high-risk actions. Finally, switch on logging with automatic alerts, and review it all regularly, because agent access tends to creep as workflows change.
FAQs
Q. What is AI agent governance?
The policies and controls that decide what an AI agent can access and do, and how its actions get tracked. Identity, least privilege, and monitoring sit at its core.
Q. Why shouldn’t agents use existing service accounts?
Shared accounts hide which agent did what, and they usually carry far more access than any single task needs.
Q. What does “excessive agency” mean?
It’s OWASP’s term (LLM06:2025) for giving an AI system more functionality, permissions or autonomy than its job requires. It’s a root cause of many agent security failures.
Related: Best AI Development Companies for Data AI Solutions in 2026 You Should Know About
