Shadow AI is the generative-AI version of shadow IT: employees or teams using AI tools, models, or plugins that security never approved, with no visibility into what moves through them. Every report on the topic describes the same direction: something sensitive leaving the company through a tool nobody vetted. For a software house, that risk is real. It is not the one that costs the most six months from now.
What do security vendors mean by shadow AI?
Search the term today and the framing is close to uniform: IBM, Palo Alto Networks, Zscaler, Check Point, Orca Security, Vanta, and the Cloud Security Alliance all describe the same scenario, an employee pasting a customer list, a contract, or source code into a public chatbot the company never approved, with no log of what left or where it went. The PagerDuty Shadow AI Survey, published June 11, 2026 by Wakefield Research, puts a number on it: two-thirds of office professionals at companies with at least $500 million in revenue say they have used an AI tool at work they believed was not approved, and 88% had shared work-related information with a public AI tool. The survey covered marketing, finance, and operations roles. It explicitly excluded IT and technology staff, meaning it measured none of what a developer does with a coding agent.
The other direction: code arriving instead of data leaving
Flip the direction and the gap in that survey becomes the point: developers weren't excluded by accident, they were excluded because they were never "shadow" in the first place. Most of them use AI coding tools openly, often with the company's blessing. The Checkmarx Future of AppSec in the Era of AI report, published August 14, 2025 from more than 1,500 CISOs, AppSec managers, and developers across North America, Europe, and Asia-Pacific, found that 34% of organizations say over 60% of their code is now AI-generated, while only 18% have a policy governing how that happens, and 20% officially forbid AI coding assistants regardless. Sanctioned or not, the code keeps shipping. A policy built to stop information leaving through an unapproved channel has nothing to say about a change that entered the product through an approved one, with no record of which session produced it or who signed off.
| Data leaving (what gets measured) | Code arriving (what doesn't) | |
|---|---|---|
| What crosses the boundary | Company data pasted into an external tool | AI-written code merged into the product |
| Who notices first | Security, usually after an incident | Nobody, until someone asks why a change looks the way it does |
| What already exists to catch it | DLP, browser isolation, model allow-lists | Review tools that check the diff, not its origin |
| Cost if ignored | Data breach, leaked IP | Unreviewed logic in production, no record of who approved it |
Why doesn't banning the tools work in a delivery organization?
Banning AI coding tools is the fix 20% of the organizations in the Checkmarx survey already tried, with no sign it changes what ends up in the codebase. A ban only works if it's enforceable, and an assistant running inside an editor, a terminal, or a CLI leaves far fewer traces than a browser tab a web proxy can block. Most of these tools also run locally or through a CLI that never touches the corporate network path a DLP tool was built to watch, so the control that catches a pasted customer list has nothing to inspect when the same risk shows up as a generated function instead.
The practical result looks like vibe coding under a client deadline: code ships fast because shipping fast is the job, and whether a human reviewed it, or which agent wrote it under what authorization, stops being something anyone can answer after the fact. A rule nobody can verify isn't a control. It's a line in a document that makes an audit worse, not better, because now there's a policy on record the organization isn't actually following, on top of the original gap it was supposed to close.
What can you actually require instead of a ban?
Three things are enforceable where a ban isn't, because none of them depend on catching a browser tab before the code already exists:
- Declaration: every merged change states which agent or assistant touched it, even when the answer is "none."
- Verification: something other than the same model grading its own homework, a test suite, a build, a tool that checks the diff itself, confirms the code does what it claims before it ships.
- Record: the declaration and the verification result are stored somewhere that survives the person, or the session, that produced them.
None of this requires knowing every tool an employee might open on a given afternoon. It requires knowing what changed, at the one point every change already has to pass through: the merge.
A short policy that doesn't slow the team down
None of the above needs a security team rewriting how developers work. It needs the three steps above attached to the point in the pipeline every change already passes through, instead of a list of forbidden tools nobody can fully enforce. The same gap keeps showing up on what's declared inside an AI-generated build: the mechanism to show what's in a release and who approved it already exists, it's just rarely pointed at the question a shadow-AI policy was never built to answer. Detent (detent-ai.com) ties that declaration, verification, and signed record to every change on the line, from request to production, so "did an unapproved agent write this" has an answer that doesn't depend on asking around.