Vibe coding is productive. Anyone who’s used Cursor or Claude Code to knock out a working feature in a fraction of the normal time knows that. The issue isn’t whether it speeds things up — it obviously does. The issue is that the productivity gain often comes with a security debt that doesn’t show up until a CVE lands in your inbox, or a penetration tester flags something embarrassing in a production system.

The numbers from early 2026 are not flattering. Cloud Security Alliance research attributed 35 CVEs in March alone to AI-generated code — up from six in January. Separate analysis found that commits containing AI-generated code double the baseline rate of accidentally committed secrets like API keys and credentials. If you’ve shifted your engineering workflow heavily toward AI-assisted generation without adjusting your security review practices, you’ve likely got vulnerabilities in production that your current tooling isn’t catching.

None of this is an argument against using AI coding tools. It’s an argument for understanding what AI reliably gets wrong, so you can review for it.

The Three Patterns That Keep Showing Up

Improper input validation. AI models are very good at writing code that handles the happy path. They’re less reliably careful about what happens when the input is unexpected, malformed, or deliberately hostile. SQL injection, command injection, path traversal vulnerabilities, and XSS issues frequently show up in AI-generated code precisely because the model generated code that works for normal input and never accounted for the adversarial case. If you ask a model to write a file upload handler, there’s a reasonable chance it won’t include the checks that prevent a user from uploading a file with a .php extension to a directory that executes PHP files.

Over-permissive IAM and access controls. When an AI model generates cloud infrastructure code or security group rules, it often defaults to more permissive settings than necessary because the permissive setting is what makes the code work in the widest range of contexts. An S3 bucket policy generated to make a feature work quickly might allow public read access. An IAM role generated to give a Lambda function access to a specific table might be generated with broad read access across the entire account. The code does what it was asked to do; it just does it with more access than needed.

Hardcoded credentials. This one is almost embarrassingly common, and it’s been a problem with human-written code forever. AI models will helpfully generate working code with example credentials inline, or carry forward patterns they’ve seen in training data where credentials were hardcoded. Even good models sometimes include a password = "example_password" in generated code that’s intended to be replaced but doesn’t get caught. The volume is higher with AI-generated code — more code means more opportunity for this to slip through.

Slopsquatting: The AI-Specific Risk You Might Not Know About

There’s a newer attack vector worth knowing about. AI models sometimes hallucinate package names — generating import statements that reference plausible-sounding packages that don’t actually exist in the real package registry. Attackers have started registering those names on npm, PyPI, and other registries with malicious code inside.

When you run npm install or pip install on the requirements that your AI-generated code listed, you might install a package the AI made up that’s now been claimed by an attacker. This is called slopsquatting, and while it’s not yet at epidemic scale, it’s a genuine risk for codebases that adopt AI-generated dependency lists without verification. The fix is straightforward: check every new package name before installing it, and use a software composition analysis tool that flags packages with unusual characteristics (very new, no legitimate maintainer history, low download count suddenly spiking).

Building Review Gates That Actually Work

The gap between “we use SAST tools” and “we have security review gates that catch AI-generated vulnerabilities” is wider than most teams realise. Static analysis tools like Semgrep, Snyk Code, and CodeQL are genuinely useful, but they’re most effective when configured for the specific patterns that appear in AI-generated code rather than run with default rules.

A few things that make a real difference. First, make secrets scanning a hard gate in CI — not a warning, an actual block. GitHub Advanced Security, GitLab, and standalone tools like Trufflehog and Gitleaks will catch hardcoded credentials before they get merged. There’s no good reason for this to be advisory.

Second, review AI-generated code at the access control and permission level specifically. Make it part of your pull request template: “if this code makes any external calls, creates any cloud resources, or handles any user input, has the permission model been explicitly checked?” That question being on the checklist doesn’t guarantee it gets answered carefully, but it at least makes the oversight deliberate rather than accidental.

Third, consider where you want human-written code as a policy matter, not just a preference. Authentication flows, payment processing, anything that touches PII in sensitive ways — these are areas where the security requirements are specific enough that you want a human who understands the full context making the implementation decisions, with AI as a reference or a draft rather than the author. Writing that down as a team policy is more useful than leaving it to individual judgement on each PR.

The Governance Question

If you’re in a regulated environment — financial services, healthcare, anything under SOC 2 or ISO 27001 — the question of AI-generated code is going to come up in your next audit if it hasn’t already. Auditors are starting to ask about AI code policies, and “we use Cursor and review PRs” is not the same as a documented policy with controls.

The practical minimum is: a written policy stating where AI-generated code is used and where it isn’t, a requirement for all AI-generated code to pass the same SAST gates as human-written code, and logging of what AI tooling was used during development (most modern AI coding tools support this). That’s not onerous, and it’s the foundation you’ll need if the question gets asked formally.

The productivity benefits of vibe coding are real enough that walking away from them is probably not the right answer. But treating AI-generated code as production-ready without specific security review practices to match is how you end up defending a breach to a regulator.