Shadow AI: why banning it does not work

The bottom line: shadow AI is not a technical problem, it is everyday behavior no ban can switch off

Shadow AI is the use of artificial intelligence tools (a public chatbot, a copilot, a text or code generator) by employees without the approval or knowledge of the security team. It is not an attack or a system failure: it is a person pasting a draft contract, a snippet of code or a customer sheet into a tool open in another tab, because it solves their day.

That is why banning it does not remove it, it hides it. The risk does not live in the tool but in the person's decision about what information they hand over and under what pressure, and that decision gets made dozens of times a week in any company. Anyone who wants to control it has to look at behavior, not just write a policy no one reads. The rest of this piece develops that idea: what shadow AI actually is, how it differs from the risk of an AI agent, why bans fail, and what to observe in behavior to reduce risk without slowing people down.

What shadow AI is and why it exploded in a single year

We call shadow AI the unauthorized use of AI tools for work tasks. The term inherits the logic of the old shadow IT, those apps teams adopted on their own without going through the technology department, but with a difference that changes everything: the barrier to entry is zero. Nothing needs to be installed and no budget needs to be requested. All it takes is opening a browser, typing a question and pasting in whatever you are working on.

The jump over the past year was not gradual. Frequent use of AI assistants among employees went from being a thing for a curious few to a widespread habit in a matter of months, driven by free tools, by copilots that arrived built into suites the company already pays for, and by the pressure to produce faster. Adoption ran ahead of any policy. By the time the security team sat down to write the rules, half the office had already been using these tools every day for months.

That gap is the point. Shadow AI did not appear out of carelessness or bad intent: it appeared because the tool is useful, it is one click away, and no one explicitly said no. Treating it as an anomaly to be stamped out misreads the phenomenon. It is everyday behavior, and everyday behavior does not switch off with a memo.

How it differs from the risk of an AI agent with its own identity and permissions

It is worth separating two things that often get confused. Shadow AI is a person using an AI tool without permission. An AI agent is a program that acts on its own, with its own identity, its own credentials and permissions to read data, run tasks or connect to other systems. The first risk is about human conduct; the second is about governing the identities and access of machines.

The distinction matters because the control is different in each case. An AI agent is governed like any privileged identity: you limit its scope, audit its actions, revoke it when it is no longer needed. That is a real and growing problem, and we address it separately in our piece on AI agent risk and human risk. Shadow AI, by contrast, is not governed with machine permissions, because the one deciding what information to hand over is a person acting within their legitimate access. There is no privilege to revoke: there is a habit to understand.

Blending the two problems leads to solutions that do not apply. Putting identity controls on agents does not change what an employee pastes into a chatbot from their personal account, and training the person does not govern an autonomous agent. This piece deals with the first case, the one about conduct.

Why banning the tool pushes its use underground

Banning has an obvious appeal: it is quick to announce and gives the sense that the problem is closed. But it collides with the reality of work. The tool saves the person hours, and that gain does not vanish because a policy says no. What vanishes is visibility. Use continues, now from the phone, from a personal account or off the company network, exactly where the security team can no longer see anything.

Cisco's 90-5-5 framework, which estimates that around 90 percent of breaches involve a human factor, helps explain why a ban fails as a control. That same framework splits the remaining 5 and 5 between missing or misconfigured tools and limited resources such as time or staffing. A ban is exactly that, a governance tool, and one that is misconfigured for the problem: it does not change conduct, it only makes it invisible. It rests on the hope that people will stop doing something that works for them, instead of giving them a safe alternative and watching how they behave.

There is a silent cost to that blindness. When use goes underground, the company loses the ability to know what kind of information is leaving, how often and in what context. And without that signal, it also cannot measure its own risk or react in time if something leaks. The global average cost of a data breach was 4.4 million dollars in 2025, a 9 percent drop from the year before that is explained, precisely, by the fact that companies that identify and contain faster pay less (IBM Cost of a Data Breach 2025). Banning without seeing means giving up that speed of reaction.

What to watch in behavior: what data the person pastes and under what pressure

If the risk is about conduct, the observation has to be about conduct. The useful question is not "are they using AI?", which we already know they are, but "what information do they hand over, when and why?". That is where the difference lies between harmless use and use that exposes the company.

Three things are worth watching. First, what kind of data ends up in these tools: asking it to rewrite a generic email is not the same as pasting in a customer database, proprietary code or unpublished financial information. Second, under what pressure it happens: the rushed paste, the "I need this in ten minutes", is where the person skips the controls without thinking, the very dynamic any social engineering attack exploits. And third, whether an approved alternative exists and is within reach, because when there is none, the shadow tool is the only way out and clandestine use is guaranteed.

That approach shifts the conversation from blame to observation. It is not about catching anyone doing something wrong, but about understanding a pattern of behavior so you can step in where it truly matters. It is the same logic that applies to any risk born of a human decision under pressure: first you observe the real conduct, then you correct the part that exposes you.

How a human risk program tackles the habit without blocking the tool

A human risk management (HRM) program, meaning the approach that measures and corrects how people behave in the face of risk rather than only what they know, tackles shadow AI on the side of the habit, not the block. The premise is that the employee will keep reaching for the tool that solves their problem, so the goal is not to switch off that impulse but to educate the decision that comes with it: what can be pasted and what cannot, how to recognize when haste is pushing someone to skip a control, and where to go when a safe alternative is needed.

That is achieved with training at the moment the risky conduct appears, not an annual course no one remembers, and by measuring whether the lesson changed behavior rather than whether the employee attended.

Here a concept enters that is worth naming precisely: the retest, which means testing the person again weeks later, in an equivalent situation, to see whether they truly changed how they act or only remembered the instruction for a while. The difference is not minor: there is peer-reviewed evidence that completing training does not on its own predict a reduction in real failures, and that what demonstrates change is testing the behavior again (Ho et al., IEEE S&P 2025; Lain et al., IEEE S&P 2022). We go deeper into that idea of testing conduct in our piece on what a security behavior and culture program actually is.

At Fensivo we work that use case from behavior: we measure how people act under pressure with personalized email phishing simulations, we deliver specific training the moment someone fails, and we validate with a retest that the lesson stuck, not that it was remembered. We do not detect which AI tools each employee uses, and that is not the point: the point is to prepare and check the person's decision when haste pushes them to hand over something they should not, whether in a chatbot or in a well-crafted email.

Shadow AI is not a fad that will pass or a hole to be plugged with a policy. It is the new face of an old problem: capable people taking reasonable shortcuts under pressure. Does your company know what information is walking out that door, or does it just have a policy that assumes the door is closed?