AI tools have made it genuinely possible for non-technical staff to ship working software. The productivity gains are real. What does not come bundled with the tools is any of the governance, security review, or accountability infrastructure that normally surrounds software deployment. This piece is for the people building with these tools, and the managers being brought the results.
What Vibe Coding Actually Is — and What It Isn’t
The term was coined by Andrej Karpathy — co-founder of OpenAI — to describe a mode of working in which AI handles the entire development process rather than supporting it. The user prompts. The AI designs the architecture, generates code, finds dependencies, tests, and fixes errors. No programming knowledge required. Karpathy’s own framing: you can “fully give in to the vibes” and forget the code exists.
Tools in this category include Cursor, Bolt, and CodeGPT. They are categorically different from tools like GitHub Copilot, which functions as intelligent autocomplete and still requires a developer in the loop. Vibe coding tools are fully agentic — the non-technical user is the only human involved from concept to deployment.
That distinction matters enormously when things go wrong. Traditional AI-assisted coding complements a developer. Vibe coding replaces them — including all the review, testing, and institutional knowledge that comes with them.
This is not an argument that vibe coding should not be used. The speed advantage is real and the accessibility is genuinely democratising for small businesses with limited technical budgets. The argument is that the absence of governance around these tools represents a specific, underappreciated category of risk — one that can transform a perceived efficiency gain into a significant liability before anyone has noticed the problem developing.
The Security Risks That Don’t Announce Themselves
Security failures are rarely dramatic at the point they occur. A vibe coded tool handling customer data can run fine for months before a vulnerability is discovered — by which point the exposure has already happened. Several distinct risk mechanisms are worth understanding clearly.
Package hallucinations and slopsquatting
AI coding tools occasionally reference software packages and libraries that do not exist — a byproduct of their probabilistic, autocomplete-like functioning. In straightforward cases, this causes the build to fail. The more serious risk is what happens when it doesn’t fail at all. Malicious actors have begun registering the hallucinated package names that AI tools commonly produce, creating real packages filled with harmful code that the AI then unknowingly incorporates as a dependency. This attack pattern has been dubbed “slopsquatting” — an evolution of the older typosquatting technique. Because coding agents tend to hallucinate the same package names repeatedly, the attack surface is predictable and is being actively targeted.
An AI coding agent generates code that references a package called utils-validate-uk. The package doesn’t exist in any legitimate registry — but it does now, because someone registered it after seeing it appear in AI-generated code. Your new internal tool installs it automatically during setup. The package phones home. Your staff data, customer records, or internal credentials are now in someone else’s hands. Nobody noticed because the tool ran without errors.
Training data and inherited vulnerabilities
AI coding models are trained predominantly on publicly available code repositories. That means they absorb both exemplary practice and poor practice — deprecated libraries, insecure coding patterns, authentication approaches that were commonplace in 2019 and have since been identified as exploitable. These patterns are reproduced at scale, in production, without anyone necessarily being aware they are present.
Code bloat and the review problem
Coding agents tend to generate new code rather than reusing or refactoring what already exists. The result is significantly longer codebases than a human developer would produce for equivalent functionality. One commonly cited observation: a non-technical user can generate 20,000 lines of code in twenty minutes and spend two years debugging the results. That volume is not merely an inconvenience — it makes meaningful security review effectively impossible for anyone without deep technical knowledge of the specific codebase. Longer code means greater attack surface and exponentially more places for vulnerabilities to hide.
Multi-agent systems and MCP
More sophisticated vibe coding setups involve multiple AI agents coordinating with each other — one agent planning, another writing, another testing. This introduces additional risk: a single compromised agent can propagate malicious outputs across the wider system, and the coordination channels between agents are themselves potential attack vectors.
Anthropic’s Model Context Protocol (MCP) is worth noting specifically for a software-literate audience. It provides a standardised interface for connecting AI systems with data across different tools and environments — increasingly described as “the USB-C port for AI applications.” As adoption grows, it represents an expanding attack surface. MCP currently prioritises usability and currently lacks mature authentication standards, context encryption, and reliable mechanisms for verifying tool integrity. That will improve over time. For now, businesses connecting AI agents to live data sources via MCP should treat it as experimental infrastructure, not production-grade plumbing.
The Legal Exposure Most Businesses Aren’t Aware Of
Security breaches are one class of risk. Regulatory and legal exposure is another — and one that can arrive independently, before any breach has occurred.
UK GDPR obligations
If your vibe coded tool touches personal data — customer records, staff information, lead management, anything involving identifiable individuals — UK GDPR applies to how that software is built, not just to what it stores.
Article 25 requires that data protection considerations are embedded into systems from the point of design — “data protection by design and by default.” AI-generated code deployed without human review almost certainly does not meet this standard, because no qualified person has made deliberate choices about how personal data is handled within the architecture.
Article 32 requires appropriate technical and organisational measures for the security of processing. Unreviewed, undocumented software does not meet this standard by definition — there is no documented assessment of what measures are in place or why they are appropriate.
Article 33 applies regardless of how software was built: a qualifying breach triggers a 72-hour notification obligation to the ICO. The fact that the vulnerability arose from AI-generated code is not a mitigating circumstance in that process.
The EU Cyber Resilience Act
For any business with EU operations or customers, the CRA is relevant and coming into full effect in the near term. It requires manufacturers of software-based products to develop according to secure-by-design principles, conduct mandatory risk assessments, and provide security updates for at least five years post-deployment. Vibe coded software is structurally incompatible with several of these requirements. No equivalent general regulation exists in the UK yet, but the direction of travel is established.
Coding agents do not only generate software — they can also generate technical documentation, risk assessments, and security reports that look entirely plausible but have no connection to the actual state of the code. A vibe coder can produce a software bill of materials, a data flow diagram, and a security assessment without any of these documents reflecting reality.
This is “vibe compliance.” It creates a paper trail that may give false confidence internally and, in a regulatory or contractual context, could constitute misrepresentation. Documentation generated by the same tool that built the software is not evidence of a security process — it is an artefact of one.
Contractual obligations and insurance
Beyond regulation, many software development and service contracts contain explicit security obligations. Businesses deploying vibe coded tools in client-facing contexts — customer portals, booking flows, data collection forms — may be in breach of security commitments made elsewhere without having recognised the connection.
Cyber insurance is also relevant here. Policies increasingly contain exclusions for software developed outside defined secure development lifecycle practices. An insurer presented with a claim arising from a tool that was built without documented review, testing, or maintenance planning is in a strong position to dispute the claim. That is a conversation worth having before, not after, an incident.
Why This Is Different From Shadow IT
IT teams have been managing shadow IT for over a decade — staff spinning up unsanctioned Dropboxes, running business communications through personal WhatsApp groups, maintaining critical data in spreadsheets that exist nowhere in official infrastructure. The governance challenge was real and costly.
Vibe coding is shadow IT at a different order of magnitude, and the distinction is important to get right. Previous shadow IT primarily stored data in the wrong place. AI-generated software actively processes and exposes it through applications that have no review, no documentation, and no accountability structure. Someone’s personal Dropbox is a storage risk. A vibe coded customer-facing application handling payment data, contact forms, or staff records is an active security posture — one that nobody assessed and nobody owns.
The “bus factor” crystallises the maintenance problem. If the person who built the application — often without any technical background, often working alone, often in an afternoon — leaves the business, changes role, or simply moves their attention elsewhere, the institutional knowledge of what the tool does, how it works, and what it depends on goes with them. Unlike software built by a development team, there is no codebase anyone else understands, no documentation to recover from, and no handover process. The tool continues to run. No one is maintaining it. No one knows what maintaining it would even involve.
Software is also not a static artefact. Libraries age. Vulnerabilities are discovered and catalogued — the CVE database and the UK’s NCSC advisory service maintain ongoing records of known exploitable issues. APIs change. What is secure at launch can become a liability within months through no active failure on anyone’s part. Human-built software from a professional team carries a maintenance plan and an owner. Most vibe coded tools carry neither.
What Proper Governance Actually Looks Like
The goal is not to prohibit these tools. It is to establish a lightweight framework that captures the genuine productivity gains while ensuring that what gets deployed is understood, documented, and owned. For a 10 to 50-person business without a dedicated engineering team, the following is a realistic starting point.
-
What data does it touch? Identify every category of data the tool processes, stores, or transmits. If it touches personal data, UK GDPR applies to the architecture, not just the storage.
-
Who has reviewed the code? Someone technically qualified — not the person who built it — must have read the code before it is deployed. “The AI checked it” is not a review.
-
Where is it documented? Architecture, data flows, dependencies, and known limitations must be written down in a form that someone else could act on. If the documentation was AI-generated from the same codebase, it counts for nothing.
-
Who owns it when it breaks? A named person or team must be responsible for maintenance and incident response. Ownership cannot be “whoever built it” if that person has no technical background or could leave.
-
What is the patch process? When a dependency vulnerability is identified — and it will be — who gets notified, how quickly, and who makes the change? This process must exist before deployment, not after the first vulnerability notice.
The audit question to ask your team now
Before implementing forward-looking governance, it is worth establishing what is already running. The question to put to your team — framed not as an investigation but as a stock-take — is simply: what tools or automations are you currently using that were built with AI assistance, even partially? Include internal dashboards, reporting scripts, contact forms with custom logic, automated workflows, and anything that processes or stores data outside your core business systems. Most businesses that ask this question are surprised by what surfaces.
The threshold question: when is external review warranted?
Internal governance is appropriate for some use cases. External technical review is warranted for others. The following table is a reasonable starting framework.
| Scenario | Minimum standard |
|---|---|
| Internal tool, no personal data, read-only outputs (e.g. dashboards, reports) | Internal review sufficient |
| Internal tool handling staff personal data or HR records | Technical review + documented data mapping |
| Customer-facing tool with any data input | Independent technical review required |
| Any tool handling payment data or sensitive customer PII | Independent security audit required |
| Any tool deployed under a contract with security obligations | Legal review of obligations + technical audit |
Recommended tools for basic scanning
The following are accessible, well-regarded tools that a technical reviewer — even someone without deep security specialisation — can use as a starting point for assessing AI-generated code. They are not a substitute for professional security review in higher-risk contexts, but they add meaningful coverage for internal tools.
These tools generate reports. A report is not the same as security. The value is in having a qualified person act on the findings — which means the governance framework must identify who that person is before the tool runs, not after the first alert lands in an unmonitored inbox.
Vibe coding tools are entirely legal to use in a business context. The legal risks arise not from using the tools themselves, but from deploying the software they produce without appropriate review, documentation, and governance — particularly where that software touches personal data. UK GDPR places obligations on how software is designed and secured, irrespective of the tools used to build it.
AI tools can identify some classes of vulnerability and are improving rapidly. They cannot reliably detect novel or context-specific vulnerabilities, maintain meaningful context across large codebases, or provide the independent perspective that a genuine security review requires. AI-generated security documentation produced from the same codebase is not evidence of security — it is a description of what the AI thinks the code does, which may not reflect what it actually does. Independent review remains necessary for any tool handling sensitive data.
Slopsquatting refers to the practice of malicious actors registering software package names that AI coding tools commonly hallucinate — creating real, harmful packages that AI-generated code then incorporates automatically. Because different AI tools tend to hallucinate the same names repeatedly, attackers can predict which names to register. The risk is real, documented, and growing as vibe coding adoption increases. Dependency scanning tools such as Snyk address this class of risk directly, which is one reason they are included in the recommended toolset above.
Yes. UK GDPR applies to personal data regardless of whether that data belongs to customers or employees. Staff records, HR data, performance information, and any other data relating to an identified or identifiable individual are all within scope. Article 25 (data protection by design) and Article 32 (security of processing) apply to the architecture of systems handling staff data in exactly the same way they apply to customer-facing tools.
The data controller — typically the business that deployed the tool — bears primary responsibility under UK GDPR, irrespective of how the software was built or who built it. “It was AI-generated” and “a member of staff built it without oversight” are not defences in an ICO investigation. This is why governance — clear ownership, documented review, and a named person responsible for maintenance — matters not just operationally but in terms of demonstrable accountability.
This is an evolving area and policy terms vary significantly. What is consistent is the direction: cyber insurance policies increasingly contain exclusions or conditions relating to software developed outside documented secure development practices. If a claim arises from a tool with no documented security review, no identified owner, and no patch process, an insurer is in a strong position to dispute the claim on the grounds that appropriate technical controls were not in place. Reviewing your policy terms — and disclosing how internal software is developed — before an incident is the sensible approach.
Gary Walsh is the Head of Tech Support at Software Supplies, with more than 20 years in the IT industry. Fully Microsoft-certified and experienced across the full business software stack — from Windows and Office to cloud infrastructure and device management — Gary delivers practical, no-nonsense advice that helps users and businesses get the most from their technology.
