What happens when employees start shipping live applications without IT or security knowing, and what organisations should do about it.
The last two pieces in this series were about what vibe coding actually feels like for a normal person and not a professional content creator. I wrote them from the perspective of someone who did it with no development background and found out the cost.
One thing we haven't spoken about, and not enough people are, is security. How to stay safe while you're building your future unicorn.
This week we have a guest writer: Kit Barker.
Kit is a friend, and he's one of the few people I know who can talk about this from both sides.
He's spent the last several years working in information security (as a Chief Information Security Officer, an Application Security Engineer, and now as a Cyber and Information Security Specialist working with organisations on application security and data protection). He's reviewed the code these platforms produce. He knows what the AI leaves out.
I asked him to write this. I'm glad he said yes.
Key Takeaways
- Vibe coding isn't just a side-project phenomenon: employees across your organisation are already building and deploying live applications without IT or security knowing
- The AI builds what you ask for. It doesn't ask the questions a developer would (about access control, data encryption, or what happens when something goes wrong)
- "It works" isn't the same as "it's safe." The security gaps in vibe-coded applications are invisible until something goes wrong
- Banning these tools doesn't work. People will use them anyway, and you'll just lose visibility
- Proportionate governance turns a risky experiment into an organisational capability: due diligence on platforms, classify by risk, oversight scaled to what's at stake, and a register of what exists
Imagine this. A team lead in your HR department reads a series of articles about "vibe coding" (building software by describing what you want to an AI). She's been frustrated with the new starter onboarding process for months. Too many spreadsheets, too many emails, too many things falling through the cracks. So she opens one of the platforms (Lovable, Bolt, take your pick) over her lunch break.
By Wednesday, she has a working web application. It collects new starter details through a clean form, stores them in a database, and emails the IT team automatically when someone needs setting up. It looks professional. It works. Her team loves it.
And nobody in IT, security, or compliance knows it exists.
If you've read the previous articles in this series, you'll know two things: that non-developers really can build functional software with AI tools, and that it's considerably harder than LinkedIn would have you believe. Midnight debugging sessions and silently failing features should put paid to the idea that you just describe what you want and software appears.
But there's a dimension neither piece has covered yet. What happens when it's not one person building a side project? What happens when it's dozens of people across your organisation, building tools that handle real data, on platforms you haven't vetted, without anyone checking what they've made?
That's the question I spend a lot of my working life answering. And right now, most organisations aren't able to answer it.
This isn't new. But it's faster.
Organisations have dealt with shadow IT for years. The finance team's critical spreadsheet that only Dave understands. The marketing department's rogue Trello board full of client data. The sales manager who signed up for a CRM on a free trial and onboarded half the team before anyone in IT heard about it.
We know how to deal with that, more or less. It's annoying, it creates governance headaches, but the blast radius is usually contained. A spreadsheet on someone's desktop isn't great, but it's not a live application on the internet. The CRM is usually a reasonably robust SaaS platform.
The difference now is speed. Tools such as Lovable, Bolt, and Replit can take someone from a lunch-break idea to a deployed web application in hours. Not a prototype hidden on someone's laptop. A live application, on the internet, potentially handling real data, accessible to anyone with the URL. And the person who built it almost certainly hasn't thought about who else might be able to access it, because why would they? They're not a developer. They're someone who had a problem and found a remarkably effective way to solve it.
Shadow IT used to be a governance annoyance. Vibe-coded applications are a governance and security risk that moves at a pace most organisations aren't set up to handle.
The AI doesn't ask the questions an engineer would
The previous piece in this series made an important observation: the AI will tell you with complete confidence that it's fixed a problem, and the problem will still be there when you test it. That's a debugging challenge for an individual builder. The organisational problem is deeper.
When a software engineer builds something, they bring professional scepticism to the process. They ask questions the user didn't think of. Who should be able to access this data? What happens if someone enters something unexpected into this form? Should this function work differently because it's handling sensitive records? Does this integrate with anything else that might break?
The AI doesn't do any of that. It does what it's told: helpfully, confidently, and without challenge. Ask it to build a form that collects employee data and stores it in a database, it will build exactly that. It won't ask whether the data should be encrypted. It won't suggest that access should be restricted. It won't point out that the database is publicly accessible by default.
I've reviewed code produced by several of these platforms, and the pattern is consistent and the security maturity low. The AI builds what's requested, but leaves gaps that a competent engineer would have caught. Authentication that can be bypassed by changing a URL parameter. No input validation (meaning someone could inject malicious code through a form field). Sensitive data stored or logged in plain text. API keys embedded directly in the front-end code where anyone can see them.
The application works. It does exactly what the person asked for. It would also fail any security review I've ever conducted, and could be trivial for any frontier AI model to hack.
Think of it this way: the AI is like a very capable new hire who does precisely what you ask but never pushes back. That's fine when someone experienced is directing the work. When the person giving instructions doesn't know what questions to ask, nobody asks them.
The terms of service matter more than you think
Many of these platforms have terms that allow them to use the non-personal data you upload. For an individual building a side project with dummy data, that might be a perfectly acceptable trade-off. For an organisation whose employees are feeding in client information, commercial strategies, internal processes, or employee records? That's a different conversation entirely.
Where the data is stored matters too. Your employee in HR building that onboarding tool probably hasn't checked whether the platform stores data in a jurisdiction that meets your compliance requirements. If you're working in healthcare, legal, or financial services (or frankly any sector handling personal data under UK GDPR) that's not a theoretical concern. It's the kind of thing that comes up in regulatory conversations.
The point isn't that these terms are necessarily predatory. It's that nobody's reading them. And when you scale from one person's side project to a dozen employees building tools across the organisation, "nobody checked the terms" starts to look a lot less like an oversight and a lot more like a governance failure.
"It works" is not the same as "it's safe"
This is the gap that concerns me most, because it's the hardest to spot.
The earlier articles in this series described the visible problems: features that should work but don't, interactions that silently fail. You know something's wrong because the thing doesn't do what it's supposed to. The security problems are the ones you can't see. The application works perfectly. Users are happy. But underneath, there's no logging of who accessed what, no rate limiting, no proper error handling, and no separation between what different users should be able to see.
I've seen this pattern repeatedly. Without ongoing monitoring (the kind that requires someone who knows what they're looking for) there's no way of telling whether a change the AI made last Tuesday has quietly opened a hole in your security. The person who requested the change tested whether the feature worked. Nobody tested whether it broke something else.
Individual builders can tolerate a level of "it works, ship it" because the consequences are contained. When those applications handle your organisation's data, your clients' data, or your employees' data, "it works" isn't the bar you should be aiming for.
So what should you actually do about it?
If you've read this far and your instinct is "right, we need to ban these tools," I'd push back on that. Banning them doesn't work: people will use them anyway, and you'll just lose visibility of what's being built. More importantly, these tools genuinely do offer something valuable. The ability for non-technical people to build working solutions to real problems is worth having. The question is how you do it safely.
The key principles aren't complicated.
Do your due diligence on the platforms. Before anyone builds anything, understand the terms. Where does data go? Can you opt out of it being used for training? What jurisdiction is it stored in? This is a one-time exercise per platform, not a burden on every individual builder. Do it once, make a clear decision, and communicate it.
Classify what's being built by risk. Not every application needs the same oversight. A tool that tracks meeting room bookings is different from one that handles client data. A simple tiering system (based on what data the application handles and what the consequences would be if something went wrong) tells you how much scrutiny each project needs. The meeting room tool might need a quick check. The HR onboarding app needs a proper review.
Assign technical oversight proportionate to the risk. This doesn't mean an engineer needs to write every line of code: that defeats the entire point. It means someone with technical expertise is available to review security-critical features, advise on architecture decisions, and spot the gaps the AI leaves. Think of it like having a mechanic check a car you've built yourself. You did the work. They make sure it's roadworthy.
Know what exists. Maintain a register of what's been built, who built it, what data it handles, and where it's deployed. This sounds bureaucratic, and I won't pretend it's anyone's favourite task. But when someone leaves the organisation, or when you need to respond to a data subject access request, or when a security incident requires you to understand what systems exist, you'll be glad you know.
The framing matters here. This isn't governance as friction. It's governance as the thing that turns an exciting but risky experiment into a genuine organisational capability. Done well, it means more people can build, not fewer, because the guardrails are in place to let them do it safely.
The bigger picture
Paul's been writing this month about technological literacy as an individual skill: the willingness to pick up a tool, build something, break it, and keep going. He's right about that, and his honesty about what it actually costs has been a welcome counterpoint to the "build a SaaS in eleven minutes" crowd.
But there's an organisational dimension too. The organisations that get the most from this wave of AI-powered building won't be the ones that ban it, and they won't be the ones that let it happen unchecked. They'll be the ones that create the conditions (the governance, the oversight, the culture) for people to build safely.
Individual technological literacy is a willingness to be bad at something in public. Organisational technological literacy is the maturity to say: we want our people to build, and we're going to make sure they can do it well.