A Vibe Coding Security Checklist: Ten Rules for Teams Writing Code with AI

Velocity went up, discipline did not

Vibe coding — describing intent in natural language and letting AI produce the implementation — is no longer a hobbyist experiment. In many teams it now carries a substantial share of the work, from scaffolding to business logic.

The problem is that security processes were designed on the assumption that humans write the code. Humans remember which library they pulled in. Humans get suspicious about unfamiliar dependencies. Humans hesitate before pasting Stack Overflow code. AI does none of this. It emits perfectly plausible-looking code with high confidence, including package names that do not exist, open source fragments carrying their original licenses, and outdated patterns learned from training data.

This is not an argument against AI-assisted coding. Quite the opposite: precisely because it is here to stay and its share will keep growing, the surrounding discipline has to catch up. The ten rules below are organized across five stages of the development flow, and each can be written directly into a team standard.

Stage one: prompting

Rule 1 · Put constraints in the prompt, not in the patch afterwards.

"Write a file upload endpoint" and "write a file upload endpoint using the project's existing validation utilities, no new dependencies, with path handling that prevents directory traversal" produce results that differ by an order of magnitude in quality. Encoding your stack constraints, security requirements and dependency policy into prompt templates is far more efficient than correcting each violation during code review.

Rule 2 · Sensitive context never goes into public models.

Production configuration, real credentials, customer data, unreleased business logic — the moment any of it is pasted into a public chatbot, it has left your control. Teams need explicit data classification: which code domains may use public AI tools, and which require an internally deployed model. The hard part is not technical. It is providing a compliant alternative good enough that developers do not route around it.

Stage two: generation

Rule 3 · Treat AI as a prolific junior engineer, not a senior expert.

A junior engineer's code goes through review. AI-generated code goes through the same review. The difference is throughput — AI produces far faster, so the review mechanism has to be automated. Reading every AI-generated line by hand will exhaust the team long before it catches everything.

Rule 4 · Scan at generation time, not at commit time.

The later a risk surfaces, the more it costs to fix. The ideal shape is real-time detection inside the IDE: as the AI writes a block of code, the security engine has already completed taint analysis, dependency checks and license matching. This is where "shift left" necessarily goes in the AI era — left all the way to the moment of generation.

Stage three: dependency intake

Rule 5 · Maintain a dependency allowlist and let AI choose only from it.

AI picks dependencies based on their popularity in training data, not on your team's stack roadmap, license policy or security baseline. Constraining AI to a governed set of dependencies is far more practical than auditing every library it decides to introduce.

Rule 6 · Defend actively against hallucinated packages.

AI will confidently reference package names that do not exist. Attackers have been systematically registering the names that appear most often — this is slopsquatting. Defense has three layers: verify before install that a package genuinely exists with a plausible release history; run an internal registry mirror with internal-first resolution; require human confirmation for the first installation of any newly introduced dependency.

Rule 7 · Transitive dependencies count too.

One package introduced by AI can drag in dozens of transitive dependencies. They become part of your attack surface and your license obligations just the same, yet they rarely enter anyone's field of view. Full dependency tree resolution and continuous vulnerability matching are table stakes for dependency management in the AI era.

Stage four: review

Rule 8 · Use snippet-level detection to catch reproduced open source.

AI can reproduce open source code from its training data verbatim. Those fragments appear in no dependency manifest, so manifest-only tools cannot see them — but the license obligations they carry are entirely real. Snippet-level fingerprint matching is currently the only way to surface this class of risk, and as the share of AI-generated code rises, that capability moves from nice-to-have to necessary.

Rule 9 · Focus review on business logic, not syntax.

AI-generated code is usually syntactically correct and stylistically consistent, often more so than human code. Where it goes wrong is elsewhere: misreading business rules, incomplete boundary handling, permission checks in the wrong place, error handling that is too permissive. Human reviewers should spend their attention on exactly the judgments machines are bad at, and leave syntax and style to tooling.

Stage five: merge

Rule 10 · Leave a provenance trail.

Which code was AI-generated, by which model, when, and from what prompt — this information becomes critical in three situations: tracing an incident, defending a license dispute, and satisfying compliance audits that may well emerge. The cost is one extra marker at commit time. The benefit is having an answer when someone asks.

Turning ten rules into a gate

Ten rules that live only in a document will not achieve high adoption. What works is encoding them into the flow: prompt templates in the IDE plugin, the dependency allowlist in registry configuration, scanning in the IDE and CI, provenance markers in the commit template — and finally a CI gate that makes the admission decision. Code that fails does not reach the main branch.

AI raised code production by an order of magnitude. Security capability has to move at the same speed. This is not about adding burden to developers; it is about letting them use a powerful tool with confidence.

---

Further reading: The full picture of AI-generated code security risks · AI security entries in our Open Source & SBOM Guide · How CleanCode Security Agent analyzes at the moment of writing