Nobody knows how many agents they are running

The first thing we do on an AI governance engagement is ask for the register. Almost every client has one now. It is usually a spreadsheet, maintained by someone in risk or architecture, and it usually lists between four and nine systems.

The second thing we do is go and look. Code search across the repositories, inspection of the cloud accounts, egress patterns on the network, and, most productively, the expense records. Somebody paid for it. That trail is almost always the one that finds the tool the security team never saw.

The register is never right. That is not a criticism of the person maintaining it, and it is not the old story about shadow IT either. What we find is teams that did exactly what leadership asked them to do, at the speed leadership asked for it, using the access they already had.

Why the gap is agents, not models

Models get noticed. Somebody signs a contract, procurement gets involved, there is a line in the budget. A model tends to arrive through a process, and processes leave records.

Agents arrive differently. An engineer wires a model to a tool, gives it a credential so the demo works, and shows it to their manager on a Thursday. It saves four hours a week. It stays. Nobody filled in a form because nothing was bought, and the thing that changed was a few dozen lines in a repository nobody outside that team reads.

By the time we arrive, that agent has been writing into a production system for eight months, still using the credential that was convenient on day one.

What the credential problem actually looks like

Here is the shape of it, repeated across engagements with different names attached.

• An agent reads inbound customer email so it can categorise and route tickets.
• To close tickets it was given write access, and the simplest write access available was to the service account that already had it.
• That service account can write to more than the ticket table. It usually can write to the customer record.
• The email body is untrusted input arriving from anyone on the internet, and it lands directly in the agent's context.
• Nothing in the logging distinguishes a write the agent made because a human asked from a write it made because a message told it to.

None of the individual decisions there is unreasonable. The engineer who built it was solving the problem in front of them with the tools they had. The compounding is what makes it dangerous, and compounding is invisible to everyone except somebody looking at the whole path at once.

Blast radius is the number that changes the conversation

We stopped describing this in terms of vulnerabilities some time ago, because it did not land. A board hearing that an agent is vulnerable to prompt injection reasonably asks how likely that is and moves on.

Blast radius lands better. For each agent we map what it can read, what it can write, what it can trigger, and what the worst outcome is if someone talks it into doing the wrong thing. Then we put that next to the task the agent was actually built to do. The gap between those two is the finding, and it is usually enormous.

A board that hears an agent built to categorise tickets can modify any customer record and issue refunds does not need a probability estimate. They can see the problem, and more importantly they can see the fix.

The fix is cheap, which is the good news

Almost everything in this category is inexpensive to remediate relative to what it costs when it surfaces on its own. Scope the credential to the minimum the task requires. Log every action with its originating context so a bad write can be traced. Put a human approval step on anything irreversible, which in practice means anything involving money, deletion or an external party.

For a typical estate that is a few weeks of work per agent and it does not require replacing anything. The hard part is not the engineering. The hard part is knowing which agents exist, which is why the inventory comes first and why we do it by looking rather than by asking.

What we would suggest doing this quarter

You do not need an assessment to start. Search your repositories for the model provider SDKs you have accounts with. Pull the last twelve months of expense records and look for anything AI-shaped under a few hundred dollars a month, which is where these things live. Ask each engineering team leader, privately and without a form, what they have running that is not on the register. You will find things.

Then, for each one, ask a single question: if someone hostile controlled the input to this, what is the most damaging thing it could do with the access it currently holds. That question alone will reorder your priorities.