ISJ hears exclusively from Erika Dean, CISO at Tricentis who explains why “vibe coding” risks creating a new form of shadow IT.
AI is changing who can build software inside the enterprise, creating a new visibility challenge for CISOs.
As AI-assisted development puts software creation into the hands of more non-engineering staff, applications can be developed outside traditional teams and the security and governance processes that would normally apply.
In much the same way that cloud and SaaS created new forms of shadow IT, vibe coding can introduce software that security teams may not know about or be developed in accordance with security best practices.
The National Cyber Security Centre has already highlighted the need for safeguards around vibe coding, including the risks of relying on AI-generated code without appropriate security controls.
Meanwhile, the rapid adoption of tools such as Cursor and Claude means organisations today need to urgently rethink how they govern software development.
Speed without visibility
The appeal of vibe coding is clear: AI can produce functional applications at speed and with less technical knowledge by the producer.
But a working application is not necessarily a secure or reliable one. For security teams, the concern is not just whether AI-generated code contains vulnerabilities, but whether they know the application exists, what it can access and where it is being used.
As more employees gain the ability to create software using AI, the boundaries of the traditional development environment are becoming less clear.
Employees may be unfamiliar with secure development, software quality practices or enterprise governance requirements and may reasonably assume that if an AI-generated application works as intended, it is ready to use.
This is where cybersecurity can start to fall behind. AI-generated code can introduce vulnerabilities or insecure dependencies that are not immediately obvious, making testing and review essential.
Vibe coding should not be viewed as a trade-off between speed and quality.
The greater concern is the potential compromise between speed and visibility.
Quality and security measures must be built into the process from the outset so that applications cannot move from an informal experiment to an enterprise dependency without the appropriate oversight.
What can go wrong?
One of the biggest risks is when an application starts as something informal or personal, but then gets shared with other team members, gains wider usage and adoption, and eventually becomes integrated into enterprise systems or starts touching production data.
At that point, what began as an individual productivity tool can become a security concern.
An application may have access to sensitive business data, credentials, APIs or other systems without having gone through the controls that would normally apply to enterprise software.
AI-generated code can also introduce vulnerabilities or insecure dependencies that are difficult for non-specialist users to identify.
If companies have not thought through that process or built the right governance controls, they can end up with a shadow IT situation.
The application is effectively operating like a business application, but the organisation may have no visibility into it until it is too late and it is likely not being maintained appropriately.
This could lead to not just security vulnerabilities, but also operational risks
The parallel with traditional shadow IT is important: the problem is not necessarily that employees are deliberately bypassing security. It is that the organisation may not know what has been created, where it is being used or what it has access to.
How the vibe coding risk is evolving
The longer-term security challenge is therefore not simply whether AI-generated code is secure.
Rather, it is that AI is transforming software development from something performed by specialist engineering teams into something almost anyone can do.
And that fundamentally changes the governance challenge facing CISOs, making traditional boundaries around software development harder to define and monitor.
Most organisations are still in the early stages of governing AI-assisted software development.
But while tools like Cursor and Claude are being increasingly utilised to build applications and automate tasks, there is often a delay between software being created and organisations understanding where it is being used, what data it accesses and whether it has been developed with appropriate quality and security controls.
As these applications become more widely adopted, the challenge for CISOs will become less about whether code was written by a human or AI, and more about ensuring every application, regardless of who created it, is subject to the same governance, testing and validation standards.
The question is not who wrote the code, but whether the organisation can account for the application, understand its risk and apply the appropriate controls.
For CISOs, that means extending visibility and governance beyond traditional development pipelines to account for software potentially created wherever AI-assisted development is taking place.
What should CISOs do to manage the risks?
The first step is putting the right guardrails and governance in place.
Enterprises should provide approved AI development environments that automatically enforce testing, governance and security controls rather than allowing employees to use consumer AI coding tools independently.
Companies should also have clear guidance around when an application needs to go through formal review.
Again, any application that touches production data should have already been reviewed by security teams and go through the same protocols as any other production application.
The same principle should apply to applications that connect to internal systems, handle sensitive information, or become critical to business processes.
Ultimately, CISOs need visibility over every route by which software enters or evolves in their organisation, not just within traditional engineering pipelines.
Whether an application is written by a professional developer or generated by a non-technical employee using AI, the organisation should be able to identify it, understand what it can access and assess its risk.
It should then be subject to the same testing, governance and security standards before it reaches production.
Erika Dean is Chief Information Security Officer (CISO) at Tricentis, where she leads the company’s global security strategy, overseeing enterprise cybersecurity, compliance and product security while ensuring Tricentis’ software continues to meet the evolving security needs of enterprise customers. Erika has more than two decades of cybersecurity leadership experience spanning financial services and technology industries. Throughout her career, she has built and led security programs at Robinhood and Capital One focused on protecting organisations while enabling business growth, fostering customer trust and strengthening resilience against the evolving threat landscape.