Shadow AI Inventory: Every AI Client on Every Endpoint

Ask a security team which AI tools their developers use and you get a list. Ask the endpoints and you get a longer one. That gap is shadow AI, and you can't govern what you can't see. The Autonomous Security endpoint agent closes it: a shadow AI inventory across more than 40 AI clients on Mac, Windows and Linux, with the MCP servers, skills and extensions each one carries, and who runs them.

Why a shadow AI inventory starts on the endpoint

The AI tools developers use most don't live in a browser tab. They are IDEs with assistants built in, coding agents in the terminal, desktop chat apps, and local model runners. They install in a minute, update themselves, and each one can be extended: an MCP server here, a skill there, a plugin from a marketplace.

None of that shows up in a SaaS log or a network proxy in a useful way. A coding agent that talks to a model looks, from the network, like any other HTTPS traffic. The MCP server it launched on the laptop doesn't talk to the network at all until it does something. The place to find out what is installed, and what it is wired to, is the machine itself.

What the agent finds

Install the endpoint agent through your MDM or by hand, and each machine reports:

The AI clients installed: Claude Code and Claude Desktop, Cursor, VS Code and GitHub Copilot, Codex and the ChatGPT desktop app, Gemini CLI, JetBrains IDEs, Windsurf, Zed, Kiro, Cline, Continue, Goose, LM Studio and more: over 40 in all.
What each one is wired to: the MCP servers configured in it, the skills and extensions it loads, and the settings that decide what it may do on its own.
Who uses them: by endpoint and by user, so an inventory line has an owner to talk to.
What they do, for the clients that report it: the prompts sent and the tool calls made, in one place across clients.

The inventory updates as things change. A developer who adds an MCP server to Cursor on Tuesday shows up with it on Tuesday, not at the next quarterly survey.

An example

A platform team rolls the agent out to its engineering laptops. Within a day the inventory shows the expected coding agents, and some unexpected things around them:

an MCP server pointing at a production database, configured in two developers' desktop chat apps;
a community MCP server for a project tracker, installed from a public repository last week, on a dozen machines;
a skill copied from a blog post that runs shell commands, loaded in one agent;
a local model runner nobody had heard of.

None of it is malicious. All of it is exactly what a security team needs to know before something goes wrong: which data an agent can reach, and through what.

From inventory to decisions

An inventory is useful because of what you do with it. It tells you which MCP servers and skills to look at first, and an MCP server approved once deserves a second look when it changes (approved once, trusted forever). And it is where policy starts: decide which MCP servers are allowed and which are not, and the agent enforces it on the clients that support it.

That is the order we recommend:

See: deploy the agent and let the inventory fill for a few days.
Sort: look at what is wired to sensitive systems and what came from unknown sources.
Decide: approve what is fine, talk to the owners of what isn't, and put policies on the rest.

We wrote earlier this year about why MCP is where AI risk becomes real: the model only talks, while the tools act. The endpoint is where those tools are configured, so it is where the inventory has to come from.

Mac, Windows and Linux

Developers don't all use the same machine, and an inventory that covers only some of them is a list of the places you looked. The agent runs on macOS, Windows and Linux, deploys through the device management you already use, and keeps itself up to date, so it covers the whole fleet rather than the part that was easy to reach.

See your shadow AI

Most teams are surprised by the first inventory, not because it is alarming, but because it is long. Start a shadow AI free trial, deploy the agent to a few machines, and see what your developers' AI clients are wired to.