Best AI Security markBest AI Security

NOTE · 2 SEPTEMBER 2026

How to inventory AI agents and MCP servers on employee devices

The verdict

Start by defining what counts (agents, coding assistants, desktop AI apps, extensions, local MCP servers, skills and the credentials they can reach), then collect it from the devices themselves, ideally through the EDR or MDM you already run. Record who uses each item and what it can touch, sort everything into approved, approved with conditions and blocked, and re-check often, because agents and MCP servers are added from a terminal in seconds.

A practical method for the first job in AI agent security: knowing what is installed, who runs it and what it can reach.

By Best AI Security editors · 2 September 2026 · 5 min read

Why start with an inventory?

Every control that comes later depends on it. A rule that asks before a coding agent runs a cloud CLI is only useful if you know which devices have that agent, which MCP servers it loads and which credentials sit on the same machine. The four checkpoints we use across this site (see, decide, allow or block, log) start with "see" for that reason.

The inventory is also the fastest way to answer the question CIOs ask first: how much AI is already in use? Harmonic Security, summarizing Gartner's Market Overview for AI Usage Control in August 2026, quotes Gartner's prediction that "by 2030, more than half of enterprises will use dedicated AI usage control technologies." Whether or not a company buys a tool, the first deliverable is the same list.

Step 1: What should the inventory include?

Chatbots in a browser tab are the easy part. The items that carry the most risk on a laptop are the ones that act. Build the list around these categories:

  • Agents and coding assistants, such as Claude Code, Codex and Cursor, plus desktop AI assistants.
  • MCP servers configured for each agent, including servers a user added themselves. The MCP specification describes local servers as binaries downloaded and executed on the same machine as the client.
  • The command that launches each local MCP server. The specification lists a malicious startup command in a client configuration as an attack path.
  • Extensions, plugins and skills: browser AI extensions, IDE extensions and packages pulled from marketplaces.
  • Credentials and files each agent can reach: tokens, cloud CLI profiles, SSH keys and source code.
  • Settings: whether permission rules, hooks and allowed MCP servers are centrally managed or left to the user.

Source: MCP Security Best Practices · Reviewed Sep 2026

Step 2: How do you collect it from the devices?

Network logs will miss much of this. Many agents talk to their providers over ordinary HTTPS, and a local MCP server may never touch the corporate network. Collection has to happen on the device. The vendors on this site use four routes, according to their public pages:

From public vendor pages reviewed September 2026.
ToolHow its public pages describe discovery
BayAn ephemeral binary that runs through your existing MDM or EDR and inventories AI agents, MCP servers, tools, credentials, extensions, settings and endpoint deployments.
Noma SecurityDiscovers endpoint agents such as Claude Code, Cursor and Codex, with their MCP servers and skills, through existing EDR or MDM.
Harmonic SecurityRolls out through Intune, JAMF, Kandji or Group Policy, covering browser extensions, desktop apps and CLI tools.
Koi (Palo Alto Networks)Visibility into models, MCPs and extensions, as a Cortex XDR module or standalone.
Prompt SecurityInventories AI tools and code assistants, maps agents and MCP servers, built into the SentinelOne Singularity Platform.
Bloom SecurityFleet-wide discovery of software, extensions and AI, with policies across npm, Chrome Web Store and Open VSX.

The practical choice is between a route that uses tooling already on every device and one that adds a new component. Reusing EDR or MDM avoids another rollout; a dedicated agent or browser extension may see more in real time. Ask each vendor which one it uses and what changes on a developer machine.

Step 3: What should each inventory record hold?

A name and a version are not enough to make a decision. For each agent or MCP server, record:

  1. Device and user, so an action can later be tied to a person.
  2. The agent or client that loads it, and its version.
  3. For MCP servers: local or remote, the transport (stdio or HTTP), and the full launch command for local servers.
  4. Where it came from: an approved catalog, a marketplace, or a user's own configuration.
  5. What it can reach: files, credentials, internal APIs and cloud accounts.
  6. Whether its settings are centrally managed.

The MCP specification says servers intended to run locally should use the stdio transport, or restrict HTTP access with an authorization token or an IPC mechanism. A local server left listening on localhost without either is worth flagging on its own.

Step 4: How do you sort what you find?

Sort every item into three groups. Approved: allowed for everyone. Approved with conditions: allowed for a team, with some actions set to ask first, for example a coding agent allowed in engineering with shell commands that touch production credentials paused for confirmation. Blocked: removed or denied. Most of the value sits in the middle group, because it lets IT say yes to tools employees already want. Our shadow AI guide covers why blanket blocking tends to push use onto personal devices.

Step 5: How do you keep it current?

An inventory taken once goes stale within days, because a new MCP server is one line in a configuration file. Three checks keep it useful:

  • Measure how long a newly installed agent takes to appear. Ask vendors this directly; it is question 5 in our buyer's checklist.
  • Watch for changes, not only for new items: a new MCP server added to an approved agent, or a changed launch command.
  • Export the list to your asset or CMDB tooling so it sits with the rest of your device records.

What comes after the inventory?

The inventory feeds the policy. Once you know which agents run where, you can decide which actions to allow, which to ask about and which to deny. Our note on writing an allow, ask or deny policy picks up from here, and the rankings show how each tool scores on endpoint visibility.

Related

Sources