Direct answer: An AI agent that can read, write or act on your systems should be governed like any other identity with access. An AI agent access review does five things: lists every agent, including those built into software you already use; gives each its own identity; cuts its access back to what its task needs, read-only by default; names one business owner who agrees its limits and can switch it off; and makes sure every action is logged against the agent's identity. Then test what each agent does when things go wrong before it goes live, and review agent access on the same cycle as user access.
On 1 May 2026, six national cyber agencies, including the UK's National Cyber Security Centre, the US Cybersecurity and Infrastructure Security Agency and their counterparts in Australia, Canada and New Zealand, published their first joint guidance on AI agents: Careful Adoption of Agentic AI Services.
Its central message is that an agent able to take actions is a security concern in its own right. It isn't just a feature of the software it arrived in, and it shouldn't inherit that software's assumptions about trust.
That matters because agents are no longer confined to innovation teams. They're arriving in the tools organisations use every day.
Most organisations didn't make one decision to deploy AI agents. They arrived by several routes:
Each route leaves an agent able to act somewhere in the estate, often under an identity that wasn't designed for it. We've written before about the security gaps enterprise AI already carries; agents widen them, because they don't just read data, they act on it.
Start with an inventory. Include agents your teams built, agents in pilots, agents in integrations and the agent features built into SaaS tools. For each one, record what it does, which systems it touches and who asked for it.
The agents built into existing software are the ones most often missed. Check each major SaaS tool for agent or automation features and whether they are switched on.
An agent running under a shared service account, or under a person's account, can't be told apart from everything else that account does. Give each agent its own identity, so its access can be scoped, reviewed and revoked on its own, and so its actions can be traced to it.
Least privilege applies to agents as it does to people, and arguably more so, because an agent acts faster and at greater volume than any person. For each agent:
Every agent needs one named business owner. The owner agrees what the agent may do, reviews what it has done and has the authority to switch it off. Without an owner, nobody can make those decisions quickly, and an agent that misbehaves keeps running while people work out who should stop it.
If an agent acted yesterday, could you prove what it did? Logging should record, against the agent's own identity:
Keep agent logs for as long as your other audit records. An incident involving an agent will be investigated like any other, and the evidence has to exist.
The review will find agents with too much access, no owner or no logging. Plan the changes in order of risk: agents with write or action rights to sensitive systems first, then everything else. Record the decision for each.
Most testing checks that an agent does the job when everything goes right. The risks sit in what happens when it doesn't. Before go-live, test each agent against:
An agent that fails safely is one you can put into production. An agent that has only been tested on success isn't ready.
Access reviews for people are routine in most organisations. Agents should join the same cycle. At each review, check that every agent still has an owner, that its access still matches its task, that pilot access has expired where it should, and that logging is working.
New agents should go through the same steps before they're switched on, not after.
Agents built into software come with vendor reassurance about how they're secured. That is useful, but it isn't assurance. The organisation remains accountable for what an agent can reach and what it does with that access. Leaders need an independent view of access, permissions, logging and the off switch, drawn from their own estate rather than the vendor's documentation.
We help enterprises and SMEs bring AI agents under control, using our Sync, Align, Optimise approach.
An AI system that takes actions rather than only answering questions: reading and updating records, sending messages or running tasks across other systems, often with some freedom over the steps it takes to reach a goal.
A dedicated identity, like a service account, used by one agent and nothing else. It lets you scope, review and revoke that agent's access on its own, and trace every action back to it.
On the same cycle as your user access reviews, and whenever an agent's task changes. Pilot access should carry an expiry date so it can't outlive the pilot.
A named business owner for the process the agent works in, not only the team that built or bought it. They agree its limits, review what it has done and have the authority to switch it off.
Request a 30-minute discovery conversation with our team. We'll help you list the AI agents in your estate and decide what each one should be allowed to do.