On January 28, 2026, a social network for AI agents called Moltbook opened to the public. Its founder made one thing clear from the start: he had not written a single line of code. The entire application was built with AI coding tools.
Three days later, security researchers at Wiz found a misconfigured Supabase database. No Row Level Security. The API key sat in client-side JavaScript. Full read and write access to everything.
The result: 1.5 million API authentication tokens exposed. 35,000 email addresses. Private messages between agents. The kind of breach that normally takes months or years to discover happened before the product had been live for a week.
Moltbook is not an isolated case. It is a preview of what happens when AI-generated code reaches production without security review. And the data says it is happening at scale.
The Numbers Are Getting Worse, Not Better
Georgia Tech's Systems Software and Security Lab launched the Vibe Security Radar in May 2025. The project tracks CVEs — publicly registered software vulnerabilities — that can be traced back to AI-generated code.
The trajectory is steep. January 2026: six CVEs. February: fifteen. March: thirty-five. The breakdown for March alone: twenty-seven attributed to Claude Code, four to GitHub Copilot, two to Devin, one each to Aether and Cursor.
The researchers estimate they catch only 10 to 20 percent of what actually exists. The real number could be 400 to 700 CVEs across the open source ecosystem in a single month.
The industry data confirms the pattern. Veracode tested over 100 large language models across Java, JavaScript, Python, and C#. Forty-five percent of AI-generated code failed security tests. For cross-site scripting specifically, models failed 86 percent of the time. For log injection, 88 percent.
Aikido Security's 2026 report surveyed 450 developers and security leaders. Sixty-nine percent had discovered vulnerabilities introduced by AI-generated code. One in five reported incidents that caused material business impact. US organizations were hit hardest: 43 percent reported serious incidents, compared to 20 percent in Europe.
This is not a theoretical risk. These are production systems, real users, real data.
What We Actually Find
We are in an unusual position. We build with AI coding tools every day — Claude Code, Cursor, the full stack. We also pentest applications that were built the same way, through our work at IJONIS and our security product DeepMantis. The same patterns appear again and again.
Hardcoded Secrets in Client-Side Code
This was the Moltbook failure, and it is the single most common issue we encounter. AI models generate functional code that connects to databases, APIs, and third-party services. The code works. It also embeds credentials directly in files that ship to the browser.
The problem is not that AI tools do not know about environment variables. If you ask specifically, they will use them. But during a vibe coding session — where the developer accepts suggestion after suggestion without reviewing each one — the model defaults to whatever gets the code running fastest. Often that means hardcoding the connection string.
The Moltbook Pattern
Supabase publishes a "publishable" API key that is safe to expose — but only when Row Level Security is enabled. AI tools regularly generate Supabase integrations that use the key without configuring RLS. The result: full database access from any browser.
Missing or Broken Authentication
We regularly find applications where entire API routes have no authentication at all. The AI generated the route, connected it to the database, and returned data to the frontend. Nobody asked it to add auth middleware, so it did not.
In one assessment, we found 14 unauthenticated API endpoints in a single application. Not obscure admin routes — core business logic. User data, payment records, internal documents. The developer had tested the app while logged in and everything worked. The AI never added the guards, and the developer never noticed they were missing.
SQL Injection in Unexpected Places
Traditional scanners test parameter values for injection. AI-generated code often introduces injection vectors in places scanners do not check: JSON keys, header values, file names, query ordering parameters.
The McKinsey Lilli breach — which we covered in depth in our previous post on AI agent pentesting — was exactly this pattern. The SQL injection was in JSON field names, not values. An AI agent found it in two hours. Traditional scanners had missed it for over two years.
Overly Permissive Database Configurations
AI tools optimize for getting the application running. When database permissions cause errors, the model's instinct is to broaden access until the errors stop. We find databases where the application user has full admin privileges, tables with no row-level policies, and storage buckets set to public by default.
Dependency Confusion
AI models suggest packages by name. Sometimes those names are close to, but not exactly, a real package. Sometimes the package exists but has been abandoned or compromised. The model has no way to verify package integrity, check for known vulnerabilities, or assess whether a dependency is actively maintained.
Why AI Code Is Structurally Vulnerable
These are not random bugs. There is a structural reason AI-generated code tends toward insecurity, and it comes down to how the models were trained and how they are used.
Training Data Bias
Language models learn from public code. The majority of public code — tutorials, Stack Overflow answers, getting-started guides, example repositories — prioritizes clarity and simplicity over security. The code that teaches you how to connect to a database does not include rate limiting, input sanitization, or least-privilege access. It shows the happy path.
When you vibe-code, you get code that looks like tutorial code. Because it was trained on tutorial code.
No Threat Model
A security-conscious developer writes code with an adversary in mind. What happens if this input is malicious? What if this user is not who they claim to be? What if this request is replayed?
AI models have no threat model. They generate code that fulfills the functional requirement described in the prompt. Security is orthogonal to function, and unless the prompt explicitly demands it, the model will not add it unprompted.
The Review Gap
The entire premise of vibe coding is speed. You describe what you want, the AI generates it, you accept and move on. The more you review, the slower you go — which defeats the purpose.
This creates a systematic review gap. In traditional development, code review catches a significant percentage of security issues before they reach production. In vibe coding workflows, the review step is exactly what gets skipped.
The Tools Themselves Are Targets
The security problem extends beyond the code that AI tools generate. The tools themselves have become attack surfaces.
In 2025, a vulnerability in Claude Code (CVE-2025-55284) allowed data exfiltration from a developer's machine through DNS requests. Researchers at AIM Security disclosed a remote code execution flaw in Cursor that required zero user interaction. OX Security found critical vulnerabilities in VS Code, Cursor, and Windsurf that could allow data exfiltration.
Supply Chain Risk
A compromised AI coding tool does not just affect one file. It sits in the developer's environment with access to the entire codebase, environment variables, SSH keys, and cloud credentials. One exploit has the blast radius of a full workstation compromise.
This is the uncomfortable truth about the current vibe coding ecosystem: the tools that generate insecure code are themselves insecure. The attack surface is compounding.
What to Do About It
We are not arguing against AI-assisted development. We use it every day. The issue is not the tools — it is the workflow. Here is what actually works, based on what we see in assessments.
1. Treat AI Code Like Junior Developer Code
Every line gets reviewed. Not skimmed — reviewed. If you would not let an intern push directly to production, do not let an AI tool do it either. This sounds obvious, but it is the single highest-impact change most teams can make.
2. Run Security Scanning on Every Commit
Static analysis, secret detection, and dependency auditing should run automatically on every commit. Not quarterly, not before release — on every commit. Tools like Semgrep, Snyk, and GitHub's own secret scanning catch a significant percentage of the issues we find manually.
3. Pentest Before Launch, Not After the Breach
If your application was built with AI tools — even partially — get it tested by someone who understands AI-specific vulnerability patterns. Traditional pentests check traditional attack surfaces. AI-generated code introduces vectors that traditional testers may not look for. Autonomous pentesting tools can speed up this process — our comparison of six platforms shows which tools fit fast-shipping teams.
4. Lock Down Your AI Tool Environment
Review what your AI coding tools have access to. Do they need your production database credentials? Your cloud provider keys? Your SSH config? Apply least privilege to your development environment, not just your production infrastructure.
5. Enable Security Guardrails in Your AI Tools
Most AI coding tools now support project-level configuration files (CLAUDE.md, .cursorrules, and similar). Use them. Define security requirements explicitly: require environment variables for secrets, enforce authentication on all routes, demand input validation at boundaries. The AI will follow instructions it is given.
The Regulatory Clock Is Ticking
The EU AI Act is already in effect. While it primarily targets AI systems rather than AI-generated code, the direction is clear: accountability for AI outputs is expanding. If your AI-generated application processes personal data and a breach occurs because of a vulnerability the AI introduced, GDPR liability does not care whether a human or a model wrote the code.
Insurance carriers are starting to ask about AI tool usage in their cyber liability questionnaires. The question is no longer whether you use AI to write code. It is whether you have controls around how that code gets into production.
The Moltbook breach took three days. The Georgia Tech CVE count is doubling month over month. One in five breaches now traces back to AI-written code. The reckoning is not coming. It is here.
We build with AI and we break what AI builds. If you are shipping a vibe-coded product and want to know where the holes are before someone else finds them, get in touch.
