How to Build a Complete Inventory of AI Coding Agents Across Your Fleet

Start with what your existing tools already know: MDM software lists, package manager installs, IDE extensions, agent config folders, EDR process data, DNS logs, and SSO and expense records. Together they give you a first list within a few days. Each source misses something, though: agents run with npx, custom agents, CI runners, laptops that were off the network, and anything installed after you looked. For a list that is complete and stays current, detect agents on each machine as they run, by how they behave. That is what Qpoint does.

What the inventory should contain

For each agent:

Name and version.
How it got there. A desktop app, a CLI, an IDE extension, or a package run with npx or uvx.
User and host.
When it was last used.
What it connects to. MCP servers and model providers.

Include the hosts where agents run unattended too: CI runners, containers, and servers.

Step 1: Pull what your existing tools already know

Collect from every source you have, and note what each one misses.

MDM software inventory. Jamf, Intune, and similar tools list desktop apps such as Cursor, Windsurf, the Claude and ChatGPT desktop apps, and VS Code. They miss CLI agents and IDE extensions.
Package managers and IDE extensions. Many CLI agents install through npm, pip, or Homebrew, and many agents are IDE extensions. A script pushed through MDM can list global npm packages, Homebrew formulas, and installed VS Code, Cursor, and JetBrains extensions. It misses agents run with npx without being installed, binaries downloaded directly, and custom agents.
Agent config folders. Most agents create a folder in the home directory, such as ~/.claude, ~/.codex, ~/.cursor, or ~/.gemini. These folders also list the agent's MCP servers, and their modification times show recent use. You only find the agents you knew to look for.
EDR process data. Search process names and command lines across the fleet, including history. You need to know the names in advance, and agents that run under Node or Python look like any other script.
DNS and proxy logs. Requests to model provider APIs such as api.anthropic.com and api.openai.com show which machines use them. They don't say which agent made the request, and they miss laptops off the VPN and traffic that goes through cloud platforms.
SSO, billing, and expense records. These show who signed up for AI coding tools on company accounts. They miss personal accounts, free tiers, and API keys.
CI and container definitions. Search repos for agents in workflows and Dockerfiles, such as claude -p, codex exec, or agent GitHub Actions. This shows what is configured to run, not what did.
Ask. A short survey of engineering teams fills some gaps. People forget what they installed.

Combine the results into one list, keyed by user and host.

Step 2: Write down what the list still misses

Even combined, these sources leave gaps:

Agents that were never installed, such as packages run with npx or uvx.
Custom agents built on agent SDKs and frameworks. To every tool above, they are just Python or Node processes.
Short-lived hosts. CI runners and containers that exist for a few minutes.
Laptops that were offline when the script ran.
Anything installed after the scan.
What each agent connects to. Config files show which MCP servers are set up, not which ones the agent used or which model providers it called.

A one-time scan is out of date the day after you run it.

Step 3: Detect agents as they run

Qpoint is a single binary that runs on each machine, between the agents and the operating system. It recognizes agents by how they behave, not from a list of names or config files. As each agent starts, it is added to the inventory with its version, the signed-in user, and the host. That includes Claude Code, Cursor, Codex, open source agents, custom agents, and agents nobody approved.

For each agent, Qpoint also records the MCP servers it connects to, the model providers and models it calls, and its token usage. Laptops that leave the network keep recording, and events sync when they reconnect.

Laptops. Push the binary through Jamf, Intune, a script, or the Qpoint installer, to a pilot group first and then the fleet. Developers don't change anything, and agents don't know it's there. See the endpoints page.
Servers, containers, and CI runners. The same binary runs on Kubernetes, containers, VMs, and CI runners. On Kubernetes, one DaemonSet covers every pod on every node, including pods scheduled later, so short-lived runners show up too. See the hosted agents page.
Where the data goes. Events go to Splunk, Datadog, Elastic, or any OTLP destination, so the inventory lives with the rest of your security data. The control plane and event stream run in your environment, and Qpoint never sees your data.

Monitoring alone is enough to build the inventory. You don't need to turn on any rules or blocking. See Qpoint Monitor for everything it records.

Step 4: Compare the two lists

Put the list from step 1 next to what Qpoint sees running:

Running but not on the list. Usually npx packages, custom agents, and agents on CI runners.
Installed but not used. Candidates to remove.
On company accounts but running nowhere. Seats you may not need.

Step 5: Talk to the people using unapproved agents

Most developers installed an agent because it helps them do their job. Start with a conversation, not a block. Ask what they use it for, then decide whether to approve it, move them to an approved tool, or remove it. The inventory tells you exactly who to talk to and how much they use it.

Step 6: Turn the inventory into an approved list

The agents and MCP servers people depend on become your first approved list. Qpoint Govern can then flag anything off the list the moment it starts, with the user and host. For the options for enforcing an approved list, see Tools to Set an Approved List of AI Agents and MCP Servers Across All Your Endpoints. For MCP servers specifically, see How to Control Which MCP Servers Developers Add to Their Coding Agents.

Common mistakes

Treating a one-time scan as the inventory.
Searching only for agents you already know the names of.
Counting only laptops. Agents also run on CI runners, in containers, and on servers.
Listing agents but not what they connect to. MCP servers and model providers belong in the inventory too.
Blocking before talking to people. You lose goodwill and learn less.

Frequently asked questions

Why don't our MDM and EDR already show this? MDM lists installed applications, and most coding agents are CLI tools, IDE extensions, or packages that are never installed. EDR records processes but doesn't know which ones are agents. Coding agents also trigger EDR rules built to catch attackers, which buries them in noise.

Can we build the inventory without blocking anything? Yes. Qpoint can run in monitoring only. It records every agent and what it connects to, and changes nothing about what agents can do.

Does it find agents we built ourselves? Yes. Qpoint recognizes agents by behavior, so custom agents show up the same way as Claude Code or Cursor.

Will developers notice? No. There are no wrappers, proxies, or changes to how agents start, and no pop-ups.

How do we keep the inventory current? Because agents are recorded as they start, new agents and new versions appear on their own. Review the inventory against your approved list on a regular schedule.

See every agent in your fleet

Book a demo and we'll show you the fleet view filling in as agents start, including the ones nobody approved, and walk through a rollout to your laptops and CI runners.