What is a shadow agent?
Shadow agents appear when a developer connects a coding agent to CI, an employee grants an AI tool access to a mailbox, or a team tries an experimental MCP server and never removes it. They are not malicious by definition. The problem is that nobody decided what they should reach.
claude-codeDeveloper laptop · found via MCP configSanctioned
cursor-agentDeveloper laptop · no ownerShadow
ai-review stepCI workflow · uses DEPLOY_TOKENShadowA shadow agent is an AI agent running in an organisation with real access, but without being registered, reviewed or owned by anyone responsible for it.
Where shadow agents come from. Five common doors.
None of these needs an attacker. Each one gives an agent credentials that nobody reviewed.
Cursor, Claude Code or Codex installed by a developer. They run with the developer’s shell, git credentials and cloud profiles.
An employee clicks Allow and a notetaker or assistant gets mail, drive or CRM scopes. No ticket, no review, no expiry.
A server added to a local MCP config, usually with a long-lived token in its env block.
A workflow step that calls an AI CLI with repository secrets, often added in a pull request nobody read closely.
A LangChain or notebook agent that reuses an existing API key, service account or cloud role.
Same agent. Different accountability.
The software can be identical. What makes an agent sanctioned is everything around it.
| Shadow agent | Sanctioned agent | |
|---|---|---|
| Inventory | Not registered anywhere | Listed with type, source and owner |
| Owner | Nobody, or the person who installed it | A named team that answers for it |
| Credential | Personal token, shared key or the developer’s own session | Dedicated identity, scoped to the task |
| Access review | Never reviewed | Reviewed when access changes |
| Reach | Whatever the credential can reach | Known paths, risky ones closed |
| Offboarding | Survives when the installer leaves | Removed or reassigned with its owner |
How to find shadow agents. Follow the credentials.
ai-notetakerdana.reyes · gmail.readonly, driveNewslide-generator3 users · drive.fileNew{
"mcpServers": {
"crm": {
"command": "npx",
"args": ["-y", "crm-mcp-server"],
"env": {
"CRM_API_TOKEN": "sk_live_••••••••••"
}
}
}
}- name: AI review run: npx ai-review-cli --fix --all env: MODEL_API_KEY: ${{ secrets.MODEL_API_KEY }} GITHUB_TOKEN: ${{ secrets.DEPLOY_TOKEN }} # deploy token: repo write + packages
Why a shadow agent is an attack path
A shadow agent holds real credentials but sits outside every review. Whoever controls it, through prompt injection, a malicious repository or a stolen token, inherits everything those credentials can reach. That chain is an attack path, and because nobody registered the agent, nobody is watching the first step.
This is why reach matters more than the count. Ten shadow agents with read access to a wiki are a hygiene issue. One with a path to production data is an incident waiting for a trigger.
cursor-agentFound one. Now what?
Finding shadow agents is the first step. Assigning an owner is the second. Neither makes the agent sanctioned by itself: its access still needs a review.
Questions, answered.
Short answers on shadow agents and how to handle them.
Is a shadow agent the same as shadow IT?
It is a special case. Shadow IT is any tool used without approval. A shadow agent also acts on its own: it reads data, calls APIs and runs commands with the credentials it was given, so the risk is what it can reach, not only that it exists.
Are shadow agents malicious?
Usually not. Most are installed by employees to get work done. They become a problem because their access was never reviewed, and anyone who controls the agent, for example through prompt injection or a stolen token, inherits that access.
How do I find shadow AI agents?
Look where agents leave traces: OAuth consent logs in Google Workspace and Microsoft Entra ID, MCP configuration files on developer machines, CI workflows that call AI tools with secrets, and cloud or model provider API keys used by new clients.
What should I do when I find one?
Assign an owner, review what the agent can reach, then either move it to a dedicated, scoped identity or remove it. Finding it and assigning an owner does not make it sanctioned by itself.
Related terms.
Shadow agents are one piece of the attack path picture.
See what your agents can reach. Before someone else does.
Book a demo and we walk through the access paths in an environment like yours.