18,000 AI Agents Found, 300 Approved: Audit Yours

By Lazar Milicevic · Published October 13, 2026 · 9 min read

You probably have more AI agents running on your team's machines than you've approved. Claude Code on a developer's laptop, Cursor on another, a Codex CLI someone installed on a Friday afternoon. Here's what one large-company discovery scan found, and how to run a smaller version of the same audit on your own fleet this week.

What CrowdStrike actually reported

A Fortune 500 CrowdStrike customer turned on agent discovery in August 2026 and found 18,000 AI agents active on its endpoints. It had approved 300. According to VentureBeat's reporting, that gap was the opening slide of CrowdStrike President Michael Sentonas' keynote at Fal.Con 2026. CEO George Kurtz announced Falcon Guardian itself in the opening keynote, so both executives presented it.

A few caveats before drawing conclusions:

• The customer is unnamed, and the 18,000 figure comes from CrowdStrike's keynote as reported by VentureBeat. I found no independent verification, so treat it as a vendor-sourced data point.
• About 17,700 agents sat outside the approved inventory. That is not the same as 17,700 malicious agents, or even 17,700 shadow-AI installs. CrowdStrike would not say how many were truly unsanctioned shadow AI.
• The agents included tools you'd recognize: Claude Code, OpenAI Codex, Cursor and Kiro were among those identified.

So the honest reading: one very large company had no reliable inventory of what was running on its machines, and a single scan exposed a 60x gap. The number matters less than the pattern. If a Fortune 500 security team with dedicated tooling didn't know, a 6-person company relying on "everyone knows what we use" almost certainly doesn't either.

Why agent sprawl is a different problem than shadow SaaS

Shadow SaaS meant someone signing up for a tool you didn't pay for. Agents are worse for three reasons.

They inherit permissions. Sentonas said agents often inherit human permissions and are being deployed faster than they can be governed. An agent running as you can read what you can read: your ~/.aws directory, your .env files, your SSH keys, your browser sessions.

They run without you watching. A coding agent that executes shell commands, installs plugins, and calls tools is acting on your machine whether or not you're looking at the terminal.

Counts scale per person, not per company. CrowdStrike's investor briefing put the ratio at roughly 90 agents per employee, as reported by VentureBeat. That's a vendor claim, not independent data, but even if the real number for your team is a tenth of that, a headcount-based mental model of "one tool, one seat" is broken.

For a small team the practical consequence is simple: your attack surface now includes every agent any employee or contractor has installed, plus every plugin and MCP server those agents loaded.

What the demos showed (and what they didn't)

CrowdStrike ran two controlled demos at Fal.Con. They were staged, not incidents at the customer, but they're useful because they show where the real risk lives.

Demo 1: prompt injection through a GitHub issue. A Claude Code agent followed a link into a GitHub issue containing a hidden instruction to send out AWS credentials. The Falcon sensor blocked the exfiltration. A follow-up query through a Falcon MCP server found 12 agents that had used the same skill.

Demo 2: a malicious plugin. Claude Code installed a plugin from a public repository that registered a local MCP server, which then stole credentials on every tool call. The model itself was never manipulated. As VentureBeat noted, a tool watching only the prompt layer would have passed the plugin as clean.

The second demo is the one to internalize. The threat wasn't a jailbreak; it was a supply-chain problem. An MCP server is a process on your machine that your agent trusts. If you only audit prompts and model behavior, you miss the plugin sitting beside the model.

What the demos do not show: how common these attacks are in the wild. Nobody in the sources quantified that. They show feasibility and where detection has to look.

What Falcon Guardian is, and what's still future tense

CrowdStrike announced Falcon Guardian on September 1, 2026, at Fal.Con in Las Vegas. Per the press release, it's an AI Detection and Response (AIDR) product that provides visibility and runtime enforcement from the endpoint. SiliconANGLE reports it's the expanded successor to Falcon AI Detection and Response, which went GA in December and gained shadow AI discovery and endpoint runtime protection at RSAC in March.

What's in it, per the announcement:

• Discovery via the Falcon sensor on Windows and macOS, with a live inventory of every running and dormant agent, who deployed it, and its security status.
• Agent Access Controls that let admins define which agents may run on managed endpoints and block the rest.
• Prompt-layer protection: an analyst note from NAND Research says it blocks prompt injection and jailbreaks across more than 200 known attack techniques. The 99% detection and sub-100 ms latency figures are CrowdStrike's own claims.
• Identity integration: in the keynote demo, Guardian found an engineer's Claude agent and registered it with CrowdStrike's agentic identity provider (announced September 2) with no human enrolling it.
• OpenAI coverage: an expanded partnership announced September 2 means Guardian can discover Codex agents and control them at runtime.

What was not shipping at launch: AI Gateway (which covers MCP traffic) and Falcon Complete for Guardian were described in future tense in the press release. SiliconANGLE reported AI Gateway as pre-beta and due to be generally available next quarter.

Three things I couldn't confirm, which matter if you're small:

1. Pricing and general availability dates for the endpoint features weren't disclosed in anything I found. The only licensing detail confirmed is that discovery shipped as a Falcon Flex entitlement, CrowdStrike's consumption-based model. Check CrowdStrike's current pricing and sales pages for details.
2. SMB availability. It's an enterprise Falcon product. No source says a 5-person company can buy it.
3. Coverage gaps. Windows and macOS are confirmed. One secondary source warns cloud-native and containerized agents may fall outside coverage; the press release doesn't confirm that. If your agents run in Linux containers or cloud sandboxes, don't assume you're covered.

How CrowdStrike found them, and how you can do a smaller version

The most useful detail for a small team: endpoint telemetry, scheduled scans, and DNS queries surfaced the 18,000 agents. Those are three sources almost any team can approximate without buying an enterprise platform.

Source 1: What's installed and running

On each machine (or via your MDM, if you have one), look for known agent binaries, config directories, and processes.

#!/usr/bin/env bash
# agent-inventory.sh: rough local scan for common AI agent footprints (macOS/Linux)
# Extend the lists for the tools your team actually uses.

echo "== Config/data directories =="
for d in ~/.claude ~/.codex ~/.cursor ~/.kiro ~/.config/claude ~/.continue; do
  [ -e "$d" ] && echo "FOUND: $d"
done

echo "== Binaries on PATH =="
for b in claude codex cursor kiro aider; do
  command -v "$b" >/dev/null 2>&1 && echo "FOUND: $(command -v $b)"
done

echo "== Running processes =="
ps aux | grep -Ei 'claude|codex|cursor|kiro|mcp' | grep -v grep

echo "== MCP server configs =="
find ~ -maxdepth 4 \( -name '.mcp.json' -o -name 'mcp.json' -o -name 'claude_desktop_config.json' \) 2>/dev/null

This is crude and will miss renamed binaries, but it takes five minutes and usually surprises people. The MCP config search is the part most teams skip, and it's where the credential-stealing plugin from Demo 2 would register itself.

Source 2: DNS and network egress

Agents talk to model APIs. If you run a DNS filter or firewall with logs (Cloudflare Gateway, NextDNS, your router's resolver), look for query volume to model-provider domains by device.

# Example: count lookups per client for AI API domains in a resolver log export
# Adjust the domain list and log format to your setup
grep -Ei 'anthropic|openai|cursor|kiro' dns-export.log \
  | awk '{print $CLIENT_FIELD}' | sort | uniq -c | sort -rn

Replace $CLIENT_FIELD with the right column for your log format. The point isn't a perfect parser; it's seeing which devices are making agent-style traffic that nobody registered.

Source 3: Repeat it on a schedule

CrowdStrike's third source was scheduled scans. A one-time audit decays within a month. Put the script on a weekly cron or MDM schedule and diff the output.

Build the register

Whatever you find goes into a simple inventory. Keep it boring:

# agent-register.yaml
- agent: claude-code
  owner: dana@example.com
  machine: dana-mbp
  approved: true
  scope: "repo: billing-service only"
  mcp_servers: [github, postgres-readonly]
  secrets_reachable: [".env.local"]
  last_reviewed: 2026-10-13
- agent: cursor
  owner: unknown-contractor
  machine: unknown
  approved: false
  action: "identify owner, then approve or remove"

The secrets_reachable field is the one that earns its keep. An agent's risk is mostly a function of what it can touch.

Triage: what to do with what you find

Don't try to block everything. You'll push people toward hiding it. Sort findings into four buckets:

Then fix the highest-leverage things first:

1. Move long-lived credentials out of reach. Short-lived, narrowly scoped tokens beat a full-access key in a dotfile. If an injected instruction can only reach a read-only token, the blast radius shrinks.
2. Allowlist MCP servers. Treat each one like a dependency with code execution. Pin sources, review before adding, and remove ones nobody can justify.
3. Isolate the risky work. VentureBeat's tracker (July 2026 wave) found only 18% of 116 enterprises isolate their highest-risk AI agents, and just 8% pair enforcement with isolation. For a small team, isolation can be as simple as running agents that touch untrusted input (issues, emails, web pages) in a throwaway container or VM with no credentials mounted.
4. Give each agent an owner. An unowned agent is an unreviewed agent. Every row in the register needs a human name.

Decide: buy a platform or build the basics

Be honest about what you need. Guardian is an enterprise product, and nothing I found confirms SMB pricing or availability. Here's how I'd frame the decision:

The manual approach has real limits: it's point-in-time, it won't block anything in real time, and it relies on people keeping the register honest. Runtime enforcement, meaning the ability to stop an exfiltration mid-flight as in the GitHub-issue demo, is what the paid platforms add. If your agents handle customer data or production credentials, weigh that gap seriously.

How BizFlowAI approaches this

I build AI automations for small teams, which means I see the sprawl up close: the second MCP server someone added "just to test," the agent running under a founder's personal credentials, the plugin nobody remembers installing. Eighteen thousand versus three hundred is the same shape of problem at a different scale.

The audit steps above are the ones I'd follow for any small team: inventory what's installed and talking to model APIs, map each agent to an owner and the secrets it can reach, consolidate duplicates onto a small approved set, and put scoped credentials and an MCP allowlist in place. The output should be a register your team can keep current, not a slide deck.

Work with BizFlowAI

If you'd rather have this built for you, that's what we do: production AI automation for solo founders and small teams — agents, integrations, and document pipelines that actually ship.

Request a free discovery call — 30 minutes, we map the highest-ROI automation in your workflow. No pitch deck, just engineering.

More guides like this on the BizFlowAI blog.