How to Find the AI Agents Your Staff Already Run

To find the AI agents your staff already run, look in three places before you write a policy: the laptop (agent config folders and listening ports), the network (traffic to model-provider APIs) and the identity provider (OAuth grants and API keys). Microsoft’s Defender for Endpoint now keeps an inventory of AI agents on managed devices, and its support matrix, last updated in October 2026, lists 60 of them for Windows. This guide shows how to run the same sweep with or without Microsoft’s tooling.

The vendor selling the inventory is also the one sounding the alarm. “Unfortunately, frontier models, regardless of their origin, cannot be trusted,” Hayete Gallot, who runs Microsoft’s security business, wrote in a Microsoft blog post on 19 October 2026, as TechCrunch reported. The same report says Defender’s agent detection “can find up to 60 types of agents that employees bring into the workplace, including Claude Code, Codex, and OpenClaw.” The support matrix itself, dated 7 October 2026, lists 60 agents for Windows, so the two figures agree.

Why are shadow AI agents different from shadow AI chat?

A chatbot in a browser tab answers questions. An agent on a laptop reads files, runs commands and calls other systems with the employee’s own access. With chat, data leaves through what someone pastes into a box. With an agent, data also leaves through the agent’s tools, without anyone pasting anything, which is why a chat policy does not cover it.

The Cloud Security Alliance’s OpenClaw hardening guide of 31 March 2026 cites Token Security: “approximately 22 percent of employees among its enterprise customer base were running OpenClaw, overwhelmingly without IT knowledge or approval.”

The same guide notes: “OpenClaw binds its gateway to 0.0.0.0:18789 by default.” That address means every network interface, so other machines on the same network can reach the agent’s gateway, not only the laptop it runs on. An employee’s personal assistant becomes a service on your network that nobody registered, with its own credentials and none of the controls you apply to non-human identities.

Where do AI agents leave traces on a laptop?

Most AI agents keep a config folder in the user’s home directory, and that config lists the tools (MCP servers) the agent may call. Finding the folders tells you who runs which agent. Reading the MCP config tells you what data each agent can reach. The locations below come from each vendor’s own documentation.

The CSA guide gives the same advice for OpenClaw: endpoint detection “should be configured to identify running OpenClaw processes, listening WebSocket ports (default 18789), and the presence of the ~/.clawdbot or ~/.openclaw directory structures.” Any EDR can search for folder names and listening ports, so the first sweep needs no new product.

Step 1: Sweep endpoints for agent folders and ports

Run one EDR or MDM query across all managed laptops for the folder names in the table and for any process listening on port 18789. Export the host, the user and the last-modified date of each folder. A folder touched this week is probably a live agent; one untouched since spring is more likely a forgotten test.

If you run Microsoft Defender for Endpoint, its agent inventory does much of this for you, with two limits stated in Microsoft’s own documentation. The runtime protection page is still marked “(Preview)”. And the support matrix says discovery is based on activity: “Installing an agent doesn’t by itself guarantee that the agent appears in the local AI agent inventory.” An agent installed but idle on the day you look will not show up.

In our experience, sort the results by user, not by host. One developer often runs three agents, and the conversation you need to have is with the person, not the laptop.

Step 2: Check proxy and DNS logs for model APIs

AI agents talk to model providers. Search your proxy or DNS logs for the provider API hosts, for example api.anthropic.com, which Claude Code’s network requirements list for its API requests, and api.openai.com, and list the internal hosts that call them. A host with steady API traffic outside office hours points to an agent, not to a person typing.

Browser chat apps reach the same providers, so treat a hit as a lead, not proof, and match it against Step 1. One gap matters: an agent pointed at self-hosted models, for example Ollama on the same laptop, makes no external API calls at all. For that agent, Step 1 is the only net.

Step 3: Read the OAuth grants and the expense reports

AI agents need credentials, and credentials leave records. Check which third-party apps employees have consented to in your identity provider, and ask finance for card and expense lines from AI providers. An API key paid on a personal card and claimed back as an expense is a strong sign of an agent nobody approved.

• Microsoft Entra ID: Enterprise apps > All applications > [app] > Permissions, then the User consent tab, per Microsoft. Revoking those grants needs Graph or PowerShell; the portal cannot do it.
• Google Workspace: Admin console > Security > Access and data control > API controls, then the Accessed apps list, which lists the apps that have accessed Google data.

In our view this is the cheapest step and the one teams skip. A consent grant to an agent is also a token someone can steal, which is the risk we covered in stolen agent session tokens.

Step 4: Inventory the MCP servers, not just the agents

The agent is the engine; the MCP servers are its hands. The risk sits in what each agent is connected to: a code repository, a CRM, a mail account. List the MCP servers from every config file you found in Step 1 and rank them by the data they expose. A coding agent with only a local file server is a different problem from one wired to the customer database.

Microsoft’s matrix has a separate “Discovers MCP” column. Check where each server came from, too: an MCP server or skill installed from a public marketplace carries the supply-chain risk we described in agent skill marketplaces.

What should you do with the agents you find?

Register them, scope them and log them; do not start with a ban. In our view a ban moves the agents to personal laptops, where you see nothing at all, and the people who use them most are often the ones you most want to keep.

Satya Nadella put the principle in one line, in a blog post quoted by TechCrunch: “we need to separate the supply of intelligence from the authority over it.” In practice that means each registered agent gets its own identity and only the permissions its task needs, and every write action sits behind an approval step outside the model.

Microsoft’s own controls follow the same line. According to TechCrunch, it has “added features that limit agents’ access to data and systems, and dynamically adjust their agent permissions based on the task,” including “requiring human approval if an agent appears to be making risky decisions.” You can build the same thing without Microsoft: a write-action allowlist for agents with web access and guardrails for coding agents with shell access.

The first sweep fits on one page:

• One endpoint query for the agent folders and port 18789.
• One proxy or DNS search for model-provider API hosts.
• One consent review in Entra ID or Google Workspace, plus the expense lines.
• One list of MCP servers per agent, ranked by the data they reach.

Then run it again in 30 days. New agents keep appearing, and the 60 in Microsoft’s October matrix will not be the last count.

Related reading

• Securing AI agents as non-human identities
• When not to use an AI agent
• Prompt injection cannot be patched