Shadow AI agents are the AI coding agents your developers already run on company machines that nobody in security knows about. Not shadow IT in the old sense, a SaaS tool signed up for with a corporate card, but programs that act with the developer's full access: they read credentials, run commands, install MCP servers and skills, and reach the network, with no entry in any asset register. This article is for the CISO or security architect who suspects the count is higher than the two agents the company officially adopted, and wants the real number by the end of the day.
Why is the count always higher than you think?
Because nothing in the way agents arrive involves the security team. A developer installs Claude Code with one command. Cursor is a download. Codex CLI, Gemini CLI, Windsurf and Copilot each come from a different vendor with a different installer, and Claude Desktop is a separate program from Claude Code. Each one is configured in files in the developer's home directory, and each one keeps working after the trial the company evaluated has ended.
Then the agents themselves add to the estate. An MCP server is one line in a config file, and a skill is a folder copied into place. On the machines we scan, a typical developer laptop runs between five and fifteen MCP servers, and the company that believed it had standardised on one agent finds it has eight or nine in use. Every one of those is a program with the developer's identity, and every one is an entry that should be in the inventory and is not.
The incidents of the last year were all shadow estate incidents. Two AI coding extensions with 1.5 million installs quietly sent developers' source files to a remote server. More than a thousand malicious skills were uploaded to an agent marketplace and installed by people who thought they were adding a utility. Nobody in those companies had a list, so nobody could answer the first question an incident asks: are we affected, and where?
What does a shadow AI agent actually have access to?
Whatever the developer has. That is the whole problem in a sentence, but it is worth being specific, because the specifics are what a board understands.
- Credentials. The .env file in every cloned project, the cloud CLI profiles, SSH keys, the keychain, and personal access tokens for GitHub, npm and the package registries. One real laptop we scanned held forty-six credentials its agents could read. Nothing was misplaced; that is what a working machine looks like.
- Source. Every repository the developer has cloned, which for a senior engineer is most of the company's code.
- Standing permissions. An agent asks before running a command until the developer tells it to stop asking. Many have. "Run any command", "push to git", "write anywhere" are permissions that exist on real machines today, and they mean an agent with no person in the loop.
- The network. Internal systems, staging, production consoles, anything the credentials above open.
- Text. Every file it opens and every tool result it reads is text the model treats as information and sometimes as instructions, which is how a prompt injection on a laptop turns any of the above into a loss.
Shadow AI agents are not a licensing or a policy problem. They are an unknown set of programs holding the keys to the company, and the first control is knowing they exist.
Why can the tools you already have not see them?
Every existing control was built for a different shape of problem.
EDR looks for malware. An AI agent is a trusted, signed binary from a known vendor doing what it was built to do. There is no signature to match and nothing about the process is anomalous.
A network proxy or CASB sees traffic to a model provider, so it can tell you that a machine talks to Anthropic or OpenAI. It cannot tell you which agent, what it can reach, which MCP servers it loads, or which permissions it holds. And it sees nothing when the agent's action is local: reading a credential file, running a command, writing a hook.
Software asset management counts installed applications. Most agents are not installed in the sense SAM understands. They are npm packages, single binaries in a user directory, or extensions inside an editor, and their MCP servers and skills are config lines and folders.
A survey is out of date the day it closes, because the estate changes daily and nobody fills in a form when they add an MCP server.
The one place that has the full picture is the endpoint, because that is where every agent writes its own configuration down.
How do you find every shadow AI agent in fifteen minutes?
Read what the agents wrote. Each one keeps its settings in known files: the allow rules and hooks in a settings file, the MCP servers in a config file, the skills in a folder, the extensions in the editor's directory. A sensor on the machine reads those files and reports names, versions and hashes to a console. Nothing for developers to register, nothing for them to notice, and no credential values or file contents ever leave the machine.
Fifteen minutes after the sensor is installed the console answers the questions in order:
- Which agents run on which machines. By name and version, with the person the machine belongs to. The company that thought it ran two finds the real number here.
- What each agent loads. Every MCP server, skill, extension and package, matched against advisories and read by an AI reviewer for hidden instructions. MCP server security covers why this list matters.
- What each agent can reach. The credentials it can read by name, the systems those open, and the standing permissions it holds. This is the reach a CISO needs to know before deciding anything.
- What is wrong. Readable production credentials, unreviewed servers, forbidden permissions, agents signed in as people who have left. Grouped by cause with the fix beside each, so it is a queue rather than a list.
That is discovery. It is the first half of AI agent governance; the second half is deciding what the agents may do and enforcing it on the same endpoint.
What does the count usually look like?
Every estate is different, but the shape repeats. The company adopted one or two agents officially. The inventory finds three to four times that many in use, because developers try what their peers use and nobody uninstalls. The MCP server count is a multiple of the agent count. A handful of agents hold a standing permission the security team would never have approved, granted during a session six months ago and never revisited. And somewhere there is an endpoint whose owner left the company, still reporting, its agent still signed in.
None of this is a scandal. It is what happens when a class of software arrives faster than the process for managing it, which is every class of software. The difference with agents is what they can reach, and the fix is the same as it was for laptops and cloud accounts: get the list, then govern from the list.
What should a CISO do first?
Not write a policy. Get the picture.
- Put the sensor on the machines. Fifteen minutes later you have the list, the reach and the first findings.
- Take the surprises to the people who own them: the agent nobody approved, the credential every agent can read, the permission that should not exist. Most are fixed in a conversation.
- Hold new MCP servers and skills for review from now on, so the estate stops growing behind your back.
- Decide the rules, which agents, what reach, what they may do without asking, and enforce them on the endpoint. The platform does discovery and enforcement from the same sensor.
- Map what you found to the frameworks you already owe. Every one of them, EU AI Act to SOC 2, starts with an inventory, and now you have one.
Shadow AI agents stop being shadow the moment they are on a list. That takes fifteen minutes, and it is the fifteen minutes the rest of AI agent security depends on.
Frequently asked questions
What are shadow AI agents? AI coding agents such as Claude Code, Cursor or Codex CLI that developers installed and run on company machines without the security team knowing. They act with the developer’s full access, read credentials, install MCP servers and skills, and reach the network, and none of it is in the asset register.
How do you find shadow AI agents on developer machines? Read the agents’ own configuration on each endpoint. Every agent writes its settings, permissions, MCP servers and hooks to known files in the home directory and the project. A sensor that reads those files reports the full list within fifteen minutes, with nothing for developers to register.
Can a network proxy or CASB find AI coding agents? Only partly. A proxy sees traffic to a model provider, so it can tell you that some agent exists on a machine. It cannot see which agent, what it can reach, which MCP servers it loads, or which standing permissions it holds. The picture the CISO needs lives on the endpoint.
Should shadow AI agents be blocked? No. Developers are more productive with them and a ban drives the use onto unmanaged machines. The goal is a known list: every agent inventoried, each one’s reach and permissions visible, and rules enforced on the endpoint for what they may do.