
Hoplon InfoSec
15 Jun, 2026
What This Article Covers
What AI code sprawl is and why it is fundamentally different from the shadow IT you already know
How vibe coding is turning HR managers, finance analysts, and operations leads into accidental software builders—without any security reviews.
Why policy-only responses consistently fail, and what the data shows about breach costs
Four governance strategies that security leaders at real organisations are using today
The unsolved problems that even the best CISOs are still wrestling with in 2026
A 30-60-90 day actionable roadmap to start governing AI-generated code now
Picture this. It is a Tuesday in March. An HR manager named Priya at a mid-sized financial services company needs to build an onboarding tracker for new hires. The existing system is clunky, and a ticket to IT has been sitting unacknowledged for three weeks. So Priya opens her browser, describes what she needs to an AI coding tool in plain English, and within forty minutes, she has a working web app connected to the company's HR database. She deploys it. Her team loves it.
Nobody in IT knows this happened. Nobody in security knows. No penetration testing was run. No code review took place. No one checked whether the database connection strings were hardcoded into the app or whether the permissions scopes were broader than necessary. The app is live, connected to sensitive employee records, and completely invisible to the people whose job it is to protect it.
Priya is not a bad actor. She is not reckless. She is someone trying to do her job faster than bureaucracy allows. And she is now one of hundreds of millions of people around the world doing exactly this, every single week.
This is what AI code sprawl looks like in 2026. And it is one of the most consequential security challenges facing enterprise organisations right now — not because the threat is exotic or technically sophisticated, but because it is happening constantly, invisibly, and with the best of intentions.
"380,000 publicly accessible assets created by AI coding platforms with no security review. That figure came from a single research snapshot. The real number across the full enterprise landscape is almost certainly higher."
Security teams have dealt with shadow IT for decades. An employee installs an unapproved SaaS tool, connects a personal Dropbox, or runs a local server nobody knows about. The response has typically been discovery, classification, and either shutdown or adoption. Uncomfortable, but manageable.
What is happening now with AI-driven code sprawl is fundamentally different in three ways: speed, scale, and the technical knowledge level of the person creating the risk.
Traditional shadow IT took time. Someone had to find a tool, sign up for an account, figure out how to use it, and integrate it. The friction itself provided a natural speed bump. With AI-assisted development, that friction is almost entirely gone. A non-technical employee can describe a problem in natural language and receive working, deployable code in minutes. A finance analyst who has never written a line of code in their life can build and ship a customer-facing application before lunch.
AI coding is now empowering non-developers in ways that shadow IT never did. Finance managers spin up unapproved workflows, marketing teams build customer tracking apps, and operations managers connect systems using automated pipelines, all without IT involvement.
The scale implications are staggering. Shadow AI usage increased by over 40% in 2025, especially in development teams, with 68% of organisations lacking visibility into the AI tools being used by their own employees. And the content being created carries real risk. GitGuardian's State of Secrets Sprawl 2026 report documented 28.65 million new hardcoded secrets in public GitHub commits during 2025, a 34% year-over-year increase representing the largest single-year jump ever recorded.
|
Dimension |
Traditional Shadow IT |
AI-Driven Code Sprawl |
|
Speed of creation |
Days to weeks |
Minutes to hours |
|
Who creates it |
Mostly technical employees |
Anyone, including non-technical staff |
|
Creator awareness of risk |
Partial, they know they are bending rules |
Near zero the risk is invisible to them |
|
Scale potential |
Limited by skill and time |
Unlimited AI removes all friction |
|
Detectability |
Possible with standard discovery tools |
Extremely difficult code lives in personal accounts |
|
Code quality and security |
Variable but reviewed by human who wrote it |
25%+ contains confirmed vulnerabilities |
The third difference is the most underappreciated. Traditional shadow IT was mostly created by technically literate people who understood, at least partially, what risks they were taking. The new wave of AI-generated code is being created by people who may have no idea that a hardcoded API key, an open database permission, or a missing authentication layer even exists. Non-developers don't even see the shortfalls in AI-generated code, let alone know how to close the gaps.
Here is something that makes security professionals uncomfortable to say out loud: the biggest driver of AI code sprawl is not malice. It is not a nation-state actor or a criminal ring. It is your most motivated, hardest-working employee.
Think about what "vibe coding", the practice of describing what you want to an AI in natural language and letting it build the code, looks like from the perspective of a mid-level manager under pressure. Their job spec now says, "An AI-first mindset is required." Their CEO sends internal memos about moving faster and embracing automation. Their team is stretched thin. And there is an AI tool right there that can solve their problem in forty minutes instead of waiting three weeks for a ticket.
The psychology here matters enormously for how you approach governance. These employees are not choosing shadow channels because they enjoy breaking rules. Most Shadow AI use is motivated by productivity, adopted openly by people who simply did not think to ask for approval, and concentrated in a handful of tools that have become as normalised as Google Docs.
When you understand that, you start to see that treating your employees as threat actors or designing governance that treats their judgement with contempt will not work. It will just push the behaviour further underground and make it harder to detect.
There are roughly three types of employees creating AI code sprawl risk, and each needs a different response.
This person genuinely loves technology and sees AI as a superpower. They have already built several internal tools and shared them across teams. They are often early adopters with decent intuition, but their enthusiasm outruns their security awareness. They do not know what they do not know about access controls, data classification, or vulnerability management. They are your highest-velocity risk creator and also your most valuable governance partner if you engage them early.
This person has hit bureaucratic walls so many times that they have developed creative strategies to get things done regardless of process. They are not interested in breaking security; they are interested in breaking the slowness that blocks them from doing their actual job. Every time IT takes four weeks to respond to a ticket, another workaround gets built. Governance that reduces friction is the only thing that will reach them.
This person genuinely does not understand that they are doing anything risky. They followed a YouTube tutorial, built something that works, and moved on. The database is wide open. The API key is in the front end JavaScript. They have no idea. This is the hardest group to reach because they do not know they need reaching. Samsung famously banned ChatGPT after engineers leaked proprietary source code, and a Cyberhaven study found that 11% of data employees paste into ChatGPT is confidential. The confidential data being pasted is often not intentional exfiltration; it is just how the person thought the tool worked.
The instinctive response from many organisations when they discover AI code sprawl is to write a policy. An "Acceptable Use of AI" document gets drafted, sent to all employees, and signed. A checkbox gets ticked in the compliance platform. Leadership feels like something was done.
And then nothing changes, because policy alone has never stopped a determined or uninformed person from taking the path of least resistance.
"If you ban AI tools without offering an alternative, you don't eliminate the behaviour; you just make it invisible."
Gartner predicts that by 2030, more than 40% of enterprises will experience security or compliance incidents linked to unauthorised shadow AI. GenAI traffic surged more than 890% in 2024, and Menlo Security reported a 68% surge in shadow generative AI usage across enterprises in 2025. Only 37% of organisations have policies to manage or even detect shadow AI, leaving the majority flying blind.
Policy fails for three structural reasons. First, most employees simply do not read security policies with the depth or regularity that would make them effective behavioural guides. Compliance fatigue is real. After signing the fifteenth policy document of the year, nobody is carefully weighing each clause before opening an AI tool.
Second, policy does not address the underlying need. The HR manager who built the onboarding tracker is not going to stop needing an onboarding tracker just because there is a policy against unapproved apps. She will find another way.
Third, and most critically from a regulatory standpoint, policy without technical enforcement creates a false sense of security that makes your legal exposure worse, not better. SOC2 Type II audits assume documented change management processes that bypass workflows are violated by design. ISO 27001 controls for asset inventory become meaningless when assets proliferate outside established channels. When a breach happens and the investigation reveals that you had a policy nobody followed, it is not a defence; it is evidence of a governance gap.
The legal implications are increasingly severe. GDPR Article 32 mandates appropriate technical data protection measures. HIPAA requires access controls and audit trails for health data. SOC 2 compliance depends on documented, enforced change management. ISO certification for AI now exists precisely because ungoverned AI creates systematic compliance gaps. The EU AI Act, entering full enforcement in August 2026, adds another layer of regulatory accountability that many organisations are completely unprepared for.
Shadow AI incidents average $4.63 million per breach, $670,000 above the baseline for standard breaches. 63% of organisations that experienced AI-related breaches lacked an AI governance policy. 32% of breached organisations paid regulatory fines, with 48% exceeding $100,000.
The message is clear: policy needs to be paired with technical controls, visibility infrastructure, and a fundamentally different approach to how security teams position themselves relative to business units.
The organisations navigating AI code sprawl most effectively have something in common: they stopped trying to prevent AI use and started trying to shape it. Here is what that looks like in practice.
Most organisations say they have data classification. What they actually have is a taxonomy document that nobody has operationalised. "Sensitive", "confidential", and "public" mean different things to different teams, and the gap between how data is labelled and how it is actually handled is where AI sprawl exploits first appear.
Effective data classification for the AI era requires three things. First, the classification needs to be machine-readable embedded in the data itself in a way that access control systems, DLP tools, and AI governance platforms can act on automatically. A label in a spreadsheet that only a human reads is not classification; it is documentation.
Second, classification needs to cascade to permissions. If a dataset is classified as containing personally identifiable information, then any AI tool that accesses it should automatically trigger review and logging through your attack surface management processes.
Third, classification needs to be maintained as data moves. In the AI era, data moves constantly; it gets pasted into prompts, fed into agents, and exported to new tools. Static classification done once at creation is not enough. You need dynamic classification that follows the data.
The traditional security model positions the security team as a wall between business units and risk. Requests come in, security reviews them, and approvals or rejections come back. In the AI era, this model simply cannot scale. There are too many requests, too many tools, and the velocity of adoption is too high.
The more effective model, sometimes called the internal marketplace or "paved path" approach, inverts this. Instead of reviewing everything reactively, security teams build a curated set of pre-approved, pre-secured tools and workflows that business units can adopt immediately. The security team's job becomes making the safe path so much easier than the unsafe path that employees naturally choose it.
"Build the paved path. Create the AI skills files, the process, and the blessed route for deploying an app inside your organisation." Will Bengtson, CISO at ConductorOne
In practical terms, this means maintaining a vetted library of AI tools with documented security profiles, providing templates and starter kits for common use cases that Priya the HR manager can actually use, and giving business units a fast-track approval process (measured in days, not weeks) for tools that are not yet on the approved list. When the safe path is also the fast path, shadow AI loses its main competitive advantage.
This is the kind of thinking that connects directly to virtual CISO services' security leadership that integrates with the business rather than operating as a separate compliance function.
AI agents, autonomous software systems that take actions on behalf of users, are no longer experimental. They are running inside enterprise environments right now, with access to databases, APIs, email systems, and cloud infrastructure. And most organisations have no centralised record of what agents are running, who deployed them, what data they can access, or what they are authorised to do.
A use-case registry treats AI agents the same way you would treat any other piece of critical infrastructure. Every deployed agent gets an entry that includes who owns it, what data it can access, what permissions it holds, what it is supposed to do, and when it was last reviewed.
This is not bureaucracy for its own sake. It is how you make AI agents auditable. When an incident occurs, and incidents will occur, the registry is how you answer the questions that regulators and legal teams will ask. What was the agent doing? Who authorised that access? What data did it touch?
The registry also serves as a forcing function for accountability. When someone knows they will need to document an AI deployment and defend it in a review, they think more carefully before deploying. It does not stop all risky behaviour, but it creates a meaningful friction point at exactly the right moment in the process. Your cyber resilience assessment should include auditing what AI agents are currently active in your environment.
The hardest mindset shift for many security teams is accepting that the goal is not to minimise AI use; it is to channel it into forms that are secure and visible. Organisations that lead with restriction find that they drive behaviour underground. Organisations that lead with enablement find that they maintain visibility and influence over how AI gets used.
Enablement-first looks like providing training that helps employees understand AI risks without making them afraid of AI tools. It looks like offering pre-approved use cases for common needs so that building an onboarding tracker is something you do with IT's help, not despite IT's opposition. It looks like creating clear acceptable use guidelines that tell people what they can do, not just what they cannot.
The long-term goal is to enable users to use AI coding tools to build secure applications without resorting to a shadow approach. That means security training that is relevant to the actual tools people use, not generic awareness modules built for a pre-AI world.
It would be reassuring to say that the four strategies above are sufficient. They are not. There are real, structural problems in AI code sprawl governance that the industry is still working through, and security leaders who pretend otherwise are setting themselves up for a painful awakening.
Zero trust security architecture is built around the assumption that every user identity is a human who can be authenticated, authorised, and held accountable. AI agents break this assumption completely. An agent may hold multiple credentials, operate across multiple sessions simultaneously, take actions that were not explicitly anticipated when it was deployed, and have no meaningful way to be "authenticated" in the traditional sense.
Modern AI governance failures increasingly emerge through integrations and permissions rather than direct system compromise. Two-thirds of enterprises contain risky OAuth permission scopes. 23,021 SaaS applications were operating outside centralised IT visibility.
OAuth tokens created for AI agents outlive the humans who created them. OAuth tokens stay active indefinitely. Repository access remains open. Cursor connections to private repositories stay open after developers leave. GitHub Copilot business seats may transfer without review. API tokens created for AI tools outlive the humans who created them.
The solution requires extending your endpoint security and identity management frameworks to treat AI agents as first-class entities with their own lifecycle management, permission reviews, and revocation processes.
The AI tools employees are using are themselves software systems with their own supply chains, vulnerabilities, and potential for compromise. CVE-2025-48757 documented insufficient or missing row-level security policies in AI-generated Supabase projects, exposing data across more than 170 production applications. The AI generated the database layer but did not generate the security policies that should have restricted who could read the data.
In 2026, CVE-2025-53773 revealed that hidden prompt injection in pull request descriptions enabled remote code execution with GitHub Copilot. The EchoLeak vulnerability in Microsoft 365 Copilot demonstrated that a zero-click prompt injection could access and silently exfiltrate enterprise data.
The implication is that vetting AI tools at the point of adoption is not enough. Tools need ongoing security monitoring the same way you monitor any vendor in your supply chain. This is where cyber threat intelligence programmes need to explicitly track AI tool CVEs and vendor security disclosures.
Traditional SIEM platforms and code review processes were not designed for the volume and velocity of AI-generated code. When a single employee can generate thousands of lines of code in a day, the assumption that security teams can review commits at a meaningful pace breaks down.
70% of developers said that AI code generation created vulnerabilities in 2025, and almost all enterprises surveyed had at least one security breach as a direct result of in-house developed apps. About 30% of respondents admitted they ship compromised code and hope the vulnerability won't be found.
Web application security testing and AI-driven automated red teaming are increasingly important tools; for this reason, automated scanning that can keep pace with automated generation is crucial. Gap assessments specifically designed for AI-generated code are becoming a necessary part of regular security review cycles.
Most incident response playbooks were written before AI agents existed. They assume that the root cause of a breach is a human decision or a system compromise, not an autonomous agent that took an unexpected action based on a prompt injection attack or a permissions misconfiguration.
When an AI agent is involved in a breach, the questions are different. What did the agent do, and why? What instructions was it operating under? Was the behaviour within its authorised parameters or outside them? Was it manipulated, or did it operate exactly as designed but with unexpected consequences?
Organisations need to update their incident response and recovery playbooks specifically for AI-involved scenarios. Digital forensic investigation capabilities need to extend to AI agent logs, prompt histories, and action trails in ways that most forensics teams have not yet built.
Multi-agent systems, networks of AI agents that communicate with each other and orchestrate complex workflows without human involvement at each step, are already moving from research labs into enterprise production environments. When that happens at scale, the governance challenges of today will look manageable in comparison.
The CISO role is evolving in response. The security leader of 2027 is not primarily a defender of perimeters; they are an architect of governance systems that can scale with AI adoption. That means moving from reactive security (respond to incidents) to proactive governance (design systems that make incidents less likely and more visible when they do occur).
On the regulatory side, the EU AI Act is now in force. NIST's AI Risk Management Framework provides a voluntary but increasingly referenced standard. ISO certification for AI governance exists. The direction of travel is clear: organisations that do not build systematic AI governance will face increasing regulatory, legal, and reputational consequences.
The vendor landscape is responding. Tools from companies like Wiz, Cyera, and Drata are building AI-specific discovery, classification, and governance capabilities. Online threat exposure monitoring now increasingly includes AI tools and agent surface coverage. Dark web monitoring has expanded to track leaked credentials and data from AI platform breaches.
AI-related SaaS attacks increased approximately 490% year over year. More than 80% of SaaS and AI incidents involved sensitive or regulated data. The average enterprise now operates 3,891 SaaS and AI environments. That number will not decrease. The only question is how well governed those environments are.
Strategy is only useful when it translates into action. Here is a practical starting point, broken down by timeline and organisation size.
First 30 Days: Get Visibility
Run an AI tool discovery scan across your environment: identify what AI tools are already being used, by whom, and what data they can access.
Audit existing OAuth token grants: look specifically for tokens created by AI tools that may outlive their original context
Review your data classification schema: identify gaps where sensitive data lacks machine-readable classification
Talk to three business unit leaders about their AI use and their frustrations with current IT processes: the insight will shape your governance design.
Document every AI agent currently running in your environment, including who owns it and what it can access
Activate or extend your attack surface management programme to explicitly cover AI-generated assets
Days 31 to 60: Build the Governed Path
Establish a vetted AI tool list: five to ten pre-approved tools with documented security profiles and usage guidelines
Create a fast-track approval process (target: five business days maximum) for new AI tool requests
Launch a use-case registry; start with the AI deployments you already discovered and build the template from there.
Update your acceptable use policy to be specific about AI, what data types can be used with which tools, what is prohibited, and what the process is for new use cases.
Brief your incident response team on AI-specific scenarios, what questions to ask, what evidence to preserve, and what playbook steps change when an AI agent is involved.
Run a gap assessment on your current AI governance posture against the NIST AI RMF and EU AI Act requirements.
Days 61 to 90: Scale and Sustain
Roll out AI security training tailored to non-technical users, focusing on the specific risks of vibe coding and data sharing, not generic cybersecurity awareness
Implement automated scanning for AI-generated code in your development pipelines — do not rely on manual review at scale
Establish quarterly reviews of your use case registry; retire agents that are no longer needed and review permissions for those that remain
Brief executive leadership and the board on AI governance status; this is now a material risk management issue, not just a technical one.
Engage with security compliance partners to validate your AI governance posture against applicable regulations
Consider whether an M&A security advisory process is needed. Acquisitions often bring in entirely ungoverned AI environments that need rapid assessment.
|
Organization Size |
Priority Focus |
Key Tools / Approaches |
|
Startup (under 100 people) |
Establish classification and tool list early much easier to govern from the start than to retrofit later |
Lightweight registry spreadsheet, fast-track approval via Slack, one vetted AI tool per use case category |
|
Mid-market (100-2,000 people) |
Visibility and the paved path most critical phase, behavior is established but not yet calcified |
Discovery tooling, AI tool catalog, CISO-led business unit engagement program |
|
Enterprise (2,000+ people) |
Governance at scale manual processes will fail, automation and tooling are essential |
Automated scanning, agent identity management platform, regulatory compliance integration, dedicated AI governance team |
There is a tempting framing of AI code sprawl as a future problem, something to plan for before it gets out of hand. That framing is wrong. The wild code is already inside. It is running on your infrastructure right now. It was built by your most motivated employees, with the best of intentions, using tools that make building things trivially easy and thinking about security hard.
The question security leaders face today is not whether to prevent AI code sprawl. That ship has sailed. The question is whether you can build visibility, tracking, and containment systems fast enough to govern what already exists while also shaping what comes next.
AI-generated code is 1.88 times more likely to introduce vulnerabilities than human-written code. Production incidents per pull request increased 23.5% between December 2025 and early 2026. The numbers keep moving in the wrong direction while governance efforts are still in their early stages at most organisations.
The organisations that will navigate this well are not the ones that ban the most tools or write the most restrictive policies. They are the ones that build governance systems fast enough to keep pace with adoption, design security into the path of least resistance, and treat their employees as partners in risk management rather than threat actors to be controlled.
The first step is always the same: find out what is already running. Where does your organisation stand today? If you do not have a clear answer to that question, that is the answer.
If you need help building an AI governance programme that actually scales from cyber resilience assessment to attack surface management to hands-on virtual CISO support, the conversation is worth having sooner rather than later.
Was this article helpful?
React to this post and see the live totals.
Share this :