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 their 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?
Here’s where I get to talk about what I’ve been building.
At Offgrid Security, the core problem we’re solving with Kira is: can we use AI to actually catch the security issues that AI introduces? Fight fire with fire, if you will.
We recently released 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:
claude mcp add --scope user kira-lite -- npx -y @offgridsec/kira-lite-mcp
Cursor / Windsurf / Other MCP Clients:
{
"kira-lite": {
"command": "npx",
"args": ["-y", "@offgridsec/kira-lite-mcp"]
}
}
No API keys. No accounts. No external servers. One command and you’re scanning.
What Makes This a One-Stop Solution
I’ve used a lot of security scanners in my career. Most of them do one thing okay. Some catch secrets, some catch injection flaws, some handle dependency vulnerabilities. Kira-lite was built to be the thing you don’t have to supplement with five other tools.
Here’s what ships out of the box:
376 built-in security rules across 15 languages and formats.
We’re not talking about a toy regex scanner here.
This covers JavaScript, TypeScript, Python, Java, Go, C#, PHP, Ruby, C/C++, Shell, Terraform, Dockerfile, Kubernetes YAML, and more. Each language has framework-specific rules too.
Django’s DEBUG=True in production, Spring’s CSRF disabled, Express.js missing helmet middleware, React’s dangerouslySetInnerHTML with unsanitized input. The stuff that generic scanners miss because they don’t understand the framework context.
92 secret detectors.
Not just AWS keys and GitHub tokens. We’re detecting credentials for Anthropic, OpenAI, Groq, HuggingFace, DeepSeek (relevant given the AI coding boom), plus cloud providers like GCP, DigitalOcean, Vercel, Netlify, Fly.io. CI/CD tokens for CircleCI, Buildkite, Terraform Cloud. SaaS tokens for Atlassian, Okta, Auth0, Sentry, Datadog. Payment keys for Stripe, PayPal, Square, Razorpay. The list goes on. If an AI coding assistant hardcodes a credential (and they love doing this), kira-lite will catch it.
Dependency vulnerability scanning across 11 ecosystems.
This one is huge. Kira-lite scans your lockfiles against the OSV.dev database (the same data source behind Google’s osv-scanner) for known CVEs. It supports npm, PyPI, Go, Maven, crates.io, RubyGems, Packagist, NuGet, Pub, and Hex. Thirteen lockfile formats total. Remember what I said about AI assistants introducing too many dependencies? This is how you catch the ones with known vulnerabilities before they become your problem.
Full OWASP coverage.
And I don’t mean “we cover a few items from the Top 10.” Kira-lite maps to OWASP Top 10:2025, OWASP API Security Top 10, and OWASP LLM Top 10:2025. That last one is particularly relevant. It catches things like LLM output being passed directly to eval() or exec(), prompt injection patterns, and user input concatenated into prompt templates. If you’re building AI-powered applications (and who isn’t, these days), these are the vulnerabilities that existing scanners completely ignore.
Five distinct MCP tools that your AI assistant can invoke contextually:
`scan_code scans a snippet before it’s written to disk. The AI literally checks its own work before handing it to you.
scan_file scans an existing file and automatically triggers dependency scanning if it hits a lockfile.
scan_diff compares original vs modified code and reports only new vulnerabilities. This is incredibly useful during refactors where you don’t want noise from pre-existing issues.
scan_dependencies does a full dependency audit on demand.
fix_vulnerability provides remediation guidance for specific vulnerability IDs or CWEs.`
And the scanning happens entirely on your machine. Kira-lite ships with Kira-Core, a compiled Go binary bundled for macOS, Linux, and Windows. Your code never leaves your laptop. For anyone working on proprietary codebases or in regulated industries, that’s not a nice-to-have, it’s a requirement.
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. I’m building an AI security company, so clearly I’m bought in on that future. 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 or check out what we’re building at Offgrid Security.
And if you want to try kira-lite, the package is up on npm: @offgridsec/kira-lite-mcp. One npx command, zero config, and 376 rules scanning your code before it ever hits the filesystem. I think you’ll find it genuinely useful.
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 ();
