AI-Generated Code Security: The Risks Nobody Talks About

We are in the middle of the biggest shift in software development since open source. AI code assistants — Cursor, Copilot, Bolt.new, Lovable, v0 — are rewriting how software gets built. Developers are shipping full applications in hours instead of weeks. The productivity gains are real and extraordinary.

But there is a problem that the industry is not talking about loudly enough: the code these tools generate is often insecure. Not sometimes. Not in edge cases. Consistently, across tools, across languages, across frameworks.

A landmark study from Stanford University (Perry et al., 2024) found that developers using AI code assistants produced significantly less secure code than those writing manually, with approximately 45% of AI-assisted code containing vulnerabilities. Even more concerning: the developers using AI tools were more confident that their code was secure, even when it was not.

The Scale of the Problem

To understand why this matters, consider the numbers:

Connect the dots: 76% of developers are now using AI tools that produce vulnerable code 45% of the time, and the average breach costs $4.88 million and takes 258 days to detect. The attack surface of the software industry is expanding faster than its defenses.

Why LLMs Generate Insecure Code

AI coding tools are not malicious. They are not trying to generate vulnerable code. The problem is structural, rooted in how large language models are trained and how they interpret prompts.

Training Data Reflects Reality

LLMs are trained on vast repositories of open-source code from GitHub, Stack Overflow, and other sources. The uncomfortable truth is that most of this code was not written with security in mind. Tutorial code skips error handling. Stack Overflow answers solve the functional problem without addressing security. Open-source projects often defer security hardening.

The model learns from what it sees, and what it sees is predominantly code that prioritizes making things work over making them secure.

Functional Optimization vs. Security

When you ask Cursor to “create a user profile API,” it generates code that creates a user profile API. It does not add rate limiting. It does not add input validation. It does not add authorization checks. Because you did not ask for those things.

LLMs optimize for the stated objective. Security is almost never the stated objective. The developer says “build a todo app with authentication,” and the LLM generates a todo app where users can log in — but it does not verify that User A cannot access User B's todos.

Context Window Limitations

Security is fundamentally a cross-cutting concern. Authentication needs to be consistent across dozens of files. Secret management has to work across environments. Input validation must happen at every boundary. LLMs generate code one file, one function, one block at a time. They cannot maintain a holistic security posture across an entire codebase the way a senior security engineer would.

The Five Categories of AI Code Vulnerabilities

Across our analysis of hundreds of AI-generated applications, vulnerabilities consistently fall into five categories. These map directly to the OWASP Top 10.

// AI-generated: SQL injection vulnerability
const results = await db.$queryRawUnsafe(
  `SELECT * FROM users WHERE email = '${req.body.email}'`
);

// AI-generated: XSS vulnerability
<div dangerouslySetInnerHTML={{ __html: userComment }} />

// AI-generated: missing auth check
export async function GET(req, { params }) {
  // No session check - anyone can access any user's data
  const data = await db.document.findUnique({
    where: { id: params.id },
  });
  return Response.json(data);
}

// AI-generated: hardcoded JWT secret
const token = jwt.sign(payload, "my-super-secret-key-123");

// AI-generated: secret in client env var
const stripe = new Stripe(
  import.meta.env.VITE_STRIPE_SECRET_KEY // Exposed in browser!
);

// AI-generated: no validation
router.post("/users", async (req, res) => {
  // req.body goes straight to the database
  // No type checking, no length limits, no sanitization
  const user = await db.user.create({ data: req.body });
  res.json(user);
});

// AI-generated: overly permissive CORS
app.use(cors({ origin: "*" })); // Allows requests from ANY domain

// AI-generated: verbose error exposure
app.use((err, req, res, next) => {
  res.status(500).json({
    error: err.message,
    stack: err.stack, // Exposes internals to attackers
  });
});

The Confidence Gap: Why Developers Miss These Bugs

Perhaps the most alarming finding from the Stanford study is not that AI generates insecure code, but that developers who use AI tools are more confidenttheir code is secure — even when it is not. The researchers called this the “confidence gap.”

This makes intuitive sense. When you write code by hand, you are acutely aware of what you do not know. When an AI writes code for you, it looks professional, it compiles, it passes basic tests. There is an implicit trust: surely a tool trained on millions of repositories knows what it is doing.

But the tool is not making security decisions. It is making pattern-matching decisions. It produces the most statistically likely code given your prompt. And the most likely code is not the most secure code.

The Vibe Coding Problem

“Vibe coding” — using AI to build apps by describing what you want in natural language — has lowered the barrier to building software. This is good: more people can build more things. But it has also lowered the security bar.

Tools like Lovable, Bolt.new, and Cursor enable people without security expertise to build and deploy full-stack applications. The code works. Users can sign up, create data, and use the app. But the security holes are invisible to someone who does not know to look for them.

This is not a criticism of vibe coding. It is a recognition that the tooling needs to evolve. Just as CI/CD pipelines include automated testing, they need to include automated security scanning for AI-generated code.

What You Can Do About It

The solution is not to stop using AI coding tools. They are too valuable. The solution is to add a security verification step between generation and deployment.

The Future of AI Code Security

AI code generation is not going away. It is going to get better, faster, and more widely adopted. The question is not whether we use AI to write code. The question is whether we build the security infrastructure to match the speed of AI development.

We believe the future looks like this: AI writes the code, automated scanners verify it, and humans make the final security decisions. This is the same pattern that already exists in other domains. AI generates medical diagnoses, but doctors verify. AI drafts legal documents, but lawyers review. AI writes code, but security tools and human reviewers must validate it.

ShipSafe exists to close this gap. We built it specifically for the era of AI-generated code — fast scanning, focused on the vulnerability patterns that LLMs produce, with actionable fix recommendations that developers can implement immediately.

Conclusion

AI-generated code is transforming software development. It is also introducing security vulnerabilities at an unprecedented scale. The Stanford data, our own research, and the growing number of breach reports all point to the same conclusion: AI code needs automated security verification.

The developers and teams who recognize this early and build security checks into their AI-assisted workflow will ship faster and more securely than those who either reject AI tools or trust them blindly. The choice is not between speed and security. It is between thoughtful adoption and reckless deployment.