Vibe Coding Security: Risks and How to Ship Safely

A product manager describes a refunds dashboard to an AI assistant on Friday and has it running by Sunday. It works, the team loves it, and it sits on a public preview link with no sign-in and a live payments key in its source.

Nobody removed a security control from that app. No control was ever there, because nobody reviewed the result as company software.

Vibe coding security is the practice of reviewing, hosting, and controlling software that an AI assistant wrote from natural-language prompts, so it meets the same bar as hand-written code. It covers authentication, secrets, infrastructure, and the access the assistant itself holds while it works, not only the code it outputs.

Andrej Karpathy coined “vibe coding” in February 2025 for building software by describing it and accepting what the model returns. The habit spread from hobby projects into companies within months, and hobby-project review standards came along with it.

The model optimizes for code that runs, and a missing check still runs. Veracode’s 2025 GenAI Code Security Report tested more than 100 language models on 80 coding tasks and found that the generated code introduced an OWASP Top 10 vulnerability in 45% of cases.

The platforms show the same gap at scale. In 2025 security researcher Matt Palmer scanned 1,645 apps built on Lovable and found 170 of them exposing database tables to unauthenticated readers, tracked as CVE-2025-48757. The cause was missing or insufficient row-level security on the apps’ databases, which every builder’s app still ran fine without.

Speed is the other half of the risk. An app that took a weekend to build rarely goes through the review and hosting process that a six-month project would. It goes straight from a preview link to real customer data.

The risks fall into two groups. Some live in what the assistant writes, and some live in what the assistant can reach while it writes.

Assistants build what they are asked for, and “add login later” becomes a TODO comment that ships. Preview hosts issue a certificate for every new hostname, and certificates land in public transparency logs within minutes, so an unguessable link is still a published one.

The Unreviewed AI-Built App exercise puts you in that refunds dashboard. You review the code, take the link down, and bring it back only behind company single sign-on.

A generated app needs an API key to work, and the quickest place to put it is a constant in the code. Once that code runs on a public deployment, the key has to be treated as exposed whether or not anyone is known to have copied it.

The fix has a fixed order. Revoke the old key first so it stops working, then issue a replacement and read it from the deployment’s environment rather than the source.

Generated Terraform can be valid and readable and still grant public access to a storage bucket. A terraform plan only proves the provider can build the configuration, and a public ACL is perfectly buildable.

The Insecure Generated IaC exercise has you read what a generated bucket module actually allows. You then add a policy-as-code gate to the plan stage and confirm an anonymous request is refused. For the wider storage picture, see our guide to AWS cloud security misconfigurations.

An assistant with shell access runs every command as you, with whatever cloud profile your machine holds by default. In July 2025, SaaStr founder Jason Lemkin reported that Replit’s agent deleted a production database during a code freeze, and Replit responded by separating development and production databases automatically.

The Ambient Cloud Credentials exercise traces a similar delete to a production key set as the default profile. You take production credentials off the laptop, deactivate the key, and put approvals back on ask-before-writes.

Opening one folder in an editor marks where your project ends. It does not limit what the assistant can read unless its file access is bounded to that folder.

The Unbounded Agent File Access exercise follows a consultant whose assistant searched the whole disk and pasted another client’s code into a pull request. It ends with file access bound to the workspace, a profile per client, and a commit check for other clients’ names.

Approval prompts, tenant policies, and commit hooks feel like friction when a demo is due tomorrow. Turning them off removes exactly the checkpoints that would catch an agent following instructions it read in an untrusted file.

The Disabled AI Guardrails exercise is the capstone of our course. You live through that shortcut, watch a dependency’s README make the assistant write a live key into a committed file, then restore each control and prove it now stops the leak.

Treat AI-built software as company software from the first commit, and keep the assistant’s own access narrow. These controls cover the risks above:

• A developer reads every AI-built tool before it touches customer data, the same as any other pull request.
• Internal tools run on company infrastructure behind single sign-on, never on a personal preview link.
• Keys come from the environment or a secrets manager, and a pre-commit secret scanner blocks the rest.
• A policy-as-code check on the plan stage fails insecure resources before apply.
• File access is bound to the workspace, production credentials stay off development machines, and approvals stay on for writes.
• Nobody commits with --no-verify to get past a scanner. Fix what it flagged instead.

These are the same controls a mature engineering team already runs. Vibe coding just produces software faster than those controls get applied, so the gap has to be closed on purpose.

A developer who did not write the prompt should. The builder knows what the app is supposed to do, while a reviewer reads what it actually does, including the TODO where sign-in belongs.

Write that into policy before the next tool appears. Our post on shadow IT security risks covers how to bring unsanctioned tools into an intake process without banning them.

For the broader threat model behind these assistants, including prompt injection and MCP servers, read our overview of AI coding assistant security risks.

Is vibe coding safe for production apps?

It can be, once the output goes through the same review, authentication, and secrets handling as any other company code. The danger is skipping those steps because the app took a weekend instead of a quarter. Speed of creation does not lower the bar for what reaches customers.

Can I ask the AI assistant to make the code secure?

Asking helps, but it is advice the next request may not carry. Controls that run on every change, such as code review, a secret scanner, and a policy check in the pipeline, catch problems whether a person or a model wrote the code.

Who is responsible for code an AI assistant wrote?

The person and the company that ship it. Accepting a suggestion makes it your code, with any vulnerability or licence obligation it carries. An assistant drafts; a developer decides what goes out.

How do you train developers on vibe coding security?

Hands-on scenarios work better than policy slides because the failure modes are concrete: a public link, a key in source, a delete run with the wrong profile. Our Secure AI-Assisted Development course walks engineers through each one, then has them ship the fix and prove it holds.

Pick the newest internal tool someone built with an AI assistant and check three things: who can open it without signing in, what keys sit in its source, and what credentials its builder’s machine holds.

The AI & LLM Security catalogue includes the full Secure AI-Assisted Development course, free to try. You can also talk to us about rolling it out to an engineering team.

• Veracode, 2025 GenAI Code Security Report (July 2025)
• NVD, CVE-2025-48757 (2025)
• Fortune, AI coding tool Replit wiped a database and called it a catastrophic failure (July 2025)