It can be, depending on what the app does and what data it holds. The NCSC says fully AI-written code can often be fine for prototypes and internal tools with limited exposure, but code that handles logins, sensitive personal data or credentials needs closer human oversight. This guide gives four risk tiers and a six-area checklist, marking what you can check yourself and what needs an engineer.
Perhaps a sales manager built a quoting tool with Claude Code, or an operations lead put a booking form together in Lovable, and now customers or company records depend on it. Our guide to what to do when a colleague has built a tool with AI covers the first conversation. This guide is the reference that sits behind it: how risky the app is, what to check, and when a vibe code audit is worth paying for.
What does the NCSC say about vibe coding?
The National Cyber Security Centre has published two relevant posts. The first, "The 'vibe coding spectrum' approach to AI-assisted software development" by Toby W, Principal Security Architect, published on 18 Jun 2026, makes the point that "Different code deserves different levels of oversight". At one end of its spectrum, a person writes the code with AI autocomplete. At the other, full vibe coding, the AI decides the architecture, code and tests from a high-level prompt, and the person judges the output without deeply reviewing the code.
The NCSC suggests sliding towards full vibe coding for prototypes, demos, internal tools with limited exposure, and work with no sensitive data or security functions. It suggests sliding towards manual control for authentication and authorisation logic, sensitive personal data, secrets, tokens or credentials, safety-critical code, and anything where a security flaw would have significant consequences. For that second group it says you need to review what the AI produces, understand the code, check for vulnerabilities and verify it does what you expect. In its words, "The risk isn't in using AI. The risk is not applying the right safeguards when the stakes are high."
The second post, "Vibe check: AI may replace SaaS (but not for a while)" by Dave Chismon, CTO for Architecture, published on 24 Mar 2026, is optimistic about where vibe coding is heading but blunt about today: "Currently, there are risks that are likely far outside most organisations' risk tolerances." On people without a technical background, it says the tools create code they never could, "but it's often unreliable, hard to maintain, or has critical issues."
The practical advice is to match the checking to what the software touches, which is the logic of the four tiers below.
Why do AI-built apps need checking at all?
AI coding tools are very good at producing software that works when you click through it. Security is a different property, and it is rarely in the prompt. Nobody asks for "access rules on every database table" when they ask for a booking form.
Published testing points the same way. Veracode's 2025 GenAI Code Security Report tested more than 100 large language models on 80 coding tasks and found that AI-generated code introduced security vulnerabilities in 45% of cases.
In our own reviews the same gaps recur: open database tables behind a convincing login screen, API keys in code the browser downloads, permissions enforced only on the screen, no backups, and an app only its builder understands.
Which risk tier is your app in?
The tier depends on who uses the app and what it holds. These are the same four tiers we use to price a review of an AI-built app, and the minimum checks are our recommendation before the app is relied on.
| Tier | Example | What is at stake | Minimum checks before you rely on it |
|---|---|---|---|
| Internal tool, no personal data | A dashboard, calculator or planner used only by your own team | Wrong figures feeding decisions, work lost if it breaks, and any keys it holds to your other systems | No keys or passwords in the code; it sits behind a company login; the code and hosting are in company accounts; someone other than the builder can run it |
| Internal tool with personal or financial data | A CRM add-on, an expenses tool, or anything holding customer or staff records | Personal data under UK GDPR, financial accuracy, and staff seeing records they should not | Everything above, plus access rules checked at the database, backups that have been restored at least once, and each connection to other systems limited to what the app needs |
| Customer-facing tool | A portal, booking system or form that people outside your business use | Anyone on the internet can reach it, so any gap is open to strangers as well as staff, along with customer data and your reputation | Everything above, plus an engineer's review of login and permissions, permissions checked on the server for every action, a scan of the libraries it uses, and logging of changes |
| Software you sell to others | A product other businesses pay for, where their data and their contracts depend on it | Your customers' data, your contractual commitments to them, and the security questions they will ask before signing | Everything above, plus a full engineering review before each significant release, a written incident plan, and a documented process for how code is changed and checked |
If you are unsure between two tiers, pick the higher one. Apps also move up the table: a planner gains customer names, or an internal form gets shared with a supplier. Revisit the tier whenever the app gains a new kind of user or data.
The customer-facing tiers deserve particular care because the people probing them are not only your customers. Our overview of what today's AI lets an attacker do to a UK business explains why a small, public app is still a target.
The checklist: six areas to check
These are the six places AI-built apps most often go wrong. Each item is marked "you can check this", meaning a non-technical owner can get an answer by asking or trying something, or "needs an engineer", meaning the answer depends on reading code, configuration or infrastructure.
1. Who can see your data
- You can check this: log in as an ordinary user and try to open a record that belongs to someone else, for example by changing the number at the end of the web address. If it opens, stop using the app for anything sensitive until it is fixed.
- You can check this: log out, then paste the address of a page you used while logged in. You should be sent to the login screen.
- Needs an engineer: check the access rules on the database itself. In many AI-built apps the browser talks to a hosted database directly, so the rules on each table are what stop one user reading another's records. The screens can look locked down while the tables are open.
- Needs an engineer: confirm that every action is checked on the server where it runs, so hiding a button is never the only control.
Apps built on Lovable or Replit with a hosted database raise specific questions here, which our guide to taking a Lovable or Replit app to production covers in detail.
2. Exposed keys and passwords
- You can check this: ask the builder to list every key, token and password the app uses and where each one is kept. If any answer is "in the code" or "in a file in the project", treat that key as exposed.
- You can check this: ask whether any of those keys belong to a personal account or are billed to a personal card.
- Needs an engineer: search the code, its full change history and everything the browser downloads for secrets. Deleting a key from the latest version does not remove it from earlier versions.
- Needs an engineer: rotate anything that was exposed and move it into a secrets manager, so the app reads keys at runtime and nobody pastes them into code again.
3. Vulnerable code and libraries
- You can check this: ask whether the code lives in a repository with automated dependency and secret scanning switched on, and who reads the alerts.
- Needs an engineer: review the code for unsafe patterns, such as user input reaching the database or the page without being checked, and error messages that reveal internal detail.
- Needs an engineer: check every library the app depends on for known vulnerabilities, and confirm each one is the package it claims to be. The NCSC's "Vibe check" post names "slopsquatting" among the new types of attack.
Automated review tools help with this area and are worth switching on. Our post on what Claude Code's security review checks, and what it leaves for a person explains where they stop.
4. Connections to your other systems
- You can check this: list every system the app connects to, such as your CRM, finance package, email or file storage, and which account it connects as.
- You can check this: if that account is a named person's login, the app may break when they leave, or keep their access long after it should have ended.
- Needs an engineer: narrow each connection to what the app needs, read-only wherever possible, and work out what someone could do with it if the app were compromised. A quoting tool that only needs to read deals should not be able to delete contacts.
5. Backups and recovery
- You can check this: ask when the data was last backed up and whether anyone has restored a backup. If nobody has, you do not yet know that it works.
- You can check this: ask whether there is a separate test version, or whether changes are made directly to the live app and its data.
- Needs an engineer: make sure changes to data are logged, so that you can tell who changed what and when.
Logging matters most when something goes wrong. Under UK GDPR, if a personal data breach is likely to pose a risk to people's rights and freedoms, you must notify the ICO as soon as possible and, where feasible, within 72 hours. Without logs it is very hard to say what was exposed, to whom, and since when.
6. Who owns it
- You can check this: find out which accounts hold the code, the hosting, the database and the domain, and who pays for each. Personal accounts are common in AI-built apps.
- You can check this: ask whether someone else could run and change the app if the builder left tomorrow, and whether anything is written down.
- Needs an engineer: move the code, hosting and data into company-owned accounts without losing data or breaking the live app, and document it so another engineer can pick it up.
If staff are going to keep building, it is cheaper to set up company-owned tools and checks around the people building than to rescue each app afterwards. Your AI policy should also say who may build what, and our AI policy template for UK businesses has clauses you can adapt. If you do not yet know how many of these apps exist, start by finding the AI tools already in use across the business.
Does Cyber Essentials cover an app your team built?
No. Cyber Essentials: Requirements for IT Infrastructure v3.3 (April 2026) says that publicly available commercial web applications are in scope by default, and states: "Bespoke and custom components of web applications are out of scope." An app your staff built with an AI coding tool is bespoke, so the certificate says nothing about whether it is secure.
The same document says the best way to reduce vulnerabilities in applications is robust development and testing in line with commercial best practice, and points to the Software Security Code of Practice. The certificate is still worth having for your devices, accounts and network, but it is not evidence about the app.
Whether the AI tool itself is safe to use with company data is a separate question, covered in our guide to whether Claude is safe and GDPR compliant for business.
A one-page summary you can print
Print this list and work through it with whoever built the app.
- Tier: who uses it, and does it hold personal or financial data? If in doubt, go higher.
- Data: can an ordinary user open someone else's record by changing the address? (You can check this.)
- Data: are access rules set on the database itself and checked on the server? (Needs an engineer.)
- Keys: is any key or password in the code or on a personal account? (You can check this.)
- Keys: has the code history been searched and exposed keys rotated into a secrets manager? (Needs an engineer.)
- Code: is dependency and secret scanning switched on, and does someone read the alerts? (You can check this.)
- Code: have the code and its libraries been reviewed for vulnerabilities? (Needs an engineer.)
- Connections: which systems does it connect to, and as whom? (You can check this.)
- Connections: is each connection limited to what the app needs? (Needs an engineer.)
- Backups: has a backup ever been restored, and is there a separate test version? (You can check this.)
- Recovery: are changes logged well enough to reconstruct an incident? (Needs an engineer.)
- Ownership: are the code, hosting, database and domain in company accounts? (You can check this.)
- Ownership: could another engineer take it over from the documentation? (Needs an engineer.)
- Cyber Essentials: the certificate does not cover bespoke apps.
A first-tier app that passes every "you can check this" item may be fine with light ongoing care. If any item fails, or the app is in the third or fourth tier, have an engineer look at it before more people rely on it.
How SpotDev can help
Our Safe to Ship vibe code audit covers all six areas, to the depth the app's risk tier requires, and ends with a written report graded by severity and a keep, fix or rebuild recommendation. Audits start from £1,500 and fixes from £1,500, both at a fixed price agreed before work starts. Our CTO signs off the version we reviewed, on the date we reviewed it. That sign-off is not a guarantee against every attack. Tell us what the app does and who uses it, and we will come back with its risk tier and a fixed price for the review.
Frequently asked questions
Is vibe coding safe for a business?
It depends on what the software does. The NCSC says full vibe coding can often be fine for prototypes and internal tools with limited exposure, but code that handles authentication, sensitive personal data or credentials needs people to review, understand, check and verify what the AI produced. Match the level of checking to the app's risk tier rather than treating every AI-built tool the same way.
What is the most common security problem in AI-built apps?
Data access is one of the problems we find most often. The login screen looks secure, but the database behind it has no access rules, so anyone who finds its address can read the records. Exposed API keys, permissions enforced only on the screen, missing backups and apps held in personal accounts also come up regularly.
Does Cyber Essentials cover an app our staff built with AI?
No. Cyber Essentials: Requirements for IT Infrastructure v3.3 states that bespoke and custom components of web applications are out of scope. A certificate covers your devices, accounts and network, but it says nothing about whether an app your team built is secure. That needs a separate review of the app's code, configuration and hosting.
Can we check an AI-built app ourselves?
Partly. A non-technical owner can find out where keys are stored, which accounts own the code and hosting, whether backups have ever been restored, and whether an ordinary user can open someone else's records. Database access rules, server-side permission checks, code and library vulnerabilities, and safely moving the app into company accounts need an engineer.
How much does a vibe code audit cost?
SpotDev's Safe to Ship audit starts from £1,500, with the fixed price set by the app's risk tier and agreed before work starts. Fixes start from £1,500, also at a fixed price. If you commit to fixes within 30 days, 20% of the audit fee is credited against them. Prices exclude VAT.
Does a sign-off mean the app cannot be hacked?
No. Our CTO's sign-off applies to the version we reviewed, on the date we reviewed it, and means an experienced engineer would be comfortable shipping that version. It is not a guarantee against every attack. Later changes to the app, its libraries or its hosting need checking again, which is why ongoing scanning and review matter.
Sources
- NCSC (Toby W, Principal Security Architect), The 'vibe coding spectrum' approach to AI-assisted software development, 18 Jun 2026
- NCSC (Dave Chismon, CTO for Architecture), Vibe check: AI may replace SaaS (but not for a while), 24 Mar 2026
- NCSC, Cyber Essentials: Requirements for IT Infrastructure v3.3, April 2026
- Veracode, AI-generated code poses major security risks in nearly half of all development tasks (2025 GenAI Code Security Report), 30 Jul 2025
- Information Commissioner's Office, UK GDPR data breach reporting (DPA 2018), accessed 8 Oct 2026
Get new articles by email
Practical guides from the SpotDev team, when we publish them.
By submitting this form, you consent to us sending you emails with our latest content. Privacy Policy
