Your AI Agent Inventory Is Not a Security Program

Many security teams now have a report of every AI agent running in their environment. And this is real progress, because a year ago most could not name a single one. But while a list of agents is a starting point, it is not an answer. It tells you the agents exist, but it does not tell you what they can reach, what they can do, or who is responsible for them.

Inventory is not intelligence. To manage the risk, you have to turn the list into something you can act on.

Agents Have Access. And They Actually Use It

This is the point most reports miss. An AI agent cannot do anything on its own. To read data, call an API, or change a system, it has to authenticate. It does that with an identity: an API key, a token, a service account, an OAuth grant, or the credentials of the person running it.

So the agent is the actor, and the identity is the access. When you ask “how dangerous is this agent,” the real question is “which identities can it use, and what can those identities do.” An agent with no powerful identities behind it is a limited risk. An agent that can reach a service account with broad cloud permissions is a serious one. The label on the report does not tell you which is which. The identities do.

Why Coding Agents Are the Hard Case

Look at the coding agents on the list: Cursor, Claude Code, Amazon Q, Codex, Cline, Devin, OpenHands. These deserve special attention, for two reasons.

First, they run where the most powerful credentials live. A developer’s machine usually holds cloud login sessions, git tokens, SSH keys, secrets in configuration files, and direct access to databases and pipelines. A coding agent on that machine can use all of it. It does not need its own access. It uses the developer’s.

Second, most of them can run code. A tool that only suggests text is limited. A tool that can run shell commands can act, with every credential on the machine. Many of these agents have an auto-accept mode that removes the human approval step. With that setting on, the agent acts on its own, using real access. That one setting is the difference between a helper and an unsupervised process holding production keys.

Sort Before You Secure

The agents on your report are not equal, so do not treat them as one group. Sort them first.

• Local coding tools on developer machines. The risk is the endpoint and the credentials on it.
• Cloud agents that run on their own. The risk is the access you gave to an outside service.
• Self-hosted tools you run in your environment. The risk is your own deployment and how exposed it is.
• The ones no one can explain. If no one knows who installed it or why it has access, start there.

Then rank within each group by four factors: can it run code, how powerful are the identities it can reach, is it signed in with a managed company account or a personal one, and did anyone approve it. This turns a flat list into an ordered set of work.

The Four Questions That Turn a List Into a Plan

For each agent, ask:

What can it reach? Map the identities it can use and what those identities can access. This is the blast radius.

What can it do? Reading data is an exposure risk. Taking action is an integrity risk. Separate the two.

Who controls it? Every agent needs a named owner and a clear purpose. Agents driven by outside input, such as an email or a web request, can be tricked into acting. Know where a human approves actions, and whether that step can be skipped.

Would you notice? Check whether the agent’s actions are logged and tied to that specific agent. If it went wrong at three in the morning, would anyone see it, and could you stop it.

Where This Lands

AI agents are a new kind of actor, but they run on access you already manage. They use the same identities, keys, and tokens your other systems use. That is good news. You do not need a separate program for agents. You need to extend the way you already govern non-human identities, and account for one new fact: these actors can decide and act on their own.