Most executives would agree that a script running in the background of a critical system needs controlled access. Someone wrote it, someone owns it, and it can only touch what it was built to touch.
Far fewer would say the same about the assistant inside Copilot, the agent a vendor switched on in last month’s release, or the one a colleague built on a personal AI account and connected to the company’s mail and CRM. Yet that agent can hold the same rights as the script, and it can do a great deal more with them.
That gap in understanding is what this piece is about.
What controlled looked like at a bank
For the last few years I worked on privileged access at a global bank. One of the systems my team built was an automation engine that processed privileged-access requests without a person in the loop. It was, in effect, a non-human identity with real power.
It was also one of the most tightly controlled things in the estate. Every call went through an API gateway that checked which account was asking and whether it was allowed. Each consumer had its own service account. Production and non-production used separate accounts. Credentials sat in a vault and rotated each time they were used. Nobody logged in as the engine; it was programmatic only.
None of that happened by accident. It took a programme, an architecture review and a lot of people saying no.
Agents arrive without any of it
An agent in a mid-size firm today rarely gets that treatment. It is created in an afternoon, often by someone outside IT, in a tool the firm already pays for. It connects to mail, files, the CRM or the code repository with a few clicks and a consent screen. It may run on the credentials of the person who set it up, and keep running after that person has moved on.
Microsoft’s Copilot Studio shows how easily this happens. When the person building an agent connects it to another system with their own login, Microsoft’s documentation says “the agent uses the maker’s credentials, not the end user’s credentials”. Put simply, everyone who uses the agent borrows the builder’s access. If the builder can see every client file, so can anyone who asks the agent a question.
An old problem with a new name
None of this is new in kind. Service accounts have always had the same weaknesses: no clear owner, permanent rights, passwords that never change, and nobody to remove them when the system they served is retired.
Anyone who has run a privileged-access programme will recognise where the effort goes. The tooling gets bought and deployed. Ownership is what drags on: accounts nobody will claim, owners who left years ago, systems still running long after the business stopped needing them. Firms usually fix the access in the end. Fewer fix who answers for it.
Agents inherit all of that and add three things. They can be built by anyone, not just engineers, and when an engineer builds one, it can run on some of the most powerful access in the firm. They act on someone’s behalf, often with that person’s full rights. And they chain actions together faster than anyone reviews them.
What OWASP and the FCA now say
In December 2025 OWASP published its Top 10 for agentic applications. One of the ten, ASI03, is identity and privilege abuse, which OWASP describes like this: “Agents inherit user or system identities with high-privilege credentials, creating opportunities for privilege escalation and unauthorized access across systems”. Its description ends with “shadow agent deployment that inherits legitimate credentials”, which is the colleague’s agent above, in a standards body’s words.
A fair objection is that most business users do not have admin rights, so how would their agent end up with high-privilege credentials? There are three common routes.
- The agent gets access of its own. Connecting an agent to a system often means an administrator approves access for the agent itself, or gives it a key. That access can cover the whole system: every mailbox, not just one person’s.
- It borrows someone else’s. When the builder works in IT or finance, everyone using a shared agent inherits the builder’s rights, as in the Copilot Studio example.
- Business access is privilege too. Someone who can release payments, change a customer’s bank details or read every client file holds high-value access without “admin” in their job title. OWASP’s word is “high-privilege”, not “admin”.
The FCA’s Mills Review, published in July, describes five levels of AI autonomy. Here they are in the review’s words, each with what has to be true about access at that level:
- L1, Operator. Human uses AI as a tool. The person’s own permissions are the control, so they had better be tidy.
- L2, Collaborator. Human and AI work together. The same, plus a record of what the AI did.
- L3, Consultant. AI recommends, human decides. A trail that shows what was recommended and what was decided.
- L4, Approver. AI prepares, human authorises. An approval that is a real decision, not a reflex click.
- L5, Observer. AI acts within boundaries, human monitors. The agent’s own identity, narrowly scoped, owned and time-limited.
The ladder measures autonomy, not risk. Risk is autonomy multiplied by access: a level 1 assistant that can see every file its user can see may be riskier than a level 4 agent with one narrow permission.
The review is also clear that accountability stays with people and firms. On the Senior Managers Regime it says: “We agree that the SMR still applies”. And firms “remain responsible for outcomes even where systems rely on external models or infrastructure”. For agents, reasonable steps start with knowing what each one can reach and who answers for it.
What controlled looks like for an agent
The answer is not a new kind of control. It is the controls a well-run firm already applies to admin rights, applied to agents:
- An owner from the business, not just the engineer who built it. The person who can say whether it is still needed.
- A recorded purpose, and an inventory you could produce in a day.
- The least access that does the job, with nothing permanent that does not need to be.
- Credentials that expire, not static keys.
- An end date, and a way to switch it off within the hour.
- A trail back to a person for anything it changes.
One warning on the third point. Your identity system is not the only place that decides what an agent can do. Many business systems, payments platforms among them, issue their own keys, and each key carries permissions set inside that system, which your identity team may never see. An agent can look read-only in your directory and still be able to issue refunds, because the payments key it was given allows it. It is like checking someone’s building pass and missing that they also hold a key to the safe. To know what an agent can do, look at every key and login it holds.
Three questions for Monday
- How many agents and automations can reach production systems or customer data today?
- Who is the named owner of each, and what happens when that person leaves?
- Which of them run on a static key or on a person’s account?
If putting the answers together would take more than a day, that is the gap.
Where I am on this
I spent years on the human and service-account side of privileged access. I am now spending most of my time on agents, because the same questions are coming back with less time to answer them.
Next I’ll look at the second of those questions, because it is the one most firms get stuck on: who owns this at all. If you have tried to answer them, I’d like to hear how it went.
First published on LinkedIn on 9 October 2026. Discuss it there, or write to hello@aevixadvisory.com.