Here’s a question to ask yourself before your next access review. Can you produce a list of every AI agent operating inside your organization’s systems? Not the ones IT formally approved. All of them.

Most Heads of Audit can’t. And the data that came out this month says that gap is a much bigger problem than it sounds.

A survey of more than 900 practitioners published this quarter found that 88% of organizations had a confirmed or suspected AI agent security incident in the past year. A separate study found that 82% of enterprises have AI agents running in their infrastructure that nobody formally inventoried. More than half of deployed agents operate with no logging at all. When something goes wrong, there is no audit trail, no evidence, no record of what the thing actually did.

Read that back as an auditor for a second.

We have spent our entire careers testing two questions: who has access, and who did what. There is now a population of actors inside the enterprise that outnumbers the staff by something like forty to one, and for most of those actors, neither question has an answer.

The population nobody counted

Across most large organizations, non-human identities now outnumber human ones at ratios commonly cited between 40 to 1 and 80 to 1. Service accounts, API keys, bots, and now a fast-growing layer of AI agents that can read systems, make decisions, and take actions on their own.

The governance has not kept pace. Only 23% of organizations report a formal strategy for managing non-human identities, and just 18% of security leaders trust their identity systems to handle them. Gartner expects 40% of enterprise applications to have task-specific agents embedded by the end of this year, up from under 5% in 2025.

The population is exploding, and the controls were built for a world where every actor badged in, got provisioned through HR, and showed up in a quarterly access review.

That world is gone. The agents did not go through HR.

This is literally our job

It is tempting to file this under “cybersecurity” and move on. It shouldn’t be.

Identity, access, segregation of duties, and the audit trail are the oldest topics we have. We have been asking “who can do what, and how do we know what they did afterward” since long before anyone said the word AI. The discipline already exists. The vocabulary already exists.

What changed is the population it has to cover. The access review you run every quarter was built to catch the leaver who still has access, the developer with rights to production, the one person who can both create and approve a vendor. Those tests still matter. But there is now a second population sitting alongside the humans, larger than them, and almost entirely absent from the review.

An auditor who says “show me the inventory of agents, the access each one holds, and the log of what they did last month” is not learning a new skill. They are applying the most fundamental one we have to a population nobody else thought to count. We should use that advantage before someone else writes the playbook for us. I made the same argument in The Governance Gap: if risk professionals don’t step in, the space gets filled by frameworks that don’t reflect how the tools actually work.

Least privilege was built for people

Here is the part that should make you uncomfortable: it breaks a control most of us treat as a given.

Least privilege is the backbone of access management. Give each actor the minimum rights they need, and the blast radius of a mistake stays contained. It works because a person with limited rights does a limited number of things.

An agent does not behave that way. Security researchers at Zenity demonstrated this clearly: an AI agent can stay entirely within its assigned permissions and still exceed its intended scope, because it reasons, chains actions together, and can be talked into things. The permission set says what doors the agent can open. It says nothing about what the agent decides to do once it is inside the room.

A service account runs the same script every night. An agent connected to your email can draft and send. An agent connected to your ERP can read a contract, decide it looks like the others, and act on it. Same permissions. Completely different risk.

The emerging answer is a concept worth knowing: not just least privilege, but least agency. Limit not only what the agent can touch, but how much it is allowed to decide and act before a human is back in the loop. Decision budgets. Runtime scoping. A named human owner for every agent, so that “the model did it” is never the end of the accountability chain. I wrote about that accountability gap in Who Audits the AI?; this is the operational version of it.

The clock is real this time

There is a date attached to all of this. The EU AI Act’s enforcement powers for general-purpose models and high-risk systems switch on from August 2, about five weeks from when I’m writing this. And NIST’s own standards body admitted back in February that how agents are authenticated, how their permissions are scoped, and how their activity is logged are still unsolved architectural questions.

When the regulator and the standards body both say they don’t fully know how to govern this yet, the organizations that can at least show their work are in a very different position from the ones that can’t produce a list.

I have lived a small version of this. The moment I connected my own audit orchestrator to real systems instead of pasted-in sample data, the first thing I had to get straight was exactly this: what can each agent touch, and can I reconstruct what it did afterward? The capability and the risk arrive together.

What to do before August

Three things would move you ahead of most of the market in a few weeks.

  • Ask for the inventory. Request a single list of every AI agent running against company systems, who owns each one, and what it can access. The point is not the list. It is whether anyone can produce one. The answer tells you almost everything about the maturity of the control environment.
  • Put agents in the next access review. Treat non-human identities as in-scope actors, not infrastructure plumbing. Test for orphaned agents, over-provisioned agents, and agents with no named human owner, the same way you test for human access.
  • Require the audit trail before connection, not after. Make “we can reconstruct what this agent did” a precondition for connecting any agent to a real system. If there’s no log, there’s no evidence, and with no evidence there is no audit.

None of this requires you to be a machine learning engineer. It requires you to do the thing we already know how to do, applied to a population that grew up while we were looking at the human side of the org chart.

If your CEO asked you tomorrow how many AI agents are operating in the business and what each one is allowed to do, how long would it take you to answer? And if the honest answer is “I don’t know,” is there a better place to start your next audit?