A client shows me his screen, clearly proud. In a few days, his team built a full application with an AI tool. Client form, database, dashboard. “We go live Monday.” The application works: that much is true. But working and being ready for production are two different things.

Building an app with AI has become simple. Shipping it to production without getting hurt remains a governance job. And that work starts before the first line of code, not after the first incident.

A quick reminder

Tools like Cursor, Claude Code, OpenCode, or Lovable can generate an application in a few hours from a simple description. People call it “vibe coding”: you describe what you want, the AI writes the code. To test an idea or show a sample to a client, it is a terrific tool. The problem is going to production without anyone stopping between the two.

The app that looks finished

The demo works well, and that is the trap. A demo only tests the happy paths: the right user, the right data, the right sequence. It does not test what happens when a dozen real clients use it at once, or when someone looks for a forgotten door.

In a serious project, there is planning, code review, security testing, and environment separation. Built quickly, the application skips almost all of those steps. It looks finished, so people assume it is ready. The protections were never put in place.

AI writes what you ask for. It does not write what you forgot to ask for.

What the numbers show

Veracode’s GenAI Code Security Report (2025) tested more than 100 models. Result: 45% of generated code samples failed security tests, with spikes above 70% for some languages.

Read those numbers carefully. This code does not necessarily contain more flaws per line than human-written code. The real problem is speed: people without security expertise put code online very quickly, and nobody reviewed it. The tool is not what fails: the verification step is simply gone.

In October 2025, Escape.tech analyzed 5,600 applications built with these tools. It found more than 2,000 high-impact vulnerabilities, more than 400 exposed secrets (access keys, passwords), and 175 cases of personal information leakage, including medical records and bank account numbers.

A few days after its January 2026 launch, the AI-built social network Moltbook left access open to 1.5 million access tokens and about 35,000 email addresses. The cause? A misconfigured database and an access key visible in code sent to the browser. The same story on the Lovable platform, where a documented flaw showed that about 70% of apps were running without access control enabled.

These cases are international, but the mechanism is universal, and nothing stops an identical case from already sleeping inside a local SMB.

Entire sections missing

These incidents are not isolated bugs to patch here and there. They are whole sections of security that were never built, because nobody asked for them. You do not repair a protection that does not exist: you decide to put it there, beforehand.

This is where the question becomes one of governance, not technology. The tool that wrote the code is responsible for nothing. The company that publishes the application is responsible for the personal information it collects. In Quebec, a personal information breach is a confidentiality incident you must assess and document. If it presents a risk of serious injury, you must also notify the Commission d’accès à l’information and the people concerned. AI will not do that assessment for you.

Application security belongs to the company, not to the tool that wrote the code.

Questions to settle before you launch

I am not telling you to stop using AI to build. Speed is a real advantage. I am telling you to decide your guardrails before you launch.

In information security, that framing has a name: secure development, a requirement of ISO 27001 (Annex A, control 8.25). The principle is simple. Security is part of the project from the start, not a polish pass at the end.

Here are the questions someone in your company should be able to answer before putting anything online. None of them requires you to be a programmer.

Are access keys kept out of sight?

Passwords and keys that give access to your data must never be written in clear text in the code. AI-generated code can contain them left in the open. Ask where they are stored and who can see them.

Does each user see only their own data?

An application can work perfectly while having poorly configured access rules. You need to verify that a user can only read or change data they are entitled to. That is exactly the control that was missing in the Moltbook case.

Can someone explain the sensitive parts of the code?

You do not need someone to reread every line. You need someone who understands the few places that matter: user login, who can see what, and how personal data is handled. If nobody can explain those parts, that is a red flag. I come back to this below, because “do we need a full expert review?” deserves a real answer.

Did you test security, not just features?

“It works” is not a security test. For an Internet-facing application that handles personal information, testing features alone is not enough: you need testing proportional to the risk.

Do you know what the AI imported?

Generated code often pulls in third-party libraries that nobody evaluated for necessity or security. Each one can bring its own flaws. You need to know which ones sit in your application and whether they are up to date.

Are you testing with real personal data?

A trial should never contain your clients’ real information. If a trial version leaks, real people are still affected.

Are trial and production separated?

The version you are tinkering with should not be wired to the same database that serves your clients. A mistake in testing must not be able to touch real data.

If the application is attacked, will you know?

Without access logs, an intrusion can go unnoticed for months. And in Quebec, you cannot report a breach you never detected. Security is not only about preventing the attack: it makes the incident manageable: see it, roll back with a tested backup, notify.

Who owns this in six months?

An application needs patches, monitoring, and backups. Name the owner before launch, not when something breaks.

Look at that list carefully. Most of these questions are not about code: they are about people. Who approves go-live? Who monitors? Who fixes? Who answers the client if it breaks? The biggest risk is not technical; it is organizational. Good code with nobody accountable for it is still a problem.

If you cannot answer “yes” to these questions, the application is not ready for production, no matter how convincing the demo looks.

Good news: three of these questions (secrets, dependencies, and code flaws) can be checked automatically and for free as soon as a developer pushes code. I already covered four free tools to validate code security before release in Your Team Codes Well. Nobody Validated the Security of That Code.

Three levels, not one

Not everything deserves the same rigor. It helps to name clearly where your application stands:

Trial

Validate an idea internally, with no real client data. Few requirements, but it stays internal. It does not go online.

Alpha / Beta

A few real users, limited real data, under supervision. The questions above become mandatory.

Production

Everyone can reach it. None of those questions can remain unanswered.

The real danger is treating production like a trial, only because it was stood up as fast as a trial.

Do you need to pay an expert to review everything?

No. And it matters to say that clearly. Having an external expert reread every line of a full software product costs a fortune, often tens of thousands of dollars. For an SMB that wants a small application, it is not worth it.

What is realistic is a layered approach, proportional to risk.

First, let tools do the work. The automated scanners I mentioned above catch forgotten secrets, vulnerable dependencies, and classic code mistakes for free, on every push. They clear a good share of problems that are easy to detect automatically. They do not replace validation of access controls, business logic, and the real environment configuration.

Next, review only the critical points. Not all the code: only login, who can see what, personal information handling, and payments. That is the small part of the code that concentrates most of the risk.

You can also ask the AI to critique its own code against a security checklist, before any human review. That does not replace an expert eye on critical points, but it catches a lot.

And adjust to the level: an internal trial deserves no external review; production software that stores client data does, on the critical points. Quebec’s Law 25 does not demand perfection: it demands reasonable measures based on data sensitivity.

Understanding your software is not reciting every function. It is being able to answer a simple question: if something breaks or leaks, do you know where to look and whom to call? My role is not to reread the code for you. It is to help you know what to require and what to document.

A prompt to get started

More and more managers use Claude Code, Cursor, or a similar tool themselves. If that is you, here is a prompt to paste into your tool so it reviews its own output against the questions in this list:

Act as an application security (AppSec) expert advising a Quebec SMB. You are preparing a go-live security review, not a marketing demo.

Context:
- Application generated or assisted by AI ("vibe coding")
- May process personal information (Quebec Law 25 / CAI)
- Goal: decide whether we can launch, and what must be fixed first

Strict rules:
- Invent nothing. If you cannot verify a point from code, config, or repo files, write clearly "NOT VERIFIABLE" and say what to inspect next (cloud dashboard, server env vars, server config, manual tests).
- Cite file paths and concrete excerpts when you claim a risk.
- Always distinguish: OBSERVED (in the repo) vs ASSUMED (hypothesis).
- Rate each finding: Critical / High / Medium / Low / Info.
- At the end, give a GO / NO-GO / GO WITH CONDITIONS recommendation, with numbered conditions.

Review each of the following points:

1. Secrets and credentials
   - API keys, passwords, tokens, connection strings in clear text in code, commits, versioned .env files, or public front-end?
   - Where should they live (secrets manager, server environment variables)?
   - Are any already exposed secrets that must be rotated immediately?

2. Data access control (IDOR / authorization)
   - Can each user only read and modify their own data?
   - Are access rules enforced on the server, or only hidden in the UI?
   - Are any endpoints, buckets, tables, or policies (RLS, IAM) left open "so it works"?

3. Authentication and sessions
   - How do users sign in? Passwords, OAuth, magic link?
   - Sessions / tokens: lifetime, storage, invalidation, CSRF protection if applicable?
   - Admin accounts: do they exist, and how are they protected?

4. Personal information and test data
   - Which categories of personal information are collected or stored?
   - Are there real personal data in fixtures, seeds, screenshots, logs, or config?
   - Minimization: is more collected than necessary?

5. Environments
   - Do trial and production share the same database, keys, or cloud project?
   - Can someone overwrite or read production from a dev environment?

6. Dependencies and third-party surface
   - List critical third-party libraries / services.
   - Flag outdated versions, known security advisories, or unnecessary dependencies to remove.
   - Third-party keys and webhooks: are they restricted?

7. Logging and detection
   - Would a suspicious login, authorization error, or bulk export leave a usable trail?
   - What is missing to investigate a Law 25 incident (who, what, when)?

8. Backup and recovery
   - Is a backup strategy visible in the project or docs?
   - Anything you cannot see in code: mark as "confirm outside the repo."

9. Sensitive points for human review
   - List files / modules that handle: login, permissions, payments, personal information, uploads, exports.
   - For each: explain in plain language what it does, why it is critical, and what question to ask the owner.

Response format:
A. Executive summary (5 lines max) for a non-technical manager
B. Findings table (point, severity, evidence, risk, concrete action, effort S/M/L)
C. GO/NO-GO checklist aligned with the 9 governance questions
D. What this review does NOT replace (secret/dependency/SAST scanners, manual access testing, cloud config)

If the repo is large, start with auth, API, database, config, and deployment paths, then widen.

Caution: this prompt is a first-pass review, not a guarantee. It replaces neither the free automated scanners mentioned above nor human review of critical points. A model that answers “everything looks fine” has not proven that everything is fine. Treat its answer as a list of leads to confirm, not as a green light.

The real problem

At the core, this is a tension between speed and control. Management is drawn to speed, reasonably so. But creation speed does not reduce your obligations. It only makes them easier to forget.

And catching up afterward is expensive. Rebuilding skipped protections in a rush, on an application already live with real clients on it, always costs more than planning them up front. Add downtime during the recovery and the incident you have to report.

In short, AI made building applications accessible to almost everyone. It did not make security optional. The application that works over the weekend can become a confidentiality incident the following Monday. The company answers for it, not the tool. I am not asking you to slow down. I am asking you to settle these questions before you launch. I am curious how many quickly built applications are already sleeping in production without anyone ever asking them.

Want to know where you stand on this? Let’s talk.

Sources