Stop them at the credential, not the policy. A shadow AI agent can only act through access it borrowed: a person's login, a consent grant, a personal API key. Find those grants, revoke the ones nobody registered, require every agent to hold its own identity, and make the sanctioned route quicker than the workaround.
What counts as a shadow AI agent?
Any software that uses a model to take actions in your systems without being registered, scoped and owned. That is narrower than shadow AI in general, which includes staff pasting text into a chat tool. The agent version is more dangerous because it acts: it sends, updates, files or deletes.
Typical examples: a browser extension that sends replies from a staff member's mailbox, an automation workflow that calls a model and writes to the CRM, a laptop script using an analyst's database login. Most are built in good faith to clear a backlog.
Where do shadow agents hide, and how do you find them?
| Where it hides | How you find it | Typical action |
|---|---|---|
| Delegated consent grants to third-party apps | Review app consents in your identity provider | Revoke unknown grants; restrict who may consent |
| Personal API keys to a model provider | Expense claims, network egress to model endpoints | Block the endpoint; offer an approved route |
| Automation workflows built by staff | Inventory of the automation tool's flows and connectors | Register, migrate or switch off |
| Scripts using a person's credentials | Unusual activity patterns on named accounts | Move to a separate agent identity or stop |
| Vendor features switched on inside existing tools | Admin settings of each business system | Treat as a new agent and assess it |
The last row is easy to miss. A business tool you already own can ship an agent feature that acts on your data. Nobody built it in-house, but it is still an unregistered agent until someone owns it.
What are the steps to stop them?
- Security and IT: run discovery. Pull consent grants, service accounts, model-provider traffic and automation flows. Evidence: a dated discovery report.
- Process owners: triage each find. What does it read, what can it change, whose credentials does it use, and who built it? Evidence: one line per agent in the inventory.
- Risk: decide register, migrate or switch off. Anything acting on a person's credentials, or able to move money or delete records, is switched off first and rebuilt properly if the need is real. Evidence: the decision and its owner.
- IT: close the door. Restrict user consent to new apps, block unapproved model endpoints, and require every agent to have its own identity. Evidence: the configuration change record.
- Operations: publish a sanctioned route. A short form, a named reviewer, a turnaround time. Evidence: requests received and their outcomes.
- Security: repeat discovery quarterly. Shadow agents come back when the sanctioned route is slow. Evidence: the trend in new finds.
Why does a sanctioned route matter so much?
Because blocking alone moves the problem. The work is real; if the only answer is no, the next attempt will be harder to find.
A fast route can be modest: a team proposes a job, a reviewer checks it within days, and the agent runs in shadow mode, recording what it would do on real cases without acting. Note the name clash: shadow mode is a sanctioned test, not shadow AI. Our guide on running an AI agent in shadow mode shows how to set one up so a team sees results quickly and safely.
What does this look like in practice?
Take a mid-sized insurer's claims team. An adjuster has connected an automation tool to the shared claims mailbox with their own login. It reads incoming emails, calls a model to summarise them, and updates the claim notes. It works well and three colleagues now rely on it.
Discovery finds the consent grant. Triage shows it writes to claim records as one person, so every note looks as if the adjuster wrote it. Risk decides to migrate: the summaries are useful, but writes must come from a registered agent with its own identity and scope. The flow is switched off on a set date, and the replacement runs in shadow mode for two weeks before drafting notes at depth 2 for adjusters to confirm.
Which controls keep it from coming back?
- No agent acts on a person's credentials. This one rule removes most of the harm.
- Restricted app consent. Apps requesting write access need admin approval.
- An inventory with owners. Every agent has an owner, a scope and a review date.
- Routine discovery, run like an access review.
Where Pryme fits
Pryme gives every agent its own identity, a role scope and a certificate per agent, and files every verdict, so a registered agent is visible by design. That does not find the shadow ones for you; discovery is still your job. It does make the sanctioned route short: describe the job in Agent Studio, test it on your own cases, and start it at a low depth. See our guide to agent governance for the full model.
Questions people ask
Should we discipline staff who built shadow agents?
Usually not. Most were solving a real problem. Treat the first discovery as an amnesty, then make clear that agents acting on personal credentials are not allowed from here on.
Can we detect shadow agents from network traffic alone?
Partly. Traffic shows usage, not actions. Consent grants and account activity show what was done.
Is a personal chat assistant a shadow agent?
Not if it only answers questions and takes no action in your systems. It still raises data questions, but it is shadow AI, not a shadow agent.