The UK’s National Cyber Security Centre (NCSC) has published a formal guidance post telling developers and organisations exactly how much trust to place in AI-generated code, which is otherwise called vibe coding.
Written by Toby W, a Principal Security Architect at the NCSC, the blog post lays out what the agency is calling a “vibe coding spectrum,” a framework for how organisations should calibrate their use of AI-assisted software development depending on the risk attached to what they are building.
This post is the NCSC’s most practical intervention yet on vibe coding, and it arrives as AI coding tools have moved well beyond early adopters and into mainstream software development workflows.
What the NCSC Is Responding To
The blog post defines vibe coding as giving an AI agent a high-level prompt and letting it build an application with significant autonomy, where you prompt, it codes, you review the output, and iterate. And this process has become standard practice across development teams, startups, and enterprise organisations alike.
The NCSC’s concern is grounded in a specific and documented problem. AI models are trained on vast amounts of existing code and some of that code has security issues. When an AI is given significant autonomy over a codebase with minimal oversight, there is a real and measurable risk that it produces code containing security vulnerabilities. And even beyond security, AI-generated code can also become complicated and difficult to understand, where it is capable of creating maintainability problems that compound over time.
The Spectrum Framework
Rather than issuing a blanket restriction, the NCSC argues that vibe coding is not binary. It exists on a spectrum and organisations can position themselves anywhere along it depending on their context and risk tolerance. On one end sits manual human coding with some AI assistance, where the developer writes the code and AI offers suggestions. On the other end sits full vibe coding, where the AI has autonomy over architecture, code, modules, and tests, and the developer is evaluating output and prompting again rather than editing or deeply reviewing what has been produced.
Where an organisation lands on that spectrum should be driven by the stakes involved. The NCSC says full vibe coding can be perfectly appropriate for a proof-of-concept being built to demo an idea to stakeholders, an internal tool with limited exposure, or a prototype where speed matters and no sensitive data or security functions are involved. But authentication logic for a public-facing website, code that processes sensitive customer data, anything handling secret tokens or credentials, and safety-critical code in critical national infrastructure or aviation systems all require a fundamentally different level of care.
And the agency’s position on the consequences of getting this wrong is quite direct. Data breaches, compromised accounts, and regulatory violations are among the outcomes the NCSC names for organisations that apply full vibe coding to high-stakes systems without appropriate oversight.
What Oversight Actually Looks Like
The NCSC is careful to clarify that the guidance is not a prohibition on using AI for security-critical code.
The agency says AI can absolutely help with writing authentication logic, data processing pipelines, and code review. But the question remains how to do it safely. When building systems where security failures carry real consequences, developers need to review what the AI produces, understand the code, check for vulnerabilities, verify it does what is expected, and architect the wider system to minimise the impact of any exploitation. The NCSC also notes that another AI agent can be used to assist with some of these oversight activities.
Where the NCSC Points Critical Organisations To
For organisations whose work moves toward the higher-risk end of the spectrum, the NCSC points to Baseline Cyber Security Requirements for AI Models and Systems, developed with other governments, industry leaders, and cyber security experts through ETSI’s Technical Committee on Securing AI. Those requirements are intended to set a minimum bar for how AI systems involved in security-relevant development should be built and evaluated.
On what comes next, the agency takes a measured position by acknowledging that AI models are improving rapidly and that what feels risky today might feel routine in a year as model outputs become more reliable and trustworthy. But the agency is explicit that we are not there yet.
