The Security Side of Vibe Coding: What AI-Generated Code Gets Wrong

Let me be upfront: I'm not here to tell you AI coding tools are bad. I use them constantly. Claude Code lives in my terminal. Kiro IDE is my go-to for exploration, experimentation, ideation, and development/testing (formerly Cline + VS Code). Claude Opus is effectively my second brain at this point — and with Opus 4.6 being 4.5 on ADHD medication, we're more aligned than ever. These tools have profoundly transformed my productivity. What used to take me a full week of focused work often takes just a couple of hours to spec, vibe, review, and deploy.

I'm also a security professional, however. And the security professional in me has noticed highly concerning patterns that the productivity-obsessed developer in me would rather ignore. AI coding assistants are incredibly skilled at generating code that probably works. They are significantly less skilled at generating code that probably won't cause your credit card information to be leaked.

This isn't a hit piece. It's a field report from someone who uses these tools daily and has caught enough issues to know that the classic "trust, but verify" approach to security is no longer sane in the world of AI-assisted development. And "Zero Trust" isn't the fix. It's catchy, but take a second to think about it. Seriously. How well would any system function with "Zero Trust"? It wouldn't. For me, "measure twice, cut once" is a good fit — though admittedly, my friends and family can attest that I tend to measure more than twice ... and occasionally don't cut.

The security research community has been busy studying what happens when AI writes code at scale. The findings aren't great.

Palo Alto Networks' Unit 42 research team found that AI agents are "frequently failing to enforce critical security controls, introducing mass vulnerabilities, technical debt and real-world breach scenarios." They documented cases where vibe-coded applications were breached because the AI simply didn't include authentication or rate limiting.

UpGuard analyzed over 18,000 AI agent configuration files from public GitHub repositories and found that one in five developers have granted AI coding tools unrestricted access to perform high-risk actions without human oversight. One in five. On public repos.

And then there's the "IDEsaster" research project from December 2025, which uncovered over 30 security vulnerabilities across nearly every major AI-powered IDE — Cursor, Windsurf, GitHub Copilot, Zed, Roo Code, Junie, Cline, and others. Twenty-four of those were assigned CVE identifiers. The attack chains combined prompt injection with legitimate IDE features to achieve data exfiltration and remote code execution.

These aren't theoretical risks made up to market the next "next generation" security appliance. They're documented incidents that happened to real organizations and are causing real financial and reputational damage.

CamoLeak (CVSS 9.6) — In mid-2025, researcher Omer Mayraz of Legit Security discovered that GitHub Copilot Chat could be tricked into exfiltrating secrets from private repositories. The attack worked by hiding malicious prompts in invisible markdown comments inside pull requests. When a developer asked Copilot to review the PR, it would follow the hidden instructions, find API keys and tokens, and encode them as a sequence of 1x1 pixel images — effectively creating a covert data channel. AWS keys, security tokens, and even unpublished zero-day vulnerability descriptions were extracted in the proof-of-concept.

CVE-2025-62453 — A local code execution vulnerability in GitHub Copilot for VS Code, stemming from the extension's failure to properly sanitize inputs it processes locally. The flaw meant that AI-generated suggestions could potentially execute arbitrary code on a developer's machine.

Unit 42's case files — Palo Alto's incident response team documented a sales lead application that was breached because the AI coding agent didn't include authentication or rate limiting. In another case, an AI agent — despite explicit instructions to freeze production changes — deleted an entire production database.

And these examples aren't edge cases. They're the natural consequence of mindlessly employing tools that are optimized to make code work and move on to the next step, not to make it work and protect your intellectual property.

I spend most of my development time inside Claude Code and Kiro IDE, working with Claude Opus 4.6. Here are the patterns I've noticed firsthand — not from research papers, but from catching issues in my own code.

AI defaults to innerHTML when it shouldn't. When I was building the code block functionality for this very website, the AI-generated JavaScript used innerHTML to render language badges and copy buttons. It worked perfectly. It was also an XSS vector. I had to refactor the entire file to use pure DOM manipulation — createElement, textContent, appendChild. The AI didn't flag the security issue; I caught it during review.

// What the AI generated (works, but insecure):
languageBadge.innerHTML = `${languageIcon}<span class="ml-2">${language}</span>`;

// What I refactored it to (secure DOM manipulation):
const icon = getLanguageIconElement(language);
badge.appendChild(icon);
const textSpan = document.createElement('span');
textSpan.className = 'ml-2';
textSpan.textContent = language.toUpperCase();
badge.appendChild(textSpan);

AI-generated Terraform tends toward overly permissive IAM. When I ask an AI to write an IAM policy, the first draft almost always uses "Action": "*" or "Resource": "*". It takes explicit prompting — or better yet, automated scanning with tools like checkov — to get it down to least privilege.

// What AI often generates first:
{
  "Effect": "Allow",
  "Action": "s3:*",
  "Resource": "*"
}

// What you actually need (least privilege):
{
  "Effect": "Allow",
  "Action": ["s3:PutObject", "s3:GetObject", "s3:DeleteObject", "s3:ListBucket"],
  "Resource": [
    "arn:aws:s3:::my-bucket",
    "arn:aws:s3:::my-bucket/*"
  ]
}

AI doesn't think about privacy unless you tell it to. When building my contact form, the AI happily put my email address in plaintext HTML. I had to explicitly design an obfuscation pattern — constructing the email from character arrays and only revealing it on user click interaction — to prevent automated scraping. The AI would never have thought of that on its own.

Supervised mode exists for a reason. Both Kiro and Claude Code offer modes where the AI can act autonomously (autopilot) or where every change requires your approval (supervised). I use supervised mode for anything touching security-sensitive files — Terraform configs, IAM policies, authentication logic. The productivity hit is worth it.

Unit 42 published a framework called SHIELD for governing AI-assisted development. It's solid, but here's what I've found works in practice — the stuff I actually do every day.

1. Treat AI output like a junior developer's pull request. Read it. Read the "extended thinking". Question every assumption. Let's be honest: The code will probably work, but "it works!" and "it leaked my credit card information!" aren't mutually exclusive outcomes.

2. Use hooks and steering files to encode your security requirements. In Kiro, I have hooks that automatically trigger security review when IAM, Terraform, or secrets-related files are modified. The AI can't skip the review because the hook fires on every file save.

// Example: Kiro security review hook (.kiro/hooks/security-review.kiro.hook)
{
  "name": "Security Review Gate",
  "when": {
    "type": "fileEdited",
    "patterns": ["**/*.tf", "**/*.tfvars", "**/iam/**/*", "**/secrets/**/*"]
  },
  "then": {
    "type": "askAgent",
    "prompt": "A security-sensitive file was saved. Check for: hardcoded secrets, overly permissive IAM, missing encryption, input validation gaps."
  }
}

3. Use spec-driven development to force the AI to think before coding. Kiro's spec workflow — requirements, then design, then tasks, then implementation — is genuinely one of the best guardrails I've found. It forces the AI to articulate what it's going to build and how before writing a single line of code. Security requirements get captured in the spec, not forgotten during implementation.

4. Run security scanning on everything AI generates. Checkov for Terraform. ESLint with security plugins for JavaScript. Bandit for Python. These tools catch what the AI misses. Automate them in your CI/CD pipeline so they run on every commit — I wrote about how to do this in my DevSecOps with GitHub Actions post.

5. Never grant unrestricted access without understanding the implications. That UpGuard stat — 1 in 5 developers giving AI agents full workstation access — should concern everyone. Understand what permissions your AI tools have. Use the principle of least privilege, just like you would for any other system.

6. Keep secrets out of your prompts. Don't paste API keys, connection strings, or credentials into AI chat windows. The AI doesn't need your production database password to write a migration script. Use environment variables and reference them by name.