Vibe coding — the practice of writing software by describing what you want to an AI assistant and accepting its output with minimal review — has become one of the most divisive topics in software engineering. Developers ship faster than ever. But the speed comes with a cost: AI-generated code can introduce subtle security vulnerabilities, logic errors, and supply-chain risks that no type checker or linter will catch.
This article is a practical, evidence-backed guide for developers who use AI coding agents (Cursor, Copilot, Claude, Gemini, and others) but don’t want to ship vulnerabilities alongside their features. You’ll get a concrete review framework, real examples of what goes wrong, and a checklist you can use on your next AI-assisted PR.
What is vibe coding?
The term „vibe coding” was popularized in early 2025 to describe a workflow where a developer prompts an AI model, reviews the output holistically („does this look right?”), and merges it with little or no line-by-line scrutiny. It’s the coding equivalent of skimming a document instead of reading it.
In practice, vibe coding looks like this:
- Describing a feature in natural language and accepting the generated code
- Running the test suite, seeing green, and merging
- Reviewing the diff for obvious issues but skipping edge cases
- Trusting the AI because „it’s been right before”
The problem isn’t the AI — it’s the review gap. When you write code yourself, you understand every line. When an AI writes code, you see the result but not the reasoning. This asymmetry is where bugs and security issues hide.
Why vibe coding creates unique security risks
AI-generated code isn’t inherently less secure than human-written code. The risk comes from three specific properties:
1. Plausibility without correctness
Large language models produce code that looks correct. Function names are reasonable, imports match, the structure follows conventions. But the implementation can contain:
- Hardcoded secrets that the model saw in training data
- Missing authorization checks because the model didn’t infer the permission model
- Incorrect error handling that swallows exceptions instead of propagating them
- Subtle data leaks where sensitive fields are serialized into responses
Example: An AI agent adds a „user profile” endpoint. It correctly validates the input, checks authentication, and returns user data. But it also includes the user’s password_hash and internal_id in the response JSON because the model saw those fields in similar endpoints during training.
2. Dependency hallucination
AI coding agents sometimes suggest packages that don’t exist, or reference packages that exist but have been compromised. A 2026 study from the University of Texas found that approximately 15% of package suggestions from popular AI coding assistants pointed to packages with known vulnerabilities or that didn’t exist at all.
This creates two risks:
- Typosquatting vectors: If you install a hallucinated package name, an attacker can squat it
- Known-vulnerable dependencies: The AI may suggest an old version with published CVEs
3. Configuration drift
When you vibe-code infrastructure, CI/CD pipelines, or deployment configs, small mistakes compound. An AI might generate a Dockerfile that runs as root, a CI workflow that exposes secrets in logs, or a CORS configuration that allows any origin. Each change looks minor in isolation, but they create a widening attack surface over time.
The 6-point vibe coding security review
Before you merge AI-generated code, run through this checklist. It takes 5–15 minutes and catches the most common AI-generated vulnerabilities.
✅ Point 1: Scope check — Does the diff do only what was intended?
What to look for:
- Extra files changed beyond the feature scope
- New dependencies that weren’t discussed
- Database migrations that add columns or tables unrelated to the feature
- Environment variable changes
Quick test: Look at the file list in the PR. If there are files you didn’t expect to change, investigate each one.
Why this matters for vibe coding: AI agents often make „helpful” changes beyond what you asked for — adding logging, updating configs, or modifying unrelated modules. Each extra change is a potential bug vector.
✅ Point 2: Secret scan — Does the diff contain any credentials or keys?
What to look for:
- Hardcoded API keys, tokens, passwords
- Connection strings with embedded credentials
- Private keys, certificates, or auth headers
- Base64-encoded strings that decode to credentials
Quick test: Run git diff | grep -iE '(api_key|secret|password|token|credential|auth.*=)' on the PR. Better yet, use a secret scanner like trufflehog or gitleaks.
Why this matters for vibe coding: AI models trained on public codebases have seen thousands of examples of hardcoded secrets. They replicate this pattern because it „works” — but it’s a critical security violation.
✅ Point 3: Input validation — Are all user inputs validated and sanitized?
What to look for:
- Parameters taken directly from request objects without validation
- SQL queries built by string concatenation
- File paths constructed from user input without path traversal checks
- Missing type checks on API parameters
Quick test: In the diff, find every variable that comes from user input. Trace its path. Does it hit a database query, file system, or command execution without validation?
Why this matters for vibe coding: AI agents often „simplify” by removing validation code they see as redundant, or they generate input handling based on the happy path without considering malicious inputs.
✅ Point 4: Authorization and data exposure — Are access controls correct?
What to look for:
- Endpoints that return more data than the requesting user should see
- Missing ownership checks (can user A access user B’s resource?)
- Admin functions without role checks
- API responses that include sensitive fields
Quick test: For each new endpoint or function, ask: „What prevents an unauthorized user from accessing this?” If the answer is „nothing” or „it’s assumed,” it needs a fix.
Why this matters for vibe coding: AI models generate code that follows the pattern they’ve seen most — which is often the simplest version without authorization layers. They don’t know your application’s permission model.
✅ Point 5: Dependency safety — Are new dependencies real, maintained, and secure?
What to look for:
- New packages in requirements.txt, package.json, or Cargo.toml
- Packages with few stars, no recent updates, or unknown maintainers
- Packages that are obvious typosquatting attempts
- Version pins that reference known CVEs
Quick test: For each new dependency, verify: (1) it exists on the package registry, (2) it has a reasonable number of users/stars, (3) its latest version has no known critical CVEs, and (4) the package name isn’t a typo of a popular package.
Why this matters for vibe coding: As discussed above, AI agents sometimes hallucinate packages. Even when the package exists, the AI may pick an outdated version or a package with known vulnerabilities.
✅ Point 6: Error handling and fallbacks — Does the code fail safely?
What to look for:
- Bare
exceptclauses that swallow all errors - Error messages that expose internal state (stack traces, SQL queries)
- Missing timeout or retry logic for external calls
- Default fallthrough behaviors that grant access or continue execution
Quick test: Find every try/except, catch, or error handling block in the diff. Does it log the error? Does it return a safe response? Does it fail closed (deny access) or fail open (allow access)?
Why this matters for vibe coding: AI models frequently generate „happy path” code and add minimal error handling as an afterthought. The resulting error paths are often the weakest security points.
How to use this review in your workflow
The 6-point review fits naturally into existing development workflows:
For solo developers
- Before merging any AI-assisted change, open the full diff
- Run through each of the 6 points (takes 5–15 minutes)
- If anything fails a check, fix it before merging
- Use the 5-Point Solo Developer AI Code Review Checklist for a streamlined version
For teams
- Add the 6-point checklist to your PR template
- Make every reviewer confirm they checked each point
- Automate what you can: secret scanning in CI, dependency auditing in pipeline
- Use the AI Agent Change Risk Audit Kit — Basic for structured review documentation
For CI/CD integration
- Run secret scanners (gitleaks, trufflehog) as a CI gate
- Run dependency audits (npm audit, pip audit, cargo audit) on every PR
- Block PRs that add new dependencies without a security review comment
- See our CI gates for AI-generated code guide for pipeline configuration
5 real patterns where vibe coding goes wrong
Pattern 1: The „just works” endpoint
An AI generates a REST endpoint that passes all tests but has no authentication check. The tests only verify the happy path — authorized access. In production, anyone can hit the endpoint.
Mitigation: For every new endpoint, write at least one test that sends an unauthenticated request and asserts it’s rejected.
Pattern 2: The helpful migration
An AI agent adds a database migration that creates an index on a sensitive column. The migration works, tests pass, but now there’s an index on users.email that enables efficient enumeration attacks.
Mitigation: Review migrations for sensitive data implications. Check whether indexes, columns, or constraints expose data differently than intended.
Pattern 3: The dependency shortcut
An AI suggests a utility package that handles CSV parsing, date formatting, and HTTP requests in one dependency. It’s real, maintained, but it has a known ReDoS vulnerability in the date parser. The AI didn’t mention the CVE.
Mitigation: Always check new dependencies against vulnerability databases (Snyk, GitHub Advisory Database, npm audit). See our supply chain dependency risk guide for a deeper framework.
Pattern 4: The copy-paste config
An AI generates a Docker Compose file based on popular examples. It exposes a database port to 0.0.0.0, runs the application as root, and uses default credentials. This is „how the examples do it,” so it passes the vibe check.
Mitigation: Treat infrastructure code with the same rigor as application code. Use security linters (checkov, tfsec) on Docker and Terraform files.
Pattern 5: The silent data leak
An AI refactors a user serializer to include all model fields. Previously, the response included 5 fields; now it includes 12, including internal_notes and account_status. No test fails because the response still has the expected 5 fields — but it also has 7 unexpected ones.
Mitigation: Use explicit field whitelisting in serializers. Never rely on exclusion lists. See our agentic coding risk review workflow for a structured approach.
Common mistakes when reviewing AI-generated code
- „The tests pass, so it must be fine.” Tests verify behavior, not security. Passing tests confirm the code does what it should — not that it doesn’t do what it shouldn’t.
- „I’ll review it later.” Later means never. Review AI-generated code before merging, not after. The diff only gets harder to review as more changes pile on top.
- „The AI is smarter than me, so I trust it.” AI models are pattern matchers, not security experts. They reproduce the patterns they’ve seen — including insecure ones.
- „It’s just a small change.” Small changes are where the most critical bugs hide. A one-line authorization bypass is more dangerous than a 500-line feature with obvious bugs.
- „We have CI checks, so we’re covered.” CI checks catch known patterns (linting, known CVEs, format issues). They don’t catch logic errors, authorization gaps, or data leaks in new code.
What this review doesn’t cover
This 6-point review catches the most common AI-generated vulnerabilities, but it’s not a complete security audit. It doesn’t cover:
- Race conditions in concurrent code
- Cryptographic implementation errors
- Business logic vulnerabilities (e.g., price manipulation)
- Infrastructure-level attacks (DDoS, network-level exploits)
- Third-party API security assumptions
- Compliance-specific requirements (SOC 2, GDPR, HIPAA)
For teams with compliance requirements or handling sensitive data, consider our AI Agent Change Risk Audit Kit — Pro, which includes advanced review templates, team workflows, and CI integration guides.
Get the complete review kit
The free 6-point checklist above covers the essentials. For structured review documentation, team templates, and CI integration guides, check out:
- Basic Kit ($5) — Pre-merge review checklist, secret scanning guide, dependency audit template, and a one-page review form for solo developers.
- Pro Kit ($19) — Everything in Basic plus team review workflows, CI gate configurations, sample audit reports, agency checklists, and notification templates.
FAQ
Is vibe coding inherently insecure?
No. Vibe coding is a workflow, not a security posture. The risk comes from the review gap — not reviewing AI-generated code with the same rigor you’d apply to human-written code. The 6-point checklist above bridges that gap.
Do I need to review every line of AI-generated code?
You don’t need to rewrite it, but you should understand it. For each change, confirm: (1) it does only what was intended, (2) it doesn’t introduce secrets, (3) inputs are validated, (4) authorization is correct, (5) dependencies are safe, and (6) errors are handled.
What tools help with AI code review?
Automated tools catch known patterns: secret scanners (gitleaks, trufflehog), dependency auditors (npm audit, pip audit), and security linters (semgrep, checkov). But they don’t catch logic errors, authorization gaps, or data leaks. Use them as a first pass, then apply the 6-point review.
How is this different from a regular code review?
AI-generated code has specific risk patterns: plausible-but-incorrect implementations, hardcoded secrets from training data, hallucinated dependencies, and missing authorization because the AI doesn’t know your app’s permission model. The 6-point review targets these AI-specific risks specifically.
Can I use this checklist for non-AI code?
Yes. The 6 points — scope, secrets, inputs, authorization, dependencies, and error handling — are universal security concerns. They’re especially important for AI-generated code, but they apply to any code change.
What if I’m a solo developer without a reviewer?
The checklist is designed for solo use. Before merging, open your diff and walk through each point. If you want a structured form to document your review, the Basic Kit includes a one-page review template.
Related resources
- How to review AI-generated code before you merge it — The foundational review framework
- AI code review checklist for small software teams — Team-specific review patterns
- CI gates for AI-generated code — Automating security checks in your pipeline
- Secret scanning for AI-generated code — Why your diff might be leaking API keys
- Agentic coding risk review workflow — A practical workflow for teams using AI coding agents
- AI coding agents and supply chain dependency risk — How to verify dependencies before merging
- AI Agent Change Risk Audit Kit — Basic — Pre-merge review kit ($5)
- AI Agent Change Risk Audit Kit — Pro — Expanded review kit for teams ($19)
