How to find every AI tool your employees use: a 2026 checklist

"Which AI tools do our employees use?" is the first question in almost every AI governance programme, and most answers to it are too short. That is not because people hide things. It is because the usual ways of looking were built for websites, and a growing share of AI at work is not a website.

The scale is not in doubt. Microsoft's 2024 Work Trend Index found that 78% of AI users bring their own AI tools to work. In a Cloud Security Alliance survey published in April 2026, 54% of organisations reported between 1 and 100 unsanctioned AI agents, and only 16% were highly confident they could detect threats specific to agents.

78%

of AI users bring their own AI tools to work (Microsoft Work Trend Index, 2024, 31,000 people)

71.6%

of access to generative AI tools ran through non-corporate accounts (LayerX, 2025)

54%

of organisations report 1 to 100 unsanctioned AI agents (CSA, April 2026, 445 respondents)

16%

are highly confident they can detect agent-specific threats (same survey)

Where AI lives on a laptop#

Start with the machine, not the tools you look with. AI on a work laptop sits in five layers, and only the top two leave traffic that a network tool can put a name to.

The bottom half is where the risk sits. A coding agent set to run commands without asking can act on whatever it reaches. A local model, run through Ollama or LM Studio, sends nothing over the network once it is downloaded. And a local MCP server is not a network service at all: it is a process the agent starts on the same machine. Our study of the official MCP Registry, MCP in the wild, counted 18,334 local (stdio) servers, and 37.4% of them declare a secret, which has to sit on the laptop that runs them.

What each discovery method sees#

There are three usual sources, and each has a blind spot.

Network, proxy and CASB logs see traffic to AI websites and AI providers. They are good at "someone in finance uses a chatbot". They see that a laptop called an AI provider's API, but not which tool made the call, whose key it used, or how freely the tool is allowed to act.

SSO and identity logs see sign-ins with company accounts. They miss personal accounts, which is where a large share of use happens: LayerX found 71.6% of access to generative AI tools ran through non-corporate accounts.

Surveys see what people know and choose to say. Most people know they use a chatbot. Far fewer know that the coding agent they installed started three MCP servers, or that a provider key sits in a settings file.

Try it on one machine#

You can see the gap for yourself in five minutes. On a Mac with a developer's tools installed, these are the default places to look. Paths move between versions, so treat this as a starting point, not a scanner.

# MCP servers and agent settings declared for this user
ls ~/.claude.json ~/.claude/settings.json ~/.cursor/mcp.json \
   ~/.codex/config.toml ~/.gemini/settings.json \
   ~/Library/Application\ Support/Claude/claude_desktop_config.json 2>/dev/null
 
# How freely Claude Code is allowed to act (look for defaultMode)
grep -h '"defaultMode"' ~/.claude/settings.json 2>/dev/null
 
# Local models
ollama list 2>/dev/null; ls ~/.lmstudio/models 2>/dev/null
 
# AI provider keys in .env files under your projects: names only, never values
grep -rhoE '^(ANTHROPIC|OPENAI|GEMINI|GOOGLE|MISTRAL|GROQ)_API_KEY' \
  --include='.env*' ~/code 2>/dev/null | sort | uniq -c

The checklist: find, understand, decide#

Run these per device, not per company. The answer differs from one developer's laptop to the next. They fall into three steps, and each step needs the one before it.

Find: what is on the machine#

1. AI apps and command-line tools. Desktop chat apps, AI code editors, and CLIs installed with one command. Include the ones nobody bought.
2. Coding agents, and how freely each one acts. For each agent, the permission mode it is set to and whether a session ever skipped the checks. This is autonomy, and it changes what everything below means.
3. Local models. Models downloaded to the disk and the tools that run them.
4. Skills, plugins and commands. What has been added to each agent, by name and origin. Agent skill marketplaces have already carried malicious skills, so origin matters.

Understand: what it reaches, whose it is, what it costs#

5. MCP servers, and what they can reach. Each declared server, its transport (local or remote), its host, and whether it can reach a shell, a credential or a business system.
6. Provider keys in files. Which AI provider keys exist in settings files and .env files, and whether git ignores them. Record that a key exists, never its value. See exposed keys.
7. Accounts: corporate or personal. For each AI tool, whether it is signed in with a company account, a personal account or one you cannot tell. This is where SSO-based discovery stops.
8. Usage and cost. The token usage the tools record locally, priced, and the seats nobody uses. An unknown tool is also an unknown line on a bill.
9. The projects agents work in, and AI website use. Which repositories an agent has been used in, and visits to known AI domains by category. An agent's reach is the reach of the folder it was opened in.

Decide: what you allow, and what happens when it changes#

10. A decision for every item. Each tool, server and key gets an owner and a verdict: sanctioned, blocked or undecided. An inventory nobody decides on is a list, not a control.
11. A rule for how freely agents may act. The permission modes you accept, written down, so a session that ran outside them is a finding, not a surprise.
12. An action for what is blocked, and a record of it. Removal, a guardrail on what leaves the device, or a kill switch, with the reason and the approver kept.

Keep it current#

Once is not enough. A new coding agent, MCP server or plugin is one install command away, and none of them goes through procurement. A list reviewed once a quarter is out of date for most of the quarter. The useful version reads each device on a schedule, grades what changed against the policy, and only then asks a person.

How EndLayer does it#

EndLayer is the Guardian Agent Platform, a product of Holistic AI. It runs the checklist above on every device, continuously, and turns each answer into a decision.

The Layer 1 Agent: on every device#

The Layer 1 Agent runs on each laptop or server without admin rights. It reads 21 signals from the files AI tools leave behind, every fifteen minutes, and never runs what it finds. Key values are discarded on the device before anything is sent.

Surface: find it#

Surface shows which AI tools, CLIs and coding agents are installed, and how far each agent is pre-approved to act. Twenty AI applications are recognised by name out of the box, and you can add to the catalogue in the console. Skills and commands are listed per agent host by name and origin, and each project gets a software bill of materials.

Monitor: explain it#

Monitor shows every declared MCP server with its transport and host, given a High, Medium, Low or Unknown risk tier from what it can reach. It lists provider keys by variable name and whether git ignores them, and whether each account is corporate, personal or unknown. It prices token usage from Claude Code, Codex, Cursor and OpenCode against a versioned rate table and, with an admin key connected, shows the billed cost and the seats nobody uses.

Govern: decide and act#

In Govern, each tool and server is graded against your policy. The permission modes you accept become a rule: a configured default or a session that ran outside them fails the check. Guardrails check prompts and agent tool calls on the device in Claude Code, Cursor and Codex CLI, and warn, redact or block secrets and personal data before they reach a provider. A blocked tool is uninstalled, or a blocked MCP server removed, once an administrator approves; a kill switch halts one tool or the whole fleet. Rules come grouped for the EU AI Act, ISO/IEC 42001, the NIST AI RMF, SOC 2 and GDPR, with evidence packs as the record.

Where it stops#

EndLayer sees only the devices it is installed on, so a personal laptop outside your fleet stays dark. It reads what is installed and configured, from files on the machine. It recognises AI applications by name, so a tool that is not in the catalogue yet has to be added before it is reported by name. And holding an agent's action for a person to approve before it runs is planned, not shipped.

A 30-day start#

1. Week 1: one group of devices. Install the agent on a pilot group, such as one engineering team, through your device management. Each device reports every fifteen minutes from then on.
2. Week 2: read the inventory. Compare Surface with what you thought was there. The gap is your shadow AI, by device and by person.
3. Week 3: write the first rules. Decide the tools you sanction, the permission modes you accept and the MCP servers you block. Leave the rest undecided, on purpose.
4. Week 4: act and widen. Turn on guardrails for secrets, approve the first removals, and roll the agent out to the rest of the fleet.

Sources#

• Bring-your-own AI: Microsoft and LinkedIn, 2024 Work Trend Index.
• Personal accounts: LayerX, Enterprise GenAI Data Security Report 2025.
• Unsanctioned agents and detection confidence: Cloud Security Alliance, 16 April 2026 (survey of 445 IT and security professionals, commissioned by Zenity).
• Malicious agent skills: Snyk, ToxicSkills.
• Local MCP servers: MCP in the wild, our study of the official MCP Registry, 23 October 2026.