Memo to security leadership:
The business is going to like vibe coding.
By vibe coding, we mean building software by describing intent to AI systems and iterating through generated code until the product works. It can turn a rough idea into a prototype fast. Sometimes that prototype becomes useful before anyone has decided whether it is allowed to become real.
That is the security problem.
The answer cannot be “because security said no.” That will not hold.
The better answer is: move fast, but make the blast radius visible.
What changed
Vibe coding changes who can create software and how quickly a sketch becomes an artifact.
Someone in operations can build a dashboard in an afternoon. A product manager can mock a workflow that looks suspiciously close to production-ready. An engineer can turn a vague idea into a working branch before the ticket is fully written.
That is exciting. It also breaks assumptions hidden inside many AppSec programs.
The old model assumed that production code passed through a limited set of people, repositories, review habits, and deployment paths. Vibe coding stretches that model. More people can create more code with less friction. Internal tools appear faster. Prototype branches look polished. The distance between “toy” and “we depend on this now” gets shorter.
Security risk follows the dependency, not the vibe.
Top vibe coding security risks
1. Ownership gets blurry
If a person prompted the system, an AI wrote most of the code, and another person approved the pull request, who owns the behavior in production?
The merging team should be the default accountable owner, with AppSec and platform teams providing guardrails. Otherwise generated code becomes a responsibility laundering machine. The model wrote it. The reviewer skimmed it. The service owner inherited it. The incident team discovers it.
2. Shadow software gets more convincing
Shadow IT used to be easier to spot. Now it can look polished.
A vibe-coded internal tool may have a decent UI, working auth against a test account, a database schema, and enough functionality to become useful. That does not mean it has logging, least privilege, data retention, secrets management, dependency review, audit trails, or an owner who will patch it next quarter.
The danger is not that the app is obviously bad. The danger is that it is good enough to spread.
3. Prototype defaults become production defaults
Prototypes optimize for proof. Production systems need failure handling, abuse cases, permissions, observability, data boundaries, and rollback.
Vibe coding compresses the prototype phase. That means teams need a deliberate moment where they stop asking “does it work?” and start asking “what happens when this is trusted?”
4. Sensitive context leaks during creation
The code is only half the story. The prompt history may contain stack traces, schema details, customer examples, internal logs, credentials, or source snippets.
If people are building software by conversation, the conversation becomes part of the security surface.
5. Review debt compounds
Every generated branch that lands without real review creates debt. Not because AI code is automatically worse, but because the reviewer may not have the same confidence in the author’s intent, understanding, or design process.
At scale, this becomes a queue of plausible code nobody has deeply owned.
A production eligibility gate
The most useful vibe coding control is not a ban. It is a graduation gate.
Before a vibe-coded prototype becomes production software, require evidence for five questions.
Owner: Which team owns the code, dependencies, data, alerts, and future patches?
Data: What customer, employee, source, secret, or operational data does it read, store, log, prompt, or export?
Access: Who can use it, who approves access, and what prevents cross-tenant or over-privileged behavior?
Dependencies: What packages, APIs, models, and services does it rely on, and are they approved for this use?
Review: What security-sensitive paths were reviewed, and which negative tests prove the key controls?
If a prototype cannot answer those questions, it is not production-ready. It may still be useful. It is just not ready to carry real blast radius.
A lightweight policy people might actually follow
If the policy is “no AI,” people will route around it. If the policy is “anything goes,” security will learn about the software after it matters.
A workable policy sounds more like this:
Use approved AI tools. Do not paste secrets, customer data, production logs, or restricted source into unapproved systems. You are responsible for generated code you merge. AI-assisted changes touching sensitive paths need additional review. New dependencies need justification. Production code must follow the same engineering and AppSec standards regardless of how it was created.
That policy is short enough to remember and concrete enough to automate.
Questions for the next buying committee
When evaluating platforms, internal workflows, or AI coding rollouts, ask questions that expose whether the organization can govern the speed it is creating.
Can we tell which generated changes touched sensitive code paths? Can we route those changes to the right reviewer before merge? Can we detect when a prototype starts depending on real customer data? Can we prevent secrets and restricted context from entering AI tools? Can we see new dependencies introduced by generated work? Can developers get security feedback without waiting days for AppSec? Can AppSec tune the workflow when it gets noisy?
If the answer to those questions is no, the risk is not theoretical. It is just waiting for adoption.
Questions leaders ask
Is vibe coding safe?
It can be, when the resulting software goes through the same ownership, review, data, dependency, and production readiness gates as other software. It is unsafe when prototypes silently become dependencies.
Should AppSec block vibe coding?
Usually no. Blocking the practice outright is brittle. AppSec should focus on approved tools, sensitive data rules, production gates, and pre-merge review for risky changes.
Who owns vibe-coded software?
The team that chooses to merge, deploy, or rely on it should be accountable for it. AI assistance does not remove ownership.
What is the first guardrail to add?
Create visibility around AI-assisted pull requests and prototypes that touch sensitive systems. You cannot govern what you cannot see.
The practical stance
Vibe coding is not going away because it satisfies a real business hunger: speed from idea to artifact.
Security teams should not try to shame that hunger out of the company. They should make sure the company can see what it is building, decide what is allowed to reach production, and assign ownership before something becomes critical.
For more on reviewing the code that comes out of these workflows, read AI Code Security: The Real Risk of AI-Generated Code Is Plausibility. If you want those guardrails in the development workflow, request an Enclave demo.
Let teams move fast. Just do not let production become the first place security learns what they built.