AI is removing the technical barriers that once limited Shadow IT, creating a visibility problem that organizations can’t solve simply by saying no.
AI coding assistants have transformed software development speed almost overnight. There they sit, right inside your IDE or browser, ready and willing to build whatever your mind can dream up. Turbocharged with tools like GitHub Copilot, Cursor, and Claude Code, developers are using these “superpowers” to ship features faster than ever.
But speed without guardrails creates a different kind of debt, and organizations are accumulating it quickly.
AI-generated code can look right even when it isn’t. A controlled study of developers using an AI coding assistant found they were more likely to produce insecure solutions than those coding without help. Perhaps more concerning, they were much more confident that their code was secure. That’s a dangerous combination. An AI assistant will happily generate a database query with a SQL injection vulnerability or hardcode an API key into a configuration file, and the developer reviewing it right before quitting time on a Friday has every reason to trust the output and move on.
The same problem extends into the software supply chain. AI coding tools have been known to hallucinate package names and invent dependencies that don’t exist. Attackers have caught on. They register those hallucinated package names on public registries, load them with malicious code, and wait. When another developer receives the same hallucination and installs it, the payload executes. Think of it as dependency confusion at scale, powered by the predictability of large language models.
But the bigger change isn’t what AI lets developers do. It’s who gets to build things in the first place.
From Shadow IT to Shadow AI
AI is democratizing development just as it’s empowering Shadow IT. Marketing teams that have never had a developer on staff are now generating scripts, automations, and integrations using AI tools. That code may live in private repositories with no security review, dependency scanning, or CI/CD pipeline enforcing standards. Or it may never touch version control at all, instead running directly in low/no-code platforms, shared drives or scheduled tasks that nobody owns.
Historically, Shadow IT has carried a slightly nefarious reputation, but in practice it almost always emerges for a rational reason. Businesses have real needs that central IT can’t meet quickly enough or at all, so motivated users build their own workaround(s). The intent is to keep the business moving, not to undermine security. Unfortunately for the business, the risk is the same either way.
Shadow IT has been a headache for CIOs for decades, but the conventional wisdom about what makes it dangerous is often wrong. Someone bringing in unauthorized hardware or spinning up rogue cloud storage is a problem, but a rogue wireless access point is reasonably easy to find and shut down. The real nightmare has always been users writing their own software against custom production systems or building workarounds outside their standard applications.
When organizations run massive vertical application stacks, a single SAP patch can break every piece of homegrown code built on top of them. The same goes for business intelligence dependencies. A renegade reporting tool telling leadership that sales hit one number when the real figure is something else entirely creates problems far beyond the IT department.
Shadow AI is the same basic phenomenon: employees using AI tools, building AI-assisted workflows, or connecting AI to company data and systems outside normal IT oversight. But traditionally, Shadow IT had a natural constraint: someone in the department actually had to know how to code. Shadow AI just needs someone with a browser trying to finish their expense report before lunch.
The developer who built an unauthorized system at least understood they were going around IT and usually had some sense of the rules, even if they were breaking them. The HR coordinator pasting termination details into ChatGPT to help polish the wording may have no idea they just sent employee data outside the organization’s walls.
When Shadow AI becomes harder to track
Traditional Shadow IT tended to stay contained. Accounts Payable’s invoice tool stayed in Accounts Payable. Shadow AI spreads differently. One useful prompt gets dropped into Slack, and suddenly an organization has 50 potential data-leakage points its security team knows nothing about.
Vendors are compounding the problem by embedding AI capabilities into applications organizations already use. New features appear in HRIS, ERP, CRM and email platforms, sometimes without the kind of IT or security evaluation that would accompany the rollout of a traditional new system.
AI-first tools are also moving deeper into the employee’s working environment. Anthropic’s Claude Cowork, for example, runs from the desktop, can read and modify local files, and can access cloud tools and the web using connectors. The same forces that put powerful coding assistants in every IDE are now putting AI into the email, spreadsheets, and SaaS tools used by HR, finance, and operations—largely outside traditional IT change control.
Those little unauthorized tools aren’t just living inside your environment with bad dependencies anymore. They can send data to destinations you can’t see, audit, or control. Leave intellectual property and trade secrets aside for a moment. Think about a hospital and what happens when protected health information (PHI) walks out the door through a chatbot window.
You can’t govern what you can’t see
There’s no reasonable way to lock everything down and say no to every AI request. That approach guarantees workarounds, and workarounds mean even less visibility than you had before. The organizations that get this right will be the ones that treat AI the way mature companies eventually treated cloud adoption: not as something to prohibit, but as something to enable with eyes open.
That starts with knowing what is actually happening inside your environment. AI tools are already there, whether you approved them or not. Most organizations have no visibility into which AI services their employees are using, what data is being submitted or where that data ends up. Discovery isn’t a one-time project. It’s an ongoing discipline, and you can’t write a governance policy for tools you don’t know exist.
That principle applies to development, too. AI-assisted development is shipping vulnerabilities at the same speed it ships features. Code review, secret scanning, dependency management, and automated security scanning need to be part of the development lifecycle because polished-looking AI output is not the same thing as secure output. Security scanning in the software development lifecycle is table stakes now.
And that’s why prohibition is the wrong goal. Employees are going to use tools that make them faster, and businesses have good reasons to want them to. The job is to see where AI is being used, understand what data and systems it touches, and put reasonable guardrails around it without driving employees toward even less visible workarounds.
Shadow IT used to have a limiting factor: somebody had to know enough to build around IT. AI is taking that limiting factor away. The next piece of unauthorized software inside your organization may not look like software at all, and the person who created it may have no idea they created one.
____
About:
Jim Sherlock is VP of AI & Cybersecurity R&D at ProCircular, where he leads AI research and advises enterprises on agentic AI governance, attack surface management, and emerging security risk.
Join our LinkedIn group Information Security Community!
