Vibe coding works but is it secure?

Give an AI coding tool a description of what you want to build and, within minutes, you could have a working application in front of you. Features that took days to prototype can now be generated almost instantly. For businesses under constant pressure to launch products faster and achieve more with limited resources, the attraction is obvious. AI-assisted development has the potential to accelerate software creation and open up development to more people, while allowing experienced software engineers to focus on more complex challenges. 

But what about cybersecurity? 

We recently built three web applications using Gemini Pro. The first was given no explicit security requirements. The second was given general security instructions. And the third had detailed requirements based on industry-standard OWASP guidance. In security tests, we found that while more detailed security instructions certainly produced more secure applications, none of the three was secure enough to deploy. 

AI is able to produce applications that look polished and appear to have been built according to conventional development practices. But that can make vulnerabilities harder to recognise. 

In the first application, with no explicit security requirements, the weaknesses were fundamental. User roles could be manipulated through client-controlled input, users could access other users’ data, and authentication state was stored insecurely. The application did what it had been asked to do, but it effectively assumed users would behave as intended. Attackers do not. 

The second application had security explicitly included in the development process. The AI implemented measures including JWT-based authorisation, rate limiting, file-upload validation, CORS and content security policies. This appeared to be a much more security-conscious application, however, a short security review uncovered serious weaknesses. The file-upload functionality relied too heavily on filename, size and MIME-type checks, while a link-preview feature was vulnerable to server-side request forgery. 

The third application was given highly specific security requirements, including methodologies from the OWASP Web Security Testing Guide. The generated code was also subjected to a second AI-based security review. The result was substantially better, with stronger input handling, authentication and authorisation, but it still was not secure. Among the remaining issues were CSV injection in an export function, missing rate limiting on several endpoints and an open redirect vulnerability. 

Although AI can implement many established security controls, and providing better security guidance does make a measurable difference, it is not foolproof. Telling AI to make an application secure, even with specific requirements, is not, in itself, a security strategy. 

The problem with secure-looking software 

One of the more significant risks associated with AI-assisted development is that it can create software that looks secure enough. AI models have been trained on vast quantities of existing code and documentation, meaning they can reproduce established patterns and security recommendations remarkably well. Ask an AI coding tool to implement authentication, validate input or introduce rate limiting and it will often produce a technically competent implementation. 

When security depends on understanding how different parts of an application interact, it is very different. AI can know that user input should be sanitised, for example, without reliably identifying every place where that input could subsequently be used in a dangerous way. It may add rate limiting to the routes explicitly identified as sensitive while overlooking another endpoint that becomes attractive to an attacker. Security is not a checklist of individual controls; you have to understand how a system can be abused as a whole. 

And this will become particularly important when development is driven by natural-language instructions. The person describing what an application should do may not necessarily have the security expertise to anticipate how it could be attacked. The resulting application may satisfy the functional specification perfectly, while completely failing to account for the adversarial environment it will operate in. 

Vibe coding needs security guardrails 

None of this means organisations should not use vibe coding or AI-assisted development. The productivity benefits are genuine. AI can remove repetitive development work, accelerate prototyping, help teams experiment with ideas and allow skilled engineers to spend more time on problems that require deeper expertise. We just need to ensure that development speed doesn’t overtake security assurance. 

Organisations have to look at where security sits within the AI-assisted development lifecycle. Importantly, AI-generated code should be treated as untrusted until it has been reviewed and validated. It should go through appropriate code analysis, security review and penetration testing just as traditionally developed software would.  

The fact that code has been generated by an advanced AI model should not reduce the level of scrutiny it receives. If anything, the speed and scale at which AI can generate software make effective assurance even more important. 

Security requirements also need to be incorporated into the development specification from the beginning. In practice, this means giving people using AI coding tools appropriate guidance on secure prompting, threat modelling, security requirements and the circumstances where human review is mandatory. It also means establishing policies around which AI tools can be used, what information can be provided to them and how generated code is assessed before it reaches production. 

When it comes to testing software, it typically asks whether an application behaves correctly when someone uses it as intended. Security testing needs to examine what happens when someone deliberately uses it in a way it was never intended to be used. And having that adversarial perspective is more important than ever with AI speeding up the creation and deployment of applications. 

The next challenge is autonomous coding 

AI development tools are evolving beyond generating snippets of code or responding to individual prompts. Coding agents can plan development tasks, generate and modify code, run tests and interact with development environments with limited human intervention. 

If an AI system can generate a significant amount of code, make decisions about how a system is implemented and potentially make those changes, security cannot be the responsibility of an individual developer checking the final output. It has to be an organisational responsibility. 

Software engineering teams need to understand how AI is being used across the development lifecycle, while security teams need visibility into the tools and workflows being introduced. Development processes must have appropriate approval points and automated controls, and organisations need clear governance around what AI systems are permitted to do autonomously. 

Security needs to scale with AI 

AI-assisted development will become a normal part of how software is built. Trying to prevent it risks giving up significant opportunities for productivity and innovation, so we need to make sure security assurance evolves alongside it. 

Our testing showed that better security guidance produced better results, but even highly specific requirements and a second AI-based security review did not eliminate vulnerabilities. AI can reproduce security practices but reproducing those practices is not the same as understanding how a system could be attacked. 

AI is a very capable development assistant but it should not be treated as a security authority. Software development will include more and more AI-generated code, so we need to ensure the speed at which it is built does not outpace the ability to secure it. 

AI can build the software faster but it is up to humans to make sure what it builds is safe.