Hi there, my fellow people on the internet. Hope you're doing well and your codebase isn't on fire (yet).
So here's the thing. Over the past year I've been watching something unfold that genuinely worries me. Everyone and their dog is using AI to write code now. Copilot, Cursor, Claude Code, ChatGPT, you name it. Vibe coding is real, and the productivity gains are no joke. I've used these tools myself while building Kira at Offgrid Security, and I'm not about to pretend they aren't useful.
But I've also spent a decade in security, building endpoint protection at Microsoft, securing cloud infrastructure at Atlassian, and now running my own security company. And that lens makes it impossible for me to look at AI-generated code and not ask my favorite question: what can go wrong?
Turns out, a lot.
The Numbers Don't Lie (And They Aren't Pretty)
Veracode recently published its 2025 GenAI Code Security Report after testing code from over 100 large language models. The headline finding? AI-generated code introduced security flaws in 45% of test cases. Not edge cases. Not obscure languages. Common OWASP Top 10 vulnerabilities across Java, Python, JavaScript, and C#.
Java was the worst offender with a 72% security failure rate. Cross-Site Scripting had an 86% failure rate. Let that sink in.
And here's the part that surprised even me: bigger, newer models don't do any better. Security performance has stayed flat even as models have gotten dramatically better at writing code that compiles and runs. They've learned syntax. They haven't learned security.
Apiiro's independent research across Fortune 50 companies backed this up, finding 2.74x more vulnerabilities in AI-generated code compared to human-written code. That's not a rounding error. That's a systemic problem.
Why Does This Keep Happening?
If you think about how LLMs learn to code, it makes total sense. They're trained on massive amounts of publicly available code from GitHub, Stack Overflow, tutorials, blog posts. The thing is, a huge chunk of that code is insecure. Old patterns, missing input validation, hardcoded credentials, SQL queries built with string concatenation. If the training data is full of bad habits, the model will confidently reproduce those bad habits.
The other piece is that LLMs don't understand your threat model. They don't know your application's architecture, your trust boundaries, your authentication flow. When you ask for an API endpoint, the model will happily generate one that accepts input without validation, because you didn't tell it to validate. And honestly, most developers don't include security constraints in their prompts. That's the whole premise of vibe coding: tell the AI what you want, trust it to figure out the how.
The problem is that "the how" often skips the security bits entirely.
I categorize these into three buckets:
The Obvious Stuff - missing input sanitization, SQL injection, XSS. These are the classics that have been plaguing us for two decades and LLMs are very good at reintroducing them because they're overrepresented in training data.
The Subtle Stuff - business logic flaws, missing access controls, race conditions. The code looks correct. It passes basic tests. But it's missing the guardrails that a security-conscious developer would add. This is harder to catch because there's no obvious "bad pattern" to scan for.
The Novel Stuff - hallucinated dependencies (packages that don't exist but an attacker could register), overly complex dependency trees for simple tasks, and the reintroduction of deprecated or known-vulnerable libraries. This one is uniquely AI-flavored and it's growing fast.
So What Do We Do About It?
We need to ensure that we have security measures that scale at the speed and volume of code shipped.
Unlike older security tools that used to run after every build - we need something faster, something earlier in development lifecycle.
Something that can correctly guide AI to write secure code from the inception rather than scanning for mistakes after you got your features working.
Here is one such tool, free for community to try: kira-lite, an MCP (Model Context Protocol) server that plugs directly into your AI-powered development workflow. If you haven't been following the MCP ecosystem, here's the quick version: MCP is a standard protocol that lets AI assistants connect to external tools and data sources. Think of it as giving your AI coding assistant the ability to call out to specialized services while it's working.
The idea behind kira-lite is straightforward. Instead of generating code and hoping for the best, your AI assistant can call kira-lite during the development process to scan for security issues before the code is even written to disk. It sits in the workflow, not after it.
Here's how you'd set it up:
Claude Code:
bash
claude mcp add --scope user kira-lite -- npx -y @offgridsec/kira-lite-mcp
Cursor / Windsurf / Other MCP Clients:
json
{
"kira-lite": {
"command": "npx",
"args": ["-y", "@offgridsec/kira-lite-mcp"]
}
}
No API keys. No accounts. No external servers. One command and you're scanning.
Why MCP and Why Now?
I've been thinking about this a lot. The traditional security tooling model is built around gates and checkpoints. Write code, commit, run CI pipeline, scanner finds issues, developer goes back to fix. It works, but it's slow and creates friction that developers (understandably) resent.
With MCP, the security tool becomes a collaborator rather than a gatekeeper. The AI assistant can proactively check its own work. It can call scan_code before presenting a snippet to you, catch the SQL injection in the Python function or the missing authentication check on the API endpoint, and fix it in the same conversation. No context switch. No waiting for CI. No separate dashboard to check.
With Claude Code, you can even set it up so that every edit is automatically scanned. Drop a CLAUDE.md file in your project that tells Claude to call scan_code before every write operation, and you've essentially got a security co-pilot riding shotgun on every line of AI-generated code.
This isn't a magic bullet. I want to be clear about that. No tool catches everything, and the security landscape for AI-generated code is evolving faster than any single solution can keep up with. But the shift from "scan after the fact" to "scan during generation" is significant. It's the difference between finding the fire after it's spread and catching the spark.
Things I'd Recommend Right Now
Whether you use kira-lite or not, here are some things I'd strongly suggest if your team is using AI coding assistants:
Don't trust, verify. Treat AI-generated code the same way you'd treat code from a new contractor who doesn't know your codebase. Review it. Question it. Don't assume it's handling edge cases or security concerns just because it compiles.
Add security context to your prompts. If you're asking an AI to write an API endpoint, explicitly say "include input validation, authentication checks, and parameterized queries." It won't add these by default.
Automate scanning in the loop. Whether it's through an MCP server like kira-lite, a SAST tool in your CI pipeline, or both, don't ship AI-generated code without automated security analysis. The volume of code being generated is too high for manual review alone.
Watch your dependencies. AI assistants love adding packages. Check that those packages actually exist, are maintained, and don't have known vulnerabilities. Package hallucination is a real attack vector now. Tools like kira-lite's dependency scanner can automatically check your lockfiles against CVE databases, which saves you from manually auditing every npm install your AI assistant decides to run.
Educate your team. The developers using AI tools need to understand that "working code" and "secure code" are not the same thing. This isn't about slowing people down. It's about building awareness so they know what to look for.
The Road Ahead
I genuinely believe AI is going to transform how we build software. But we're in this weird in-between phase where the tools are powerful enough to generate massive amounts of code and not yet smart enough to make that code secure by default.
That gap is where the next wave of security work lives. It's where I'm spending all my time right now, and honestly, it's one of the most interesting problems I've worked on in my career.
If you're working in this space too, or if you're a developer trying to figure out how to use AI tools without accidentally introducing a bunch of CVEs, I'd love to chat. Hit me up on LinkedIn
Will be back soon with more on this topic. There's a lot more to unpack, especially around how agent-based workflows are creating entirely new attack surfaces.
Keep hacking till then ();