By Richard Sonnen, Sentinel’s Director of AI Innovation and Consulting

Ask your IT team how many AI agents are running in your company right now. Then ask who owns each one.

You will not get a number. That is not a failure of your IT team, and it does not mean something has gone wrong at your company specifically. It is what happens when a technology arrives that does not fit any of the categories your processes were built around. An AI agent is a third kind of thing. Your organization knows how to manage applications and it knows how to manage employees, and an agent is neither.

The useful part is that the fix does not require a product. It requires a decision that somebody at your company has to make, and probably has not made yet.

You have run this play before

In 2020 anyone could create a Teams site, so everyone did. By 2022 nobody owned most of them, nothing had been turned off, and the cleanup became its own project with its own budget and its own unhappy project manager.

The tooling to manage that mess did eventually arrive. It arrived roughly two years after the sprawl did, which meant every organization spent those two years accumulating exactly the problem the tooling was later built to solve.

That sequence is running again. Agents are easier to create than Teams sites were, they arrive from more directions, and the governance features are once again trailing the adoption curve. The difference is that you have seen this movie, so you already know how it ends.

A third kind of thing

Consider what your company knows about any application it runs. There is a vendor. There is a contract, and someone in procurement can tell you when it renews. There is a retirement date, or at least a conversation about one. Somebody signed for it.

Now consider what your company knows about any employee. They were hired through a process. Someone reviews their work. When they leave, a well-drilled sequence of events disables their accounts, collects their laptop, and moves their responsibilities to someone else.

An agent gets made on a Tuesday afternoon by somebody in finance who had a good idea. It runs on the access rights of whoever built it. It has no vendor, no contract, no manager, and no end date. The person who built it is frequently the only person who knows it exists.

None of this happened because anyone was careless. The platforms were designed so that ordinary employees could build these without involving IT, and that design is working as intended. Agents are also arriving inside software you already bought, switched on in a release note nobody read. Your users did what they were encouraged to do.

Every normal process misses it

Walk an agent through the processes you already trust, and watch each one fail to catch it.

Provisioning. IT tracks what IT deployed. IT did not deploy this.

Access review. Access reviews audit people, and an agent is not a person. It holds access, it uses that access daily, and it will never appear in a report built around named users.

Offboarding. Here is the one that lands. Someone builds an agent that generates client research briefs. It is useful, so they share it, and within a few months half the sales floor has quietly built it into how they work. Then that person leaves. Their account is disabled on schedule, exactly the way your process says it should be. The agent keeps running, doing work that people depend on, and there is nobody left to ask about it.

Decommissioning. Applications get retired because somebody owns the decision to retire them. Nothing retires an agent. Agents do not stop being useful, they stop being watched, and from the outside those two states look identical.

Accountability. When an application produces a wrong answer, you file a bug against it. When an employee produces a wrong answer, you have a conversation with them. When an agent produces a wrong answer, you hold a meeting about whose fault it was, and the meeting does not reach a conclusion.

The offboarding case is the sharpest of the five and worth sitting with, because it shows how complete the gap is. Your offboarding process is probably one of the most mature things your IT organization does. It has been refined over years, it gets audited, and it still does not touch this.

What to do about it

You cannot buy your way out of this yet. The tools for governing what an agent actually does are early, and the vendors selling them are ahead of what the products deliver. What follows costs nothing except the willingness to make a call.

Decide who may build an agent, and what it may connect to. This is one meeting and one page. It is also the only thing on this list that stops the problem growing while you deal with the part that already exists. Everything else depends on it, because an inventory with no rule behind it is just a longer list of things nobody owns.

The rule does not need to be restrictive to be useful. It needs to exist. “Anyone may build an agent that reads and summarizes, and anything that writes to a system of record goes through a named approver” is a perfectly good opening position, and it is a considerable improvement on the current policy at most companies, which is silence.

Put a name and a review date against every agent you already have. A named human accountable for what it does and for deciding when it stops. A date by which somebody reconfirms that both are still true. This is a spreadsheet, and it will be an uncomfortable spreadsheet to fill in, because building it is also the exercise of discovering what you have.

Do this second rather than first. An inventory taken before the rule exists is a snapshot of a number that is still climbing.

Give agents credentials that expire. Per-agent identities, narrow permissions, short lifetimes. This matters because you are not going to inventory all of them, ever, and the honest planning assumption is that some agents will be abandoned without anyone noticing. An abandoned agent with an expiring credential stops. An abandoned agent running on its builder’s permanent access keeps going, and keeps going is the whole problem.

Start with the governance decision. The cleanup is the part you repeat every quarter if you skip it.

The uncomfortable part

There is no cautionary tale to point at yet. I went looking for a published incident, an audit finding, a regulator making an example of somebody over an agent that outlived its owner. There is not one.

That is not reassurance. It is a description of where we are in the sequence. Nobody had a Teams horror story in early 2020 either, and the organizations that came out of that period well were the ones that made the boring decision early, before it became a project with a budget.

So ask the question. Ask how many agents are running, and ask who owns them. The answer is your actual starting position, and the discomfort in the room when you ask it is the useful part.

Sentinel works through this with clients regularly, and the first conversation is usually shorter and less alarming than people expect.