Every CISO has a number in mind for “AI agents in our environment.” The first real inventory always comes back high. Always.
Why Agent Inventories Matter Now
The first time a security team runs a real discovery sweep across their fleet, the result is uncomfortable. A 1,000-endpoint engineering org will routinely surface 8 to 15 distinct AI agents in active use — most unsanctioned, most with broader permissions than any enterprise application that ever passed the procurement gate. The sweep takes hours. The follow-up budget conversation takes thirty minutes.
This is the agent equivalent of the early-2010s shock when EDR vendors first scanned managed endpoints and discovered persistent, signature-evading malware on systems that had been “clean” by AV for years. The instrumentation revealed an exposure the existing controls had no way to see. Mark to market on agents looks the same way: until the inventory exists, the position cannot be priced.
| First-Sweep Finding | Typical Range |
|---|---|
| Distinct agent binaries detected | 8–15 per 1,000 engineering endpoints |
| Share unsanctioned (not in procurement register) | 60–80% |
| Median time-to-budget-approval after the inventory lands | Under 30 minutes |
| Agents with persistence (registry, launchd, cron, login items) | Roughly 40% |
These ranges come from active deployments — what we see when a discovery agent is pointed at a real engineering fleet. They are not survey data, and they are not invariant across industries. But they are consistent enough that no CISO who has run the sweep has been surprised by the direction of the surprise.
Sanctioned, Tolerated, and Stranger Agents
The taxonomy that holds up under field conditions is not “approved vs unapproved.” It is three buckets, sized by what the procurement process actually knows about each binary.
| Bucket | Definition | Typical Share | Treatment |
|---|---|---|---|
| Sanctioned | Procured, in TPRM register, MSA signed | 15–25% | Full fleet rollout, monitored |
| Tolerated | Known to leadership, pilot or BYOL, no contract | 25–40% | Conditional access, scoped at runtime |
| Stranger | Surfaced only by inventory, no organizational record | 35–60% | Quarantine, classify, then decide |
The “stranger” bucket is where the surprise lives. These are the binaries the security team has never seen the name of, that no engineering manager remembers approving, that arrived as a transitive dependency of something else, or that one developer on the data team installed in a free-trial moment six months ago and forgot. They mark to market against the firm’s risk tolerance the same way an off-book trade marks against the trading book — uncomfortably, and only at the moment of inventory.
What the First Sweep Surfaces
Patterns from the signature pipeline show up consistently across customers. The same handful of failure modes account for most of the genuinely surprising findings:
- Vendor-renaming. An agent purchased under one product name installs a binary under a different name, stripping the procurement linkage. The inventory shows a stranger; the contract is filed under the marketing brand.
- Registry persistence on tools billed as “no install required.” Browser-extension agents that promise zero footprint nonetheless write
HKCU\Softwarekeys for session continuity. A pilot ends; the registry entry stays. - Cron and launchd entries from CLI agents. Standalone agents — Aider, Continue, Cline, Goose — installed via Homebrew or pip routinely register themselves to run on login. The agent is alive even when the user thinks they closed it.
- MCP server inheritance. A user installs Claude Desktop, configures one MCP server for a side project, and that MCP server now has the same broad filesystem and network scope as Claude Desktop itself. The MCP binary is the strangest stranger — no user remembers installing it.
Each of these is invisible to the existing stack. EDR sees a process; it does not see a permission scope. DLP sees a file move; it does not see the agent that requested it. The inventory sweep makes the exposure measurable for the first time, which is the precondition for every other control decision that follows.
Pricing the Exposure
Once the inventory is in hand, the budget conversation accelerates because the math is suddenly concrete. The frame that lands with CFOs is portfolio risk, not threat narrative.
Agent Exposure = (Agent Count × Average Permission Scope) × (Reversibility Discount × Detection Lag)
| Factor | Plain Language | Why It Matters |
|---|---|---|
| Agent count | How many distinct binaries are running | The denominator most CISOs cannot produce on Monday |
| Average permission scope | OS, network, data — what the agent can touch | Scope is the size of the position |
| Reversibility discount | Can a bad action be undone? | A git push --force agent is a different position than a “draft email” agent |
| Detection lag | Time from action to security visibility | If you cannot mark the position daily, you cannot hedge it |
This frame travels well from CISO to CFO to board. It also reframes the problem from “should we allow AI” to “what is our current exposure, and how do we want to size it?” The second question always gets funded. The first question stalls.
What This Means for the Existing Stack
The first inventory does not invalidate the existing security investments. It reframes them. EDR, DLP, CASB, SIEM all continue to do what they do. The gap they leave is the gap an agent firewall closes.
| Control | What It Sees | What It Misses |
|---|---|---|
| EDR (CrowdStrike, SentinelOne, Defender) | Process tree, syscalls, behavioral indicators | Permission scope, the prompt that asked for the action |
| DLP (Symantec, Forcepoint, Microsoft Purview) | File movement, classification, exfiltration | Agent-mediated transformations, paste-into-prompt flows |
| CASB | Sanctioned SaaS API traffic | Browser-resident agents acting on behalf of the user inside the SaaS |
| Prompt guardrails (Lakera, Protect AI) | Prompt content, model output | What the agent does after the prompt resolves at the OS layer |
The agent firewall sits at the kernel scope — between the agent’s plan and the action that touches the file system, the network, or another process. That is the control point the inventory reveals as missing. None of the existing tools is wrong; they are just instrumented one layer up from where the agent actually decides what to do.
What CISOs Should Do This Quarter
| Step | Action | Output | Effort |
|---|---|---|---|
| 1 | Run an agent discovery sweep across the engineering fleet | Distinct agent binaries with persistence indicators | 1–2 days |
| 2 | Sort the list into sanctioned / tolerated / stranger | A budget conversation with concrete numbers | Half a day |
| 3 | Pick the 3 strangers with highest permission scope | A pilot quarantine policy at the kernel layer | 1 week |
| 4 | Brief the board on agent exposure as a portfolio metric | Funded program, not a one-off remediation | 1 meeting |
Step 1 is the work that breaks the rest of the timeline open. Without an inventory, the conversation stays abstract. With one, the next three steps schedule themselves.
The Bottom Line
The first agent inventory is the moment AI security stops being a research topic and becomes a budget line. Every CISO who runs the sweep finds more agents than they expected, faster than they expected, with more permission scope than they expected. The exposure is measurable, the controls to manage it are architecturally distinct from anything in the current enterprise security stack, and the next twelve months of security spend will look different from the last twelve.
If your team is sizing agent governance for the 2026 budget cycle, request a working session. We will run a sample inventory against a slice of your fleet, classify the findings into sanctioned / tolerated / stranger, and scope a kernel-scope deployment that closes the gap. Ninety minutes.