Shadow AI is the new shadow IT, and it did not raise a change request.
In both of my recent posts (SASE should not be a side order and Anyone can deploy SASE. The hard part comes next) I mentioned, almost in passing, the AI tool that appears in the estate without anyone asking permission. Several people picked up on that line, so it deserves a proper answer.
Here is the situation as I see it in real environments, not in vendor slideware. Somewhere in your business right now, someone is pasting content into an AI tool that nobody in security has assessed. Not maliciously. They are trying to hit a deadline, the tool is genuinely useful, and it took thirty seconds to sign up with a corporate email address. Multiply that by every team member under pressure and you have meaningful data movement to services you have never heard of, on terms nobody has read.
We have been here before. This is shadow IT again, except faster and with a sharper edge. When teams quietly expensing a SaaS subscription, the risk was duplication, cost and an unmanaged account. With AI, the thing leaving the building is the content itself. Source code, customer records, commercial terms, the draft board paper. Pasted, uploaded, summarised, and in some cases retained by the service under a consumer licence agreement that nobody in your organisation ever accepted on the company's behalf.
And it is no longer just the standalone tools. The SaaS industry is under pressure of its own. When businesses can vibe-code a passable internal tool in an afternoon, every vendor is asking how to stay indispensable, and the answer they have all landed on is embedding AI into the product. Whether that is done to protect the licence or to genuinely add value, the result for you is the same. The platforms you sanctioned two years ago now ship with AI assistants baked in, quietly processing whatever your users put in front of them. Call it what it is: supply chain AI. You assessed the SaaS. Nobody assessed what is now running inside it.
The uncomfortable truth, is that you cannot block your way out of this one.
Why "just block it" fails
The instinctive response is a deny rule. It fails for three reasons.
- The list never stops moving. New AI tools appear weekly, existing SaaS platforms are embedding AI features into products you have already approved, and the category boundary is dissolving. The productivity suite you sanctioned two years ago now has generative features in it. Blocking "AI" as a category is blocking a moving target with a snapshot.
- Your business actually needs some of it. The productivity gains are real, and the teams using these tools are often your best people. A blanket block does not stop the behaviour. It moves it to personal devices and home networks, where you have no visibility at all. You will have traded a risk you could see for one you cannot.
- Blocking is a decision, and nobody is making it. A deny rule written once and never revisited is not a policy. It is a fossil. Within months it will be blocking something the business has legitimately adopted and missing something it should not, and both failures will be invisible until they hurt.
So the answer is not a wall. It is visibility, classification and a decision-making rhythm. Which is where your SASE platform comes in, because it turns out you may already own the right tool for this and be using a fraction of it.
The enforcement point you already have
If your users are working through a SASE platform, their traffic to AI services is already passing through a point where you can see it, classify it and apply policy to it. The capability is largely there.
- The starting point is simply knowing what is in the traffic. Which AI services are being used, by whom, how often, and what categories of data are moving towards them. Most organisations who run this discovery for the first time are surprised, and not pleasantly.
- Not all AI tools are equal. There is a meaningful difference between an enterprise-licensed service with contractual data protections and a free consumer tool that trains on your inputs. A CASB policy can distinguish the sanctioned instance from the unsanctioned one of the same product, which is exactly the distinction that matters here.
- The real risk is not the destination. It is what travels there. Data loss prevention tuned to your actual sensitive data, source code, customer identifiers, financial content, can allow the tool while stopping the paste. This is also, as I said in the side order piece, the layer that demands an understanding of your data as much as the product. A template will not know what your crown jewels look like.
- The mature position is not prohibition. It is a tiered policy: these services are approved for general use, these are approved with DLP guardrails, these are blocked with a message that points people at the sanctioned alternative. That last part matters more than it sounds. A block page that says no teaches people to route around you. One that says use this instead makes security the easy path.
Visibility first
CASB to tell services apart
DLP to protect the content
Policy that says yes, safely
None of this is exotic. It is CASB, DLP and URL filtering, capabilities that most SASE customers are already paying for. The gap is rarely the licence. It is that nobody is operating it.
Which brings me back to the operating model
A shadow AI policy written this quarter will be wrong within two, because the tools will have changed, the business will have adopted something new, and the vendor will have shipped AI detection capabilities you are paying for and not using. This is precisely the class of problem that a deploy-and-leave engagement cannot touch and a continuous operating rhythm handles as routine.
In our world it looks like this. The maturity cycle picks up new AI service categories in the coverage review. The quarterly optimisation report puts the discovery data in front of you, with a recommendation and a risk rating, reviewed in person with real conversation. The policy tuning cadence turns "we should probably look at that" into a change request with an owner. And because our people work across a lot of industries and environments, the pattern you are seeing has usually already been worked through with three other customers in your sector, which means you get an answer rather than a workshop.
A portal will not do this for you. A dashboard can show you the traffic. It cannot tell you which of those forty AI services your legal team would accept, or sit with your CISO and argue constructively about where the line should be. That takes people who know your environment and turn up.
The question to ask this quarter
If you take one thing from this post, make it this. Ask whoever operates your SASE platform, whether that is an internal team or a partner, one question: which AI services did our users access last month, and what data went to them?
If the answer comes back specific, you are in good shape, and the follow-up conversation about policy will be a productive one. If the answer is a pause, or a portal login, or a promise to investigate, then you have learned something important. Not about AI, but about how your platform is being operated, and about the gap between what you bought and what you are getting.
Your users are not waiting for your policy. The traffic is already flowing. The only question is whether anyone on your side is looking.
If you want the discovery run against your own environment, that is a short piece of work with your existing platform, and the results tend to start a very good conversation.
The SASE Advantage
If you’re scoping a SASE design, mid-way through an evaluation, or reassessing a deployment that has underdelivered, The SASE Advantage whitepaper sets out exactly how a certified, managed approach to Prisma Access is architected, sequenced, and operated. It’s a practical guide to what good looks like, written for the people who have to make the decision and live with it.
