Shadow AI: the risk you already have

What is shadow AI?

Shadow AI is the use of AI tools inside an organisation without approval, oversight or security review — the AI-era equivalent of shadow IT. It is the most common finding in a first AI security assessment, and it is almost always larger than the organisation expects: not two or three tools, but dozens.

What makes it different from classic shadow IT is the payload. An unsanctioned project-management tool holds project data. An unsanctioned AI assistant holds whatever an employee found it useful to paste — a customer list, a contract, a patient record, unreleased financials, the source code of the thing you sell. The exposure is not defined by the tool’s purpose. It is defined by whatever was most inconvenient to summarise by hand that afternoon.

The question is never “should we allow AI?” It is “which forty tools are already in use, by whom, and with what data?”

Robin Johns, Worldwide AI SME, Cato Networks

Why does shadow AI happen?

Because the sanctioned path is slower than the unsanctioned one. Employees are not being reckless; they are being effective. When approval takes six weeks and a free tool takes six seconds, the six-second option wins — and every additional layer of friction on the approved route widens the gap.

Three forces make AI a much sharper version of this problem than shadow IT ever was:

• Zero procurement friction. No install, no licence, no card. A browser tab is the entire adoption process.
• Genuine, immediate productivity. The tools work. People are not experimenting — they are getting their jobs done faster, which makes the behaviour extremely durable.
• Invisible data movement. Pasting text into a text box does not feel like exporting data, so it does not trigger the instinct that a file upload would.

Why doesn’t blocking work?

Because blocking removes your visibility, not the behaviour. When the corporate network blocks an AI tool, usage moves to a personal phone, a home laptop or a personal account — where there is no DLP, no logging, no policy and no way to know it happened. You have converted a visible risk into an invisible one and called it a control.

The blocked-tool failure mode is worth spelling out, because it is so often mistaken for success:

1. Security blocks the AI domains. The dashboard shows blocked requests trending to zero.
2. Employees who still have the same deadline switch to a personal device.
3. Corporate data now reaches the same AI service, from an unmanaged endpoint, under a personal account, with no record.
4. Security reports that shadow AI has been eliminated.

Nothing about the data exposure improved. The only thing that changed is that you can no longer see it. Worse, you have taught people that security is an obstacle to route around — which is expensive the next time you need them to report something.

How do you discover shadow AI?

Start on the network, not with a survey. Because AI usage is almost entirely traffic to cloud services, cloud application visibility on egress traffic will reveal the real picture in days. Surveys under-report by a wide margin — people do not volunteer behaviour they suspect is against the rules.

• Cloud application discovery on outbound traffic, via CASB or a SASE platform, across every user and location rather than only the corporate LAN.
• Categorise by risk, not by brand. What matters is where data goes, whether the provider trains on it, and whether an enterprise agreement exists — not whether the logo is familiar.
• Attribute usage to identity and department. “Marketing is using six tools” is actionable; “we saw 40,000 requests” is not.
• Sample the data, not just the destination. Volume tells you adoption; content inspection tells you exposure, and those two rankings are rarely the same.
• Inventory the internal projects too. Shadow AI is not only SaaS — it is also the team that quietly stood up a RAG pipeline over the shared drive.

The steer-don’t-block playbook

Give people a good sanctioned tool, make it the path of least resistance, apply data controls at the point of use, and reserve blocking for genuinely hostile services. The objective is not zero AI usage. It is zero invisible AI usage.

Two details decide whether this works. First, the sanctioned tool has to be genuinely good — a worse assistant behind a login page loses to a better one in a private tab, every time. Second, the coaching message has to name the alternative. “This is blocked” produces a workaround; “use the approved assistant, it handles this and keeps the data internal” produces a migration.

Most of the enforcement here lands on the network and identity layer, which is why a converged SASE platform tends to be where it gets implemented: one policy engine covering discovery, per-user access decisions, inline DLP on prompts and uploads, and a single log.

How do you know it is working?

Measure migration, not suppression. The metrics that indicate a healthy programme are the share of AI traffic going to sanctioned tools, the number of distinct unsanctioned tools in use, DLP events prevented at the point of paste, and time-to-approval for a new tool request.

• Sanctioned share of AI traffic — should climb steadily. This is the headline number.
• Distinct unsanctioned tools in use — should fall, then plateau at a small tail.
• Sensitive-data events blocked at the prompt — proves the control is live and calibrated.
• Time to approve a new tool — the leading indicator. If this rises, shadow AI will rise behind it.

A dashboard showing blocked requests falling to zero is not evidence of success. It is usually evidence that you have stopped being able to see.

Frequently asked questions