237K+ AI events recorded on our own fleet · last 30 days AI events on our own fleet · 30d
All articlesSecurity

Shadow AI is a visibility problem, not a discipline problem

Developers reach for unsanctioned AI tools because they work. Policies that ignore that drive usage out of sight. Start by seeing what is already happening.

Every security team knows the pattern. A policy says which AI tools are approved. A developer finds a faster one, installs it, and gets on with the job. Nobody files a ticket, and nobody is being malicious. The tool simply works, and the approved path is slower.

That is shadow AI: AI tools in daily use that security never approved and cannot see. It is easy to treat as a discipline problem, solved with reminders and stricter rules. In practice that rarely works, because the incentive that created it, getting work done faster, has not gone away.

Why stricter rules make it worse

When the response to unsanctioned tools is a tighter ban, usage does not stop. It moves somewhere harder to see: personal accounts, personal machines, browser tabs outside the corporate network. The organisation ends up with the same exposure and less information about it.

The real risk is not that a developer used an AI tool. It is what the tool could touch while they did:

  • source code and internal repositories
  • credentials, keys and environment files
  • customer data in logs, tickets and test fixtures

Start with an honest inventory

Before deciding what to allow or restrict, find out what is actually in use. Which AI coding tools and agents are installed on developer machines? Which actions do they take: reading files, running commands, sending content to external services? Who uses them, and for what kind of work?

You cannot govern a tool you cannot see. Visibility comes first.

An inventory like this usually brings good news as well as bad. Most usage is ordinary and productive. A small number of actions carry real risk, and those are the ones worth writing rules for.

Turn findings into a sanctioned path

Once you can see the landscape, the goal is to make the approved path the easiest one:

  1. Approve the tools people already rely on wherever the risk is acceptable.
  2. Write narrow rules for the actions that genuinely matter, like reading private keys or sending customer data to an unapproved service.
  3. When a rule applies, explain it in the moment and point to the alternative.

Handled this way, shadow AI shrinks on its own. People stop working around a system that works with them.

If you want a quick read on where your organisation stands, take the Shadow AI self-assessment.

See what your AI tools are doing. Keep your business in control.

Let’s talk