Vibe Coding Security Risks: What leaders must know
From idea to app before lunch
Over the past year, a new habit has gone mainstream. People call it vibe coding. You describe what you want in plain English, an AI assistant writes the code, and a few minutes later you have something that runs. A candidate tracker. A client portal. A dashboard that pulls in timesheets. No developer, no ticket, no waiting.
It’s genuinely impressive. The models are good, the cloud platforms underneath them are good, and the speed is intoxicating. But there’s a gap in the middle of all that excitement, and it’s the one I want to talk about.
“It works” is not the same as “it’s secure”.
A week that should make us all pause
This week has been a sharp reminder of how fragile things can be. Critical PHP vulnerabilities, dubbed PHP2Shell (CVE-2026-109618 and CVE-2026-109619), were rated 9.2 out of 10 and allow unauthenticated remote code execution. In plain terms, an attacker doesn’t need a password to run their own code on an affected server. Websites around the world were forced offline, and 32 UK government services were taken down as a precaution.
The detail that stuck with me is how the exploits came about. Researchers used frontier AI models to turn decades-old flaws into working attacks. The same technology that helps us build faster also helps attackers move faster. AI lowers the barrier on both sides of the fence.
If established, well-resourced organisations with dedicated security teams can be hit, imagine the odds for an app that was built in an afternoon, never tested, never reviewed, and quietly connected to candidate and client data.
Where vibe-coded apps tend to go wrong
None of these problems is new. What’s new is how quickly, and how quietly, they can now appear. When I look at apps that have been prompted into existence, the same issues come up again and again.
Secrets in plain sight
AI assistants will happily paste an API key or database password straight into the code to get things working. Once that code is shared, copied into a repository or pasted into another chat, the key travels with it.
Front doors without locks
Authentication and authorisation are often an afterthought. There’s a login screen, but does it stop a recruiter in one team seeing every other team’s candidates? Does the app check who is asking before it hands over a record?
Trusting every input
Injection and input validation flaws are classics for a reason. If an app passes whatever a user types straight into a database query, sooner or later someone will type something you didn’t expect.
Packages that don’t exist (yet)
AI models sometimes recommend software libraries that sound plausible but don’t actually exist. Attackers have noticed, and register those names with malicious code inside, waiting for someone to install them. It even has a name that Roald Dahl would be proud of: slopsquatting.
No record of what happened
As a software vendor with teams of developers, we have thousands of records of who did what and when - it makes rolling back if things go wrong very simple. Vibe-coded apps rarely log any of this. Without an audit trail you can’t investigate an incident, and you can’t prove that one didn’t happen.
Data wandering off
To build and debug new systems, people often paste real data into whatever tool is to hand. Sensitive information ends up in unsanctioned services, outside your contracts and outside your control. Multiply that across a business and you have shadow IT that nobody can see.
No testing, no review, no memory
There’s usually no code review, no security testing and no change control. Six months later, the person who built it has moved on and nobody understands how it works. Not even the AI that wrote it, which won’t remember the conversation.
Why recruitment firms should care most
Recruitment businesses hold exactly the kind of data attackers want: CVs, right-to-work documents, salary details, national insurance and IRS data, home addresses and phone numbers, for thousands of people who trusted you with them. That makes the sector a prime target.
It also puts you squarely in GDPR territory. If a vibe-coded tool leaks candidate data, the ICO will want to know what controls you have in place. Accountability sits with your organisation, not with the assistant that generated the code.
The regulator will not accept “the AI wrote it” as a defence.
The better path: AI inside the guardrails
Here’s the good news, and the reason I’m still an enthusiast. You don’t have to choose between speed and safety. The trick is to use AI inside platforms where security, identity and governance are already solved, rather than reinventing them in every app.
That’s why we build on Microsoft Power Platform and Dynamics 365. Data lives in Dataverse, with role-based security down to individual records and fields. People sign in through Microsoft, so single sign-on, multi-factor authentication and Conditional Access come by design.
Power Platform data loss prevention policies and managed environments control which connectors can touch which data. Proper application lifecycle management means changes are tested and promoted, not pasted straight into production. Copilot Studio agents sit under the same governance, and Microsoft Purview helps you classify and protect sensitive information wherever it goes.
Crucially, Mercury’s solutions run inside your own Microsoft tenant. I describe it as “your tenant, your lock, your keys”. Microsoft provides the lock; you hold the keys. And because Copilot respects the permissions you already have, people only see through AI what they were allowed to see without it.
You still get the speed. Low-code tools and AI assistance let teams build quickly. The difference is that the foundations underneath are governed, audited and patched as standard.
This is where the Microsoft approach changes the equation. The question isn't whether your people should use AI to build faster. They absolutely should. The question is what they're building on. With Power Platform, Dynamics 365 and Copilot Studio, you're starting with organisational identity, governed data, permissions and application management rather than trying to bolt those things onto an AI-generated application afterwards. That's the difference between vibe coding a tool and building a business application on a governed platform.
A checklist for leaders
These are the questions I’d be asking this week.
• Get a list of what has already been vibe-coded, including the side projects nobody mentioned.
• Never connect production data to an app that hasn’t been reviewed.
• Require code review and security testing before anything goes live.
• Keep secrets in a proper secrets manager, never in the code.
• Enforce single sign-on and multi-factor authentication on every business app.
• Prefer low-code on governed platforms over bespoke code nobody owns.
• Set a clear AI usage policy covering which tools are sanctioned and what data they may use.
• Ask your vendors the right questions about patching, testing, access control and incident response.
Embrace AI, with guardrails
I’m not asking anyone to slow down on AI. Quite the opposite. Move fast but keep your data safe, because trust is a competitive advantage too.
So keep experimenting. Let AI help your teams turn ideas into something real. Just don’t mistake a prototype for a product, or a working demo for a secure system.
Vibe coding is a brilliant prototyping tool, but a terrible security strategy.
Before somebody builds your next business-critical app in an afternoon, talk to us about how Power Platform and Copilot can deliver the same speed inside your Microsoft environment, with governance built in from the start (even if you're not already a Mercury customer), check out our Agent Accelerator program.