Ask a room of engineering leaders how many AI agents their company runs. The confident answers are the wrong ones.
Agents don’t arrive through procurement, with a kickoff meeting and a line item. They arrive sideways. A developer wires one into CI to triage test failures. Someone in ops gives one an inbox. A SaaS vendor ships an “AI teammate” feature and a team lead toggles it on during lunch. Each decision was small, local, and reasonable. Nobody wrote any of them down, because none of them felt like the kind of thing you write down.
Six months later there are three questions the company cannot answer:
- What agents do we actually run? Not “which AI tools are approved.” Which pieces of software, right now, can take actions on our behalf without a human touching each one?
- What do they hold? Every agent carries credentials: API keys, service accounts, a logged-in session, somebody’s OAuth grant from eight months ago. Those credentials don’t expire when the enthusiasm does.
- Who notices when one misbehaves? Not hypothetically. Which named person gets the alert, and does an alert exist?
If those questions feel unanswerable, congratulations: you have rediscovered asset management, which is both better news and worse news. Better, because your company already knows how to do asset management; it does it for laptops, servers, and SaaS seats, and none of that required understanding transformers. Worse, because asset management is the least glamorous work in security, and agents are the first asset class that acts.
Every agent has a builder. Few have an owner.
The pattern I keep seeing: the person who set up an agent understands it completely, and that person is the inventory. Then they change teams, or the vendor changes the feature, or the workflow quietly grows a second agent that feeds the first. The knowledge doesn’t transfer, but the credentials do. The agent does not attend the handoff meeting. It just keeps running, holding whatever access it was granted on its most ambitious day.
A builder is not an owner. An owner is a named person who can answer, this quarter, four questions: what does it do, what can it touch, what is it allowed to do without asking, and how do we turn it off. That last one sounds dramatic until the first time you need it at speed, at which point it is the only question.
The starter list
You don’t need a platform, a committee, or a budget line. You need a spreadsheet with seven columns:
- Name and job: what the agent does, in one sentence a non-builder understands
- Owner: a person, not a team alias
- Credentials: every key, account, and grant it holds
- Reach: the systems it can read, and the shorter, scarier list it can write to
- Autonomy: what it may do without a human tap
- Logs: where its actions land, and who ever looks
- Off switch: the tested way to stop it today
If the last column is empty, you haven’t deployed an agent so much as adopted one.
Two predictions from having done this exercise with real teams. First: the list will be longer than you expect, and the surprises won’t be the flashy coding agents; they’ll be the quiet integrations someone connected in the spring. Second: the exercise takes an afternoon, and it will be the highest-leverage afternoon your security program spends this year, because every control anyone will try to sell you (approval gates, egress rules, monitoring, all of it) silently assumes the list already exists.
Start with the list. Nothing about it is interesting, which in security is usually how you spot the part that matters.