An unsanctioned agent can only do harm through the access it holds: a token, a login, an API key, a connected mailbox. That is where to find it and where to stop it. Model usage policies tell people what not to do; identity and access controls show you which agents exist and decide what each one can touch.
Why does shadow AI look different once agents act?
Shadow AI used to mean staff pasting text into a public chatbot. The risk was data leaving the organisation: a contract, a customer list, a piece of code. Our explainer on what shadow AI is covers that original form. The controls were mostly about data loss: block certain sites, train staff, write an acceptable use policy.
Agents change the shape of the risk. A shadow agent does not just receive data; it acts. Someone in finance connects an agent to their mailbox to triage supplier invoices. A salesperson gives an agent access to the CRM to update records after calls. An analyst wires an agent to a shared drive to file documents. Each of these was set up with good intentions, using the person's own credentials or a token they generated, and none went through any approval.
What matters now is not mainly what data the agent saw. It is what the agent can change, send or delete, and under whose name.
Why do model policies fail to stop shadow agents?
Because they target the wrong layer. A policy that says "only approved AI models may be used" assumes you can see which model is in use. Agents built by staff often call models through personal accounts, browser extensions or tools that bundle a model invisibly. You will not find them by inspecting model traffic, and banning a provider just moves the agent to another.
Policies also rely on people knowing what counts as an agent. Many staff do not think of a mailbox rule driven by an AI assistant, or a spreadsheet plugin that writes to a ledger, as an agent. They will not declare what they do not recognise.
Access, by contrast, is always visible somewhere. Every agent that touches a business system has to authenticate. That leaves a trace: an OAuth grant, an API token, a service account, an unusual pattern of sign-ins from a user's account. Those traces exist whether or not anyone declared the agent.
Where do shadow agents show up in your access data?
Look in places identity and security teams already monitor.
| Where to look | What a shadow agent looks like |
|---|---|
| Third-party app grants | A user granted an unfamiliar application read and write access to mail, files or calendar |
| API tokens and keys | Personal tokens with broad scopes, newly created, used at machine speed |
| Sign-in patterns | A user account active at all hours, from a cloud address, with no interactive sessions |
| Service accounts | Accounts with no named owner, or owned by someone who has left |
| Connected system logs | Bursts of record changes too regular or too fast to be a person |
None of these needs AI-specific tooling. They need the access review discipline most organisations already apply to people and service accounts, extended to cover agents. Our AI agent access review checklist lists the checks.
How do you bring shadow agents under control?
Not by banning them outright. People built them because they needed the work done, and a ban usually drives the next one further out of sight. The approach that works treats each discovered agent as an access request that was never made.
First, find them, using the access signals above. Second, contact the owner and record what the agent does, what it can reach and whose credentials it uses. Third, revoke any access that runs through a person's own account, because an agent acting as a person destroys the record of who did what. Fourth, if the work is worth doing, give the agent its own identity, grant it only the capabilities it needs at a depth that matches the evidence, and bring it under the same checks as any sanctioned agent. If the work is not worth that effort, retire it.
Our guide on how to stop shadow AI agents covers the policy side of this; the point here is that the starting tool is the access inventory, not the model register.
Why should agents never run on a person's credentials?
Because it merges two identities that need to stay separate. When an agent acts with a person's login, every action it takes is recorded as that person's. If it sends the wrong email, pays the wrong supplier or deletes the wrong file, the record shows the person did it. You cannot tell their actions from the agent's, and you cannot remove the agent's access without removing theirs.
It also means the agent holds every permission the person holds. A finance manager's account may be able to approve payments, change bank details and access payroll. An agent built to triage invoices does not need any of that, but if it runs on the manager's credentials, it has it all. This is the single most important thing to close.
How often should you look for shadow agents?
Continuously for the strongest signals, such as new third-party grants with write access to mail or files, and on a set cycle for the rest. A quarterly access review covering agents, alongside the review of people and service accounts, is a reasonable baseline. Our playbook on running an access review for AI agents describes a workable cycle.
What is the trade-off?
Treating shadow agents as an access problem means more work for identity and security teams, who may not see AI as their remit. It also means difficult conversations with staff whose useful tools are about to be switched off or rebuilt.
The alternative is a growing estate of agents acting under people's names, with broad access, no bounds and no record of their own. That is not an AI problem you can solve with a model policy. It is an access problem, and it has an owner who already knows how to solve it. Start this week by pulling every third-party application grant with write access to mail, files or core systems, and ask who owns each one. The governance structure that should receive what you find is set out in our guide to agent governance as a bound, not a model.
Where Pryme fits
Agents in Pryme each have their own identity, separate from any person, and hold named capabilities at a set depth rather than a person's full access. Every action passes the same bounds and is filed under the agent's identity. A shadow agent brought into Pryme gets the same treatment: its own identity, its own grants and certification before it acts.
Questions people ask
Who should own shadow AI discovery: security, IT or risk?
Identity and security teams should run discovery because they own the access data. Risk should own the decision about what to do with each agent found, and the business owner should decide whether the work is worth bringing into the sanctioned estate.
Should staff be disciplined for building shadow agents?
Usually not for a first instance, especially if they come forward. Most shadow agents exist because a real need was unmet. Treat discovery as a way to learn where sanctioned tools fall short, while making clear that agents running on personal credentials will be shut off.
Can shadow agents be detected by blocking AI provider websites?
Only partly. Agents often reach models through tools, plugins or personal devices that bypass network blocks. The traces they leave in your business systems, where they actually act, are far more reliable than traffic to a provider.