Shadow AI is any AI tool, model, or agent being used for work without the approval or the knowledge of the people responsible for security and IT. It is shadow IT with a new failure mode. Shadow SaaS put company data somewhere nobody had reviewed. Shadow AI does that too, and then it acts: it calls APIs, writes to databases, opens pull requests, and sends messages, all with credentials the employee already has.
That second part is what makes it a different problem rather than a bigger one.
What it actually looks like
The chatbot case is the one everyone pictures first. Someone pastes a customer list into a consumer model to reformat it into a table. That happens constantly, and it is the least interesting version.
The versions that matter more look like this. An engineer runs a coding agent on her laptop with a personal API key. The agent has her filesystem access, her git access, and an MCP server pointed at a production read replica, because the connection string was already sitting in her .env.
Or: a team installs an MCP server through a one-click config in their editor. That config is a shell command, and a client that supports one-click local server setup executes whatever the config contains. The MCP specification's own security guidance uses this as its example of the risk, with a startup command that runs a package and then curls ~/.ssh/id_rsa to a remote host.
Or: someone wires an agent into a nightly job to triage support tickets. As part of triage it fetches a linked web page. The page contains text addressed to the agent. The agent follows it, because the fetched content and the operator's instructions arrive in the same context window with no boundary between them. OWASP files the general shape of this under excessive agency: an agent given more functionality, more permissions, and more autonomy than the task requires.
Or, least technical and probably most common: someone in marketing builds an automation in a no-code tool that pipes CRM records through a model API on a personal $20 plan. There is no procurement record because there was no procurement.
Why it is harder to find than shadow SaaS
The discovery techniques that worked for shadow SaaS all depended on a new vendor relationship existing somewhere. A new domain in DNS logs. A new line in an expense report. A new OAuth grant in the Google Workspace admin console. Every one of those assumes the tool is a distinct thing an employee signed up for.
Agent traffic often has none of that. A local MCP server on the stdio transport never touches the network; it is a subprocess exchanging JSON-RPC over stdin and stdout. An agent calling your internal API with the employee's token looks exactly like the employee calling your internal API, because as far as your systems are concerned it is. The model call itself may go to a provider you already have a contract with, so the domain is already allowlisted. And the credentials for all of it live in dotfiles and editor configs rather than in your identity provider.
You can find some of it. Endpoint tooling sees processes. Egress logs catch calls to model providers. But an engineer with a laptop and an API key is not discoverable through network telemetry alone, and assuming otherwise produces a confident inventory that is wrong, which is worse than no inventory.
The two failure modes
Data leaving is the familiar one. Someone puts something into a model that should not have left the building. It is a real risk and roughly the same risk as pasting into a personal Gmail draft, which security teams have decades of practice reasoning about.
Actions happening is the newer one, and it is the harder one. The blast radius of an agent is set by whatever credential it picked up, and that credential was almost never scoped with an agent in mind. The database user has write access because it is the same user the application uses. The GitHub token can push because it was minted for CI. Nobody chose those permissions for an autonomous process; they were inherited.
The part that tends to get missed: if you are not logging tool calls, you have no record that an agent was involved at all. A row updated at 3am by the application's database user is indistinguishable, in your audit trail, from the application updating it. You lose not just prevention but the ability to reconstruct what happened afterward.
Why blocking does not work
The reflex is to block model provider domains at the firewall. That fails for the same reason blocking Dropbox failed, and then it fails worse.
It fails the first way because the productivity gain is real enough that people route around it. Personal laptop, phone tether, personal account. An employee who routes around a block moves from somewhere you had partial visibility to somewhere you have none.
It fails the second way because the interesting agents are not at a provider domain you can enumerate. They are the internal tools your own engineers built, the MCP servers running on localhost, and the agents embedded in software you already bought and approved. There is no domain to block.
What visibility actually requires
Start by asking. A short, no-consequences survey about what people are using will get you a more accurate inventory in a week than network analysis will in a quarter, as long as answering it truly does not get anyone's tool confiscated. That condition is the whole trick.
Then give agents their own identity. An agent running under a human's OAuth token is unattributable by construction, and no amount of downstream logging fixes that. A separate service identity with its own credentials and its own scopes is what makes every later control possible.
Then log tool calls, not just prompts. Prompt logs tell you what somebody asked for. Tool call logs tell you what happened. The record worth having is the tool name, the arguments, the upstream system, the identity that made the call, and what came back. That is the artifact you will actually want during an incident, and it is the one almost nobody has.
Then scope at the tool level. Point the agent at a read replica instead of the primary. Do not expose a delete tool and hope it goes unused; do not expose it. This is unglamorous and it is most of the value.
Eliminating shadow AI is not a reachable target. Employees are adopting these tools considerably faster than any review process can keep up with, and that gap is not closing. The reachable target is a sanctioned path good enough that the shadow path is not worth the trouble, plus enough logging to reconstruct what happened on the parts you did not catch.