Your AI agent has more access than anyone you would hire. Nobody decided that.
Your supplier has shown you the demo. The agent reads the inbox, checks the customer record, drafts the refund and updates the ticket. Everyone in the room is impressed, and nobody asks the question that matters most: what else can it do?
Here is the honest answer for most agents being built right now. Almost anything the account it runs under can do.
The agent is a new member of staff you never interviewed
When you hire someone into finance, they do not get the keys to HR, the CRM admin console and the shared drive with the board papers on day one. Somebody decides what the role needs and grants that.
Agents rarely get the same treatment. They are usually connected through a service account or an API key that was set up to make the demo work, and making the demo work is easiest when nothing is ever refused. The access that was convenient in week two becomes the access that goes live.
That is not a guess. The surveys from the last twelve months say the same thing from different directions.
A Cequence and EMA survey found that 94% of enterprises trust their AI agents are not over-provisioned, but only 33% actually enforce it.
In a Cloud Security Alliance research note, 43% of organisations said they run agents on shared or generic service accounts, and only 28% could trace an agent's actions back to a human sponsor across all their environments.
Most of these studies are sponsored by vendors who sell the fix, so read the exact percentages loosely. The direction is not in doubt, and it is consistent across every source we found: confidence is high, enforcement is low.
Why this is worse than an over-privileged person
An employee with too much access mostly does not use it. They do their job, and the spare permissions sit idle.
An agent behaves differently. It acts on instructions it reads, and some of what it reads is written by people outside your organisation: an email, a support ticket, a PDF a customer uploaded. OWASP lists this as excessive agency in its top ten risks for LLM applications — damage done because a model with too much reach followed an unexpected or manipulated instruction.
We covered what that looks like in practice in the AI didn't break in, it logged in. The short version: the attacker does not need to beat your security. They need your agent to do something it was already allowed to do.
So the question is never only "is the agent clever enough?" It is also "if the agent is fooled, how much can it reach?"
What permissions should an AI agent have?
An AI agent should have only the permissions its specific task needs, granted to its own identity rather than a shared account, with anything irreversible — payments, deletions, outbound email to customers — requiring a separate approval. On current survey evidence, roughly two in three organisations do not enforce that. If your supplier cannot list what the agent can do in one page, nobody has decided it yet.
That last sentence is the uncomfortable one. In most builds we review, the permission list does not exist. Not because anyone was careless, but because nobody's contract made it their job.
The supplier was paid to make the agent work. Your IT team assumed the supplier had scoped it. Security saw "read-only integration" on a slide six months ago. Each party is reasonable, and the gap between them is where the agent sits with admin rights.
What we see in real projects
Anonymised, but typical:
- A professional services firm had a document-summarising agent running on an account that could also delete files across the whole shared drive. Summarising needed read access to one folder.
- A retailer's customer service agent could issue refunds of any size. The business rule for humans was £50 without a manager. Nobody had applied it to the agent, because the rule lived in a policy document, not the system.
- A financial services firm found its agent's API key was the same one used by three other integrations. Revoking it to stop the agent would have stopped all four.
None of these were breaches. They were found by asking. That is the point: the cheap moment to fix this is before go-live, when it is a configuration change rather than an incident.
What to ask your supplier this week
You do not need to be technical to ask these. You need the answers in writing.
- What identity does the agent run as? Its own, or a shared or personal account? "Mine, for now" is the wrong answer.
- What can that identity read, change and delete? A list per system, not a sentence.
- Which actions can't be undone, and who approves them? Money moving, data deleted, messages sent outside the business.
- What is the limit? Refund caps, record counts, spending ceilings — the same limits a person in that role has.
- How do we switch it off without breaking anything else? If the key is shared, the answer is "you can't".
- Where is every action logged, against what? You want to see, after the fact, what the agent did and why.
If you are scoping a build, put these in the statement of work. It costs nothing to write down, and it changes what the supplier is accountable for. Measuring the blast radius is the companion exercise: what is the worst a mistake could cost?
Make it part of the proof, not an afterthought
A proof of concept that shows the agent working with unlimited access proves very little. It proves the easy half.
The useful proof shows the agent doing the job with the access it will actually be allowed in production — and shows what happens when it is asked to do something it shouldn't. If performance drops when the permissions are tightened, you want to know in week three, not month nine.
That is how we run Prove: four weeks, fixed price, with the permission list, the limits and a test of what the agent refuses built into the pass mark. You keep the evidence whatever it shows. If you want to see the full set of deliverables first, here is what you get.
The agent will do exactly what it is allowed to. The only question is whether anyone decided what that is.