Ask a security team who has access to their customer database and you will get a precise answer. Names, roles, a joiners-and-leavers process, an access review every quarter, someone accountable for each grant.
Ask the same team what their AI agents can reach and the answer gets vague fast.
Not because anyone was careless. Because agents arrived through a different door.
How it actually happened
Almost nobody set out to give an AI agent broad standing access. It happened one reasonable decision at a time.
Someone built an assistant that needed to read from three systems. Getting a narrowly scoped credential meant a ticket, an approval, and a week. Getting an existing service account meant getting on with the work. The prototype worked, the prototype shipped, and the service account came with it.
Then the agent’s job grew. It started as read-only summarisation. Then it wrote a ticket. Then it issued a refund. The permissions never shrank, because nothing in the process ever asks whether they should.
Then it delegated. Modern agents call other agents and other tools. Whatever the first one held, the next one inherited, because passing the credential along was the only mechanism available.
None of these steps is a mistake exactly. Together they produce something no organisation would ever approve if it were written down as a proposal: a non-human identity with wide, permanent, unreviewed access, that acts thousands of times a day, at machine speed, on instructions partly written by strangers.
Why the old controls do not reach
Every access model we have was built around a person.
Permissions are sized for a job, not a task
A human analyst with database access uses a sliver of it on any given day, and we accept the gap because the person exercises judgement. An agent has no judgement to fall back on. The gap between what it holds and what it needs is not a margin of safety — it is unsupervised capability.
Credentials are sized for a session
We think in hours because people work in hours. An agent’s task may last ninety seconds. A credential that outlives the work by a day is not a rounding error; it is a day of standing authority nobody is watching.
Review happens on a quarterly cadence
An agent can take more actions before lunch than a person takes in a year. Quarterly review of something operating at that rate is not governance. It is archaeology.
And the input is not trusted
This is the part that has no precedent. A person reading a hostile email is unlikely to follow its instructions. An agent reading a hostile support ticket, web page, or document may well do exactly that, because to the model it is all just text. The OWASP Top 10 for LLM Applications put prompt injection at number one, and it has stayed there, because it is not a bug anyone can patch. It is what happens when the instruction channel and the data channel are the same channel.
Put those together. An identity holding far more than it needs, for far longer than it needs, reviewed far too slowly, that can be talked into using it by a stranger who never has to authenticate.
The part that keeps people up
Here is the question I would ask any team running more than a handful of agents.
If one of your agents were manipulated this afternoon,
how many others are already exposed?
Not “could be compromised next.” Already exposed — because they hold the same capability, reached through the same tool, against the same system. If the answer requires a week of investigation, that is the real finding. The blast radius of a single compromise is not one agent. It is every agent holding an overlapping capability, and most organisations cannot enumerate that set at all.
This is why “we’ll monitor them” is not an answer. Monitoring tells you what happened. At agent speed, by the time the alert is triaged, the same capability has been exercised somewhere else a few thousand times.
A retail bank, and how ordinary this looks
Let me make it concrete. The bank below is composite and unnamed; nothing in the story is invented.
Each was approved separately, by sensible people, over fourteen months.
The triage agent needed to read the customer mailbox and the CRM. Fine. It was given the integration account the old routing service used, because that account already had the right reads and standing up a new one meant a six-week queue.
The servicing agent needed account data. It inherited the same integration account, because it was already approved and already worked.
The disputes agent needed to write. Someone did think carefully here: they capped the goodwill credit at 200. But the cap lives in the agent’s own configuration, and the credential behind it can write to the ledger without a cap, because the cap was a product decision rather than a permission.
The reporting agent needed to read everything, and reads everything.
Now count what the bank actually has. One shared identity with read access across the mailbox, CRM and core banking, and write access to the ledger, exercised by four agents, one of which reads text written by members of the public.
Nobody approved that. Four people approved four reasonable things.
The Tuesday
A customer sends a complaint. Inside it, formatted to look like a forwarded thread from an internal system, are instructions addressed to whatever reads the message.
The triage agent reads it. That is its entire job.
What happens next is not exotic. There is no exploit, no malware, no privilege escalation in the classical sense. The agent does what it was designed to do, on input that was crafted for it, using authority it legitimately holds.
And here is the part that makes it a bank problem rather than a support problem. The disputes agent holds the same credential. It has held it since March. Whether or not the attacker knew that, the exposure was already there on Monday.
When the security team is asked the following week how many agents were affected, the honest answer is that they need a fortnight to work it out. Not because they are disorganised, but because nobody has ever had to enumerate “which agents share this capability” before, and no system was built to answer it.
That question — who else is already exposed — is the one I would want answerable in seconds. At most organisations today it is answerable in weeks, if at all.
What good looks like
I do not think the answer is to slow agents down. The value is real, and organisations that govern agents well will run more of them, not fewer.
But a few things have to become true.
Agents need to be identities in their own right — provisioned, reviewed and deprovisioned like anything else with access, not shared logins with a friendly name.
Authority needs to be sized to the task rather than the job, and it needs to shrink when the task ends. An agent that has spent a month doing one narrow thing should not still be holding the access it was given on day one.
Enforcement has to sit outside the model. If the only thing stopping an agent from doing something is a sentence in its system prompt asking it not to, then the control is advisory, and the attacker gets to argue with it.
And the whole thing has to be provable. Not a dashboard that says everything is fine — a record that someone outside your organisation can check, because that is what an auditor, a regulator, and eventually a court will ask for.
Where this goes
The agent identity problem is roughly where cloud security was in 2014. Everyone could see the shape of it. The tooling did not exist yet. The organisations that took it seriously early spent a few uncomfortable quarters and then stopped having incidents about it. The ones that waited learned the same lessons with an audience.
The difference this time is speed. Cloud misconfiguration sat quietly until someone found it. An over-permissioned agent is not sitting quietly. It is acting, continuously, on input from people you did not vet.
We work on this problem at Aribot, and I will write more about the specifics. But the first step does not need a vendor. It needs an inventory.
How many agents are running in your organisation right now, what can each one reach, and who approved it?
If nobody can answer that in an afternoon, that is the place to start.
Where Aribot fits
Aribot governs what AI agents are allowed to do — authority sized to the task rather than the job, enforcement that sits outside the model rather than asking it politely, and a record of what was permitted and what was refused that someone outside your organisation can check. It works with the identity stack you already run.