Every company that shipped an AI agent this year also shipped a new privileged account with it. Most of them skipped the step where somebody decides what that account is allowed to reach.
The pattern is consistent enough to predict. A team wants an agent to answer support tickets, so it gets a token for the helpdesk API. Reasonable. Then somebody wires in read access to billing because the answers are better with invoice context. That is also defensible. Then write access to the ticket queue, because auto-closing resolved tickets saves a click. Six weeks later the agent holds the combined permissions of four systems, and no document anywhere explains why. Ask three engineers on that team what the agent can reach and you will get three different answers.
That is the whole problem, and it now has measurements behind it. KPMG's 2026 cybersecurity report puts non-human identities at more than 80 to 1 against human ones in the average enterprise, with machine identities per company growing from roughly 50,000 in 2021 to about 250,000 in 2025. Suzu Labs counted 45 to 1 in its own telemetry and reported the figure at 83 to 1 by May, a 41 percent rise in five months. Treat the precise number with suspicion, since every vendor counts API keys, OAuth grants and certificates differently. The growth rate is the part that should hold your attention.
OWASP moved to match. In the 2026 revision of its Top 10 for LLM applications, Excessive Agency climbed from sixth to third, behind prompt injection and sensitive information disclosure. The reordering matters more than the ranking itself. Damage scales with what the model is permitted to do, not with how clever the attacker was. A fooled agent that can only read a knowledge base is an embarrassment. A fooled agent that can move money, close accounts or email customers is an incident.
Why agents are not service accounts
The instinct is to treat an agent like a service account, because it authenticates the same way and nobody has to handle a password reset. That instinct creates most of the exposure.
A service account has a fixed scope. Someone wrote a deployment spec, the account got three permissions, and it kept those three permissions for years. An agent's effective scope follows whatever task is in front of it. The same identity that reads a public FAQ at 10am may be reconciling invoices at 2pm. Its permission footprint at the identity layer is the union of everything it might ever need, so the footprint reflects the maximum, not the current need.
Delegation makes it worse. An agent acting for a user should hold the intersection of the two permission sets: what the user is allowed to do, and what the agent is scoped for. Most implementations take the union instead, because the user's token was already in scope and passing it through was the shortest path to a working demo. The result is an agent that can do everything its most privileged user can do, plus whatever was bolted on for the agent itself.
Three mechanisms that produce overreach
Inherited credentials. The fastest way to get an agent working is to reuse a token that already works. Often that token belongs to the developer who built the prototype, or to a shared automation account that predates the project. The agent then holds every permission the human held, including the ones for systems it will never touch.
Tool accumulation. Agents gain tools as features ship. Removing a tool requires somebody to notice it is unused, and nobody notices. A year of feature work produces an agent with 30 tools, 22 of them dead weight, and all of them widening the blast radius.
Acting on untrusted content. This is what separates an agent from a cron job. A nightly batch script processes data. An agent reads text and then decides what to do with it, and some of that text comes from outside the company. A support agent reading a customer message, a research agent reading a web page, a coding agent reading a dependency's README: each is a place where outside text becomes instructions. Security teams call the attack indirect prompt injection. The practical version is a customer email containing a line that tells the agent to export the customer table to an external address, and the agent doing it, because it has both the tool and the authority.
The audit nobody runs
You do not need a platform to start this. You need ninety minutes and an honest inventory. Six questions, in this order.
- One: does the agent authenticate as itself? If two agents share a token, or an agent uses a human's credential, you cannot attribute an action to a cause. Give each agent its own identity and its own credential before anything else. This is also the only step that lets you revoke one agent without breaking the others.
- Two: what can it actually reach? Not what the architecture diagram says. Enumerate every API endpoint, database, storage bucket and mailbox the credential unlocks, by testing the credential rather than reading the config. The gap between the config and reality is usually two or three systems nobody remembered connecting.
- Three: are read, write and spend separated? Almost every overreach incident involves an agent that only needed to read. Grant read scopes by default. Add write scopes per workflow, with a named owner. Treat money movement, account deletion and outbound email as a separate tier that requires human approval every time, including for agents you consider trusted. Approval prompts are irritating for a week, then they become part of the process.
- Four: how long does the credential live, and where is it stored? Static tokens in environment variables are the norm and the worst option. Short-lived tokens issued per task and scoped to that task remove most of the value of a stolen credential. If a secret has appeared in a repository, a CI log or a screenshot, rotate it first and ask questions later.
- Five: is there a kill switch, and when did somebody last pull it? Revocation that has never been tested is a plan, not a control. Disable one agent in staging, confirm its work stops and nothing else breaks, then write down the command. The middle of an incident is a poor time to discover that revoking the token also kills the nightly reconciliation job.
- Six: who owns it and when is it reviewed? Every agent needs a named owner, the same way every service account theoretically has one. Put the review on the same calendar as firewall rule reviews and access recertification. Quarterly suits most companies. Annual review is how you end up with an agent still holding a departed contractor's token.
When the agent is a vendor's product rather than something you built, you cannot audit its internals, and you should stop trying. Audit the connector instead. Every SaaS agent reaches your systems through a specific integration: a mailbox, a drive, a CRM tenant. The connector's permission grant is the real access boundary, and it is the thing you can see, narrow and revoke. Check whether the grant is tenant-wide or folder-scoped, whether it survives the employee who installed it, and whether the vendor's admin console can list what the agent read.
Fixing it without breaking the workflow
The usual failure mode is that access control gets scoped as security work, security work has no product owner, and the project stalls while the exposure stays. Run it as a scoping exercise instead, one agent at a time, starting with whichever agent touches money.
Narrow each grant to a single action on a single resource. Reading one record type is a smaller grant than reading a whole SaaS API, and most agent frameworks make this cheap to implement. Where the framework supports per-tool permission checks, use them. Where it does not, put a thin proxy in front of the upstream API and let the proxy enforce the scope.
Here is one worked example. A support triage agent starts with a helpdesk token holding read and write on all tickets, read on the billing API, and an SMTP credential for notifications. After an afternoon of narrowing it keeps read on tickets, write on a single field (status), read on the invoice summary endpoint, and loses the raw SMTP credential in favour of a notification service that only accepts pre-approved templates. Every customer-visible action now goes through an approval queue. Capability went down; the workflow did not change. That is the test for any scope reduction: if the workflow changed, you cut the wrong thing.
Remove tools that are not used. Check the call logs from the last 30 days, delete what never fired, and note what you removed. This is the cheapest risk reduction available and it takes an afternoon.
Constrain egress. An agent that can only reach an allowlist of hosts cannot exfiltrate data to an address quoted in a customer email. This one control neutralises a large share of prompt-injection consequences without requiring you to detect the injection at all.
Log the tool calls, not just the chat. Keep the arguments and the result for every call, tied to the agent's identity, and keep approval events alongside them. When something goes wrong, the transcript is the difference between a two-hour investigation and a two-week one. Alert on odd shapes rather than on failures: a read-only agent calling a write endpoint, a run of exports, a tool that has been dormant for months suddenly firing. Agents fail quietly, so errors are rarely the interesting part of a log.
The uncomfortable part
None of this requires a new product. The companies that will lose a quarter to an agent incident are not missing a vendor. They are missing the ninety minutes, because the agent worked, the demo landed well, and nobody asked what the token could do.
Run the six questions against your highest-privilege agent this month. Then put the result in the same document as your other privileged accounts, so the next person who reviews access sees the agent sitting beside the admin account it outranks.
