Shadow AI is shadow IT that writes code

Ten years ago the problem had a name and a shape. Someone in finance needed a thing done, IT had a six week queue, and a corporate card bought a SaaS subscription nobody in security had ever heard of. We called it shadow IT. We wrote policies about it. Mostly we lost, and then we adapted: we got better at providing sanctioned tools that were actually good enough to use.

The same thing is happening again, for the same reason, and the reason is worth saying plainly because it is not a moral failing. People route around the sanctioned path when the sanctioned path is slower than the work. That was true of expense software in 2016 and it is true of AI in 2026.

What has changed is what comes out the other end.

The output used to be a spreadsheet. Now it compiles.

Shadow IT produced data in the wrong place. That was bad, and it was mostly a containment problem: find the tool, assess it, migrate the data or block the domain.

Shadow AI produces something else. An engineer who uses an assistant to write an internal admin tool, a data-migration script, a small service that reconciles two systems, has not created a document. They have created software, and software gets committed, reviewed by whoever is free, and deployed. It acquires a database credential. It gets an ingress. Six months later it is load bearing and nobody remembers it was written in an afternoon by a model.

This is the part that makes the old playbook a poor fit. You cannot handle it at the network edge, because the artifact is not traffic to an unapproved domain. It is a pull request in your own repository that looks exactly like every other pull request.

The numbers, and the one that points somewhere useful

The scale is not in dispute. In 2026 enterprise telemetry, roughly 47% of generative-AI users still reach those tools through personal accounts, bypassing enterprise controls entirely. The average organization now records around 223 generative-AI data-policy violations per month.

And here is the number that should matter most to anyone reading this as an engineering leader: source code is the single largest category of sensitive data involved in those violations — ahead of regulated data, ahead of intellectual property, ahead of credentials.

That is not a generic story about employees pasting customer records into a chatbot. That is your codebase.

The usual conclusion drawn from numbers like these is restrict harder. But there is another one in the same dataset that points somewhere more useful. Over twelve months, the share of enterprise genAI users on personal accounts fell from 78% to 47%, while activity moved onto organization-managed infrastructure.

Be careful about what that does and does not show. It is a trend, not a controlled experiment. It does not prove that providing an approved tool caused any particular person to abandon an unapproved one. What it does show is that enterprises are successfully moving AI activity out of personal accounts and onto managed infrastructure at real scale.

The lesson is not that prohibition finally started working. It is that people move onto the governed path when the governed path exists and is good enough to use.

A ban does not remove the work. It removes your visibility into the work.

Three options, honestly stated

Ban it. The work moves to personal accounts and unreviewed pipelines. You have not reduced your AI exposure, you have reduced your measurement of it, which is worse, because now you will find out from an incident instead of a dashboard. And you have picked a fight with your best engineers over a tool that demonstrably makes them faster.

Allow it, unmanaged. Agent output arrives at agent throughput, and the shape of the risk is worse than the volume alone suggests. In Veracode's Spring 2026 benchmark, syntax correctness for AI-generated code exceeded 95% while only about 55% of generation tasks produced secure code. The code compiles. It reads naturally. It passes the smell test in review. And roughly half the time it carries a known flaw anyway. That is the failure mode human review is worst at, because nothing about it looks wrong.

Govern the path. Let people use the agents. Put a control between what the agent proposes and what reaches production, and make that control fast enough that going around it is not worth the trouble.

Only the third option keeps both the speed and the evidence.

Ban it

Policy says no. Tooling is not provided.

What happens

The work moves to personal accounts and unreviewed pipelines. Exposure is unchanged; measurement of it is gone.

What you can show an auditor

An acceptable-use policy, and no way to know whether it was followed. You find out from an incident rather than a dashboard.

Allow it, unmanaged

Engineers use agents. Nothing sits between output and the repo.

What happens

Agent output arrives at agent throughput, and review is the only control standing between it and production.

What you can show an auditor

Whatever your reviewers happened to notice, at the volume they happened to face that week.

Govern the path

Engineers use agents. A control sits between proposal and production.

What happens

Every proposal is evaluated before a person opens it, and a named human still merges.

What you can show an auditor

The rules that were in force on a given day, who approved a given change, and a linter that would have rejected any attempt to weaken a control.

Only the third column keeps both the speed and the evidence. The first two are not caricatures — both are in wide use, and the first is often the one written down. The difference shows up in the last row, when someone asks what your controls on AI-written software actually are and the honest answer has to be an artifact rather than an assertion.

What governing the path actually means

Concretely, it means the agent's output does not go straight to a human's judgment or straight to a cluster. It goes through something that has an opinion, before either.

At TruStacks that something is a signed Rego policy bundle: universal rules that every proposal must satisfy, plus your own overlay rules, written by your architects, that can only ratchet stricter and never looser. Every change the agents propose arrives as a pull request that has already been checked against all of it, and a named person merges it. Agents propose, policy decides, humans approve.

The part that matters for this argument is not the mechanism, though. It is the property the mechanism produces: when someone asks what your controls are on AI-written software, you have an answer that is an artifact rather than an assertion. You can produce the rules that were in force on a given day. You can name who approved a given change. You can show that a team could not have weakened a control to get their change through, because the linter would have rejected it at compile time.

That is a different kind of answer than "we have an acceptable use policy."

The question you will be asked

Whatever you decide, the question is coming, and it is arriving from more directions each quarter: your auditor, your largest customer's vendor security review, and increasingly your own board via the EU AI Act, the NIST AI Risk Management Framework, and ISO 42001.

It is not do you allow AI. Everyone allows AI now, whether or not they have decided to.

It is: what controls do you have on what your AI agents ship to production?

If the honest answer today is a policy document and a hope, that is worth knowing before someone else finds out for you. And it is worth knowing that the fix is not a harder ban. It is a path good enough that nobody wants to go around it.

Sources: generative-AI account and data-policy-violation figures are from Netskope's Cloud and Threat Report 2026 (enterprise telemetry, published January 2026). Code-security figures are from Veracode's Spring 2026 GenAI Code Security update, which tested more than 150 large language models across 80 coding tasks in four languages; the 55% figure describes tested generation tasks under a security benchmark, not all AI-written code in production. If you are putting any of this in front of your own board, follow the links and read the methodology. We would rather you trust the argument than the citation.