Forem: Aditi Bhatnagar

A must read this week

Aditi Bhatnagar — Mon, 04 May 2026 17:01:04 +0000

Aditi Bhatnagar

May 4

We Scanned AI-Built Apps and Found Holes That Would End Companies. Here's What We Found.

#ai #security #vibecoding #mythos

Comments 1

5 min read

We Scanned AI-Built Apps and Found Holes That Would End Companies. Here's What We Found.

Aditi Bhatnagar — Mon, 04 May 2026 16:54:47 +0000

I want to tell you about a bootstrap endpoint.

It was in a production app, live, serving real users. The endpoint existed because an AI assistant had helpfully included it during scaffolding. It returned the application's master authentication token. To anyone who asked. No login required. No API key. No nothing.

One HTTP request and you had every LLM API key, every database password, every third-party credential the app had ever touched. Fourteen secrets, handed over cheerfully by an app that had no idea it was doing anything wrong.

The developer who built this wasn't careless. They were fast. That's the whole point.

How We Got Here

Georgetown's CSET ran the numbers on AI-generated code versus hand-written code. The result was 2.74 times more vulnerabilities. Not a little worse. Nearly three times.

That tracks with what we see. Not because AI is bad at writing code — it's genuinely extraordinary at writing code. But writing code that works and writing code that's secure are two completely different objectives, and AI coding tools are only trained on one of them.

The model doesn't have a threat model. It has never been attacked. It doesn't know what SQL injection feels like from the inside, or why that particular pattern of URL handling becomes a problem the moment someone points it at an internal metadata service. It knows what working code looks like, and it reproduces those patterns at a speed no human can match — including the insecure ones that have been quietly dangerous in codebases for years.

This matters more than it used to because the other side has also gotten faster. Time from CVE to working exploit used to be weeks. With a language model it's now under an hour. The cost to build a targeted attack has dropped 100x. Your attack surface is expanding daily. Check it out.

What's Actually Sitting in Production

We've been scanning AI-built apps. Here's a sample of what we've found this year. Every single one of these teams responded immediately, patched within the same day or same week, and handled disclosure with more professionalism than most companies twice their size. That's worth saying upfront. These are security-conscious teams. The vulnerabilities got in anyway — because that's the nature of AI-generated code at speed, not the nature of the people shipping it.

Cognithor · Critical · CVSS 9.8

The bootstrap endpoint I opened with. Cognithor is an AI assistant with an active user base, and when we reported this they patched it the same day and credited the disclosure in their release notes, SECURITY.md, and commit message. That's the response of a team that takes this seriously.

The vulnerability itself: the app generated a master bearer token at startup. The /api/v1/bootstrap route returned it to any caller. No authentication. Not even a rate limit — that route was explicitly exempted. The API server bound to 0.0.0.0 by default, so any host that could reach the port could retrieve the token. With it you had access to every API key, every database password, the ability to wipe the entire configuration. Everything, one unauthenticated request away.

The AI built authentication that worked perfectly for the frontend. It just also built it for everyone else.

Fixed in v0.78.2. Same day.

LiteLLM · Critical · CVSS 9.0

LiteLLM is the proxy layer many teams use to manage access to language model APIs. Thousands of deployments. When we reported this they moved fast — patched and shipped within the week across two separate releases that addressed both failure points.

The bug was subtle. An org admin hitting POST /user/bulk_update could elevate any user on the entire platform to proxy_admin — full access to all model configurations, API keys, spend data, every tenant — in a single request. The authorization check read organization_id from the raw request body, confirmed it, then handed the payload to a Pydantic model that didn't declare that field. Pydantic silently dropped it. The handler never saw it. The scope constraint vanished between middleware and execution.

The team identified both root causes immediately and addressed them in separate targeted fixes rather than a band-aid patch. That's engineering maturity.

Patched in v1.83.7 and v1.83.8 within the week.

Microsoft VibeVoice · High · CVSS 7.8

Microsoft acknowledged the report promptly and patched the same week. Their response was exactly what responsible disclosure is supposed to look like.

The vulnerability was in VibeVoice's checkpoint conversion script, which called torch.load() without the weights_only=True flag. PyTorch's default deserialization executes arbitrary Python during unpickling. The fix has existed since PyTorch 1.13. The AI wrote the code without it because most torch.load() examples in training data don't include it — a safe pattern that became unsafe at scale.

A crafted model file passed to that script executes whatever the attacker embedded, before any application code runs, before any checks happen. In CI that means secrets, tokens, and internal network access exfiltrated silently during a routine pipeline run.

One parameter. The team knew exactly what to do the moment we showed them.

Patched same week. Credited in the commit.

The Point Isn't That These Teams Made Mistakes

They didn't, really. They built fast, used AI to help them build faster, and ended up with vulnerabilities that no reasonable code review process would have caught. The same vulnerabilities are sitting in hundreds of other codebases right now, in teams that haven't had someone look.

What these teams did right — and why we're naming them — is that they fixed it. Immediately. Professionally. Without drama. Every one of them treated this like the security-conscious organizations they are.

The vulnerability wasn't a character flaw. It was a structural problem with how AI writes code, and it's a problem every team shipping AI-generated code is carrying whether they know it or not.

Why The Old Approach Can't Keep Up

Quarterly pentests are a snapshot. You pay $15k, they examine the codebase as it stood when the engagement started, you get a report two weeks later. Your team shipped daily in between.

One security engineer against ten developers with AI assistants isn't a program. It's a gesture.

Static scanners generate noise. Most teams stop reading them after a few weeks because the signal-to-noise ratio destroys their usefulness as a daily workflow. The findings above would pass most static scans — they require tracing data flow across the whole stack, not pattern matching on individual files.

None of these solutions run at the speed you're actually shipping.

What Kira Does

Kira runs on every commit. Connects to GitHub, GitLab, or Bitbucket in one click, nothing to install.

It traces data flow across your entire codebase looking for real attack paths — the ones where untrusted input travels through several functions and ends up somewhere it shouldn't, where a permission check happens before a parameter that gets modified afterward, where the combination of individually reasonable decisions creates something exploitable.

When it finds something it doesn't ask you to investigate. It shows you whether it's actually exploitable and exactly how. Proof of concept. Reproduction steps you can run yourself.

Findings come out as shareable reports. Clean enough to hand to a customer asking about your security posture or an auditor who wants to see evidence of process.

The findings above all came from Kira. So did a lot of others we haven't written up yet.

One Thing Worth Knowing

Every line your AI writes today is code a security engineer didn't review. That's not a criticism, it's arithmetic. You're moving too fast for manual review to keep up, and that gap is exactly where the vulnerabilities that matter tend to live.

Your first scan is free. No credit card. Connect your repo and see what's actually there.

offgridsec.com

If it comes back clean, great. If it doesn't, you'll be glad you looked before someone else did.

The LiteLLM Supply Chain Attack Just Changed Everything - Here's How to Protect Your AI Stack

Aditi Bhatnagar — Thu, 26 Mar 2026 10:41:52 +0000

TL;DR

On March 24, 2026, the widely-used LiteLLM Python package was compromised in a supply chain attack. Malicious versions stole credentials from tens of thousands of developers. This post breaks down what happened, why AI tooling is uniquely vulnerable, and how MCP-based security tools like kira-lite-mcp can catch these threats before they hit production.

What Happened: The LiteLLM Compromise

Two days ago, the AI development community got a brutal wake-up call.

LiteLLM - the open-source Python library that provides a unified interface across 100+ LLMs (OpenAI, Anthropic, VertexAI, and more) - was hit by a supply chain attack. Versions 1.82.7 and 1.82.8, published directly to PyPI, contained a multi-stage credential stealer targeting SSH keys, cloud provider tokens, Kubernetes secrets, cryptocurrency wallets, and .env files.

The attack was carried out by TeamPCP, a threat group that had been chaining compromises across the open-source ecosystem since late 2025. They gained access to a LiteLLM maintainer's PyPI credentials through a prior compromise of Aqua Security's Trivy scanner - meaning one breach cascaded into another.

Here's a timeline of what went down:

~08:30 UTC - Malicious versions 1.82.7 and 1.82.8 published to PyPI
10:39-16:00 UTC - Compromised packages available for download
~11:25 UTC - PyPI quarantined the packages
By end of day - Versions yanked, credentials rotated, external IR engaged

The payload was embedded in proxy_server.py and, in version 1.82.8, a .pth file (litellm_init.pth) that executed automatically on every Python process startup. Not when you ran your app. Not when you imported litellm. When Python itself started.

If you ran pip install litellm without a pinned version during that window, the malware was already running before your code did.

Why This Matters More Than a Typical Supply Chain Attack

LiteLLM isn't just another package. It sits at the center of the AI stack, acting as a gateway between applications and multiple LLM providers. That means it often has access to:

API keys for OpenAI, Anthropic, Azure, GCP, and other providers
Environment variables with database passwords and service credentials
Kubernetes cluster secrets when deployed as a proxy
CI/CD pipeline tokens when used in automated workflows

According to Wiz, LiteLLM is present in 36% of all cloud environments. That's an astonishing blast radius for a three-hour window of exposure.

The stolen data was encrypted and exfiltrated to a C2 domain designed to look legitimate: models.litellm[.]cloud. The payload also attempted to deploy privileged Kubernetes pods to every node in a cluster, giving the attackers persistent access even after the initial malware was removed.

This wasn't an isolated incident. TeamPCP's campaign has now spanned five ecosystems - GitHub Actions, Docker Hub, npm, Open VSX, and PyPI - with each compromise yielding credentials that unlock the next target.

The Real Problem: We Don't Scan What We Should

Here's the uncomfortable truth: most development teams have zero automated security checks between their AI coding assistant generating code and that code hitting production.

Think about the typical AI-assisted development workflow:

Developer asks an AI assistant to write a function
AI generates code, often pulling in dependencies
Developer reviews it (maybe), copies it, and ships it

At no point in that flow did anyone check whether those dependencies have known vulnerabilities. Nobody verified that the packages the AI suggested actually exist (package hallucination is a real attack vector). And nobody scanned the generated code itself for injection vulnerabilities, hardcoded secrets, or insecure patterns.

The LiteLLM incident makes this painfully clear. If your project had an unpinned litellm dependency and your CI pipeline ran pip install during that three-hour window, you were compromised. Period.

Enter kira-lite-mcp: Security Scanning Inside the AI Loop

This is where tools like @offgridsec/kira-lite-mcp become critical.

kira-lite-mcp is an MCP (Model Context Protocol) server that brings real-time security scanning directly into your AI coding workflow. Instead of scanning after code is written and committed, it scans code as it's being generated - inside the same conversation where your AI assistant is writing it.

What Makes It Different

It runs 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 proprietary codebases or regulated industries, this is non-negotiable.

376 security rules out of the box. It covers OWASP Top 10:2025, OWASP API Security Top 10, and - critically - OWASP LLM Top 10:2025. That last category catches vulnerabilities that traditional scanners completely miss: LLM output passed directly to eval() or exec(), prompt injection patterns, and user input concatenated into prompt templates.

Five 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.
scan_file - scans an existing file and auto-triggers dependency scanning on lockfiles.
scan_diff - compares original vs. modified code and flags only new vulnerabilities.
scan_dependency - checks your lockfiles against CVE databases across 13 formats (npm, PyPI, Go, Maven, crates.io, RubyGems, and more).
scan_project - full project-level scan with configurable severity thresholds.

How This Would Have Helped With LiteLLM

Let's map kira-lite's capabilities directly to the LiteLLM attack scenario:

Dependency scanning catches known-bad versions. If your project's requirements.txt or lockfile pulled in litellm 1.82.7 or 1.82.8 after the CVE was published, kira-lite's dependency scanner would flag it. It checks against live CVE databases, not just a static list - so as advisories are published, your scans pick them up.

Code scanning catches suspicious patterns. The LiteLLM payload used os.system() calls, base64-encoded strings, and network exfiltration patterns. These are exactly the kinds of patterns that SAST rules detect. If an AI assistant generated code that imports from or interacts with a compromised dependency in a suspicious way, scan_code would catch it before it's saved.

Project-level scanning catches transitive risks. Many developers weren't even using LiteLLM directly - it was pulled in as a transitive dependency through AI agent frameworks, MCP servers, or LLM orchestration tools. A full project scan would surface these hidden dependencies.

Setting It Up (It Takes 30 Seconds)

npx @offgridsec/kira-lite-mcp

That's it. Zero config. Works with Claude Code, Claude Desktop, Cursor, VS Code, and any MCP-compatible client.

For Claude Desktop, add to your config:

{
  "mcpServers": {
    "kira-lite": {
      "command": "npx",
      "args": ["-y", "@offgridsec/kira-lite-mcp"]
    }
  }
}

Once configured, your AI assistant can call the security scanning tools automatically - catching vulnerabilities in the same conversation where code is being written.

Broader Lessons From the LiteLLM Incident

The LiteLLM compromise isn't the end of this campaign. As Endor Labs put it: "TeamPCP has demonstrated a consistent pattern: each compromised environment yields credentials that unlock the next target."

Here's what every team building with AI should take away:

1. Pin Your Dependencies

If your requirements.txt says litellm instead of litellm==1.82.6, you were exposed. Pin versions. Use lockfiles. Verify hashes. This is basic supply chain hygiene that too many AI projects skip because they move fast.

2. Treat AI-Generated Code Like Untrusted Code

Your AI assistant doesn't know about zero-day supply chain attacks. It doesn't verify that the packages it suggests are uncompromised. Treat its output the same way you'd treat code from a contractor who doesn't know your security policies.

3. Scan In the Loop, Not After the Fact

The traditional model - write code, commit, CI scans, fix later - doesn't scale when AI is generating code at 10x the speed of manual development. Tools like kira-lite-mcp shift security scanning left of left: into the generation step itself.

4. Watch Your Transitive Dependencies

LiteLLM wasn't just installed directly. It was pulled in by MCP servers, agent frameworks, and orchestration tools. Know your dependency tree. Audit it regularly. Use scan_dependency on every lockfile in your project.

5. Assume Breach, Rotate Fast

If you installed litellm 1.82.7 or 1.82.8, assume every credential on that machine is compromised. SSH keys, cloud tokens, API keys, database passwords, crypto wallets - rotate all of them. Check for persistence mechanisms (~/.config/sysmon/sysmon.py, ~/.config/systemd/user/sysmon.service). In Kubernetes environments, audit kube-system for pods matching node-setup-*.

The Bottom Line

The AI supply chain is now a high-value target. LiteLLM's 3.4 million daily downloads made it an incredibly efficient attack vector - and the attackers knew it.

We can't prevent every supply chain compromise. But we can build security into the development workflow itself, catching vulnerabilities before they become incidents. Tools like kira-lite-mcp represent a fundamental shift: from security as a gate at the end of the pipeline to security as a collaborator sitting next to you while you code.

The LiteLLM incident cost organizations time, trust, and potentially sensitive data. The next supply chain attack - and there will be a next one - doesn't have to.

If you found this useful, give it a like and follow for more on AI security and developer tooling. Have questions about securing your AI development workflow? Drop them in the comments.

Tags: #security #ai #programming #devops

FAQ: LiteLLM Supply Chain Attack and AI Security

What was the LiteLLM supply chain attack?
On March 24, 2026, the LiteLLM Python package on PyPI was compromised by a threat group called TeamPCP. Versions 1.82.7 and 1.82.8 contained credential-stealing malware that targeted SSH keys, cloud tokens, API keys, and Kubernetes secrets. The malicious packages were available for approximately three hours before being removed.

How do I know if I was affected by the LiteLLM attack?
You were likely affected if you ran pip install litellm without a pinned version between 10:39 UTC and 16:00 UTC on March 24, 2026, and received version 1.82.7 or 1.82.8. Run pip show litellm to check your installed version. Users of the official LiteLLM Proxy Docker image were not impacted.

What is kira-lite-mcp?
kira-lite-mcp (@offgridsec/kira-lite-mcp) is an MCP-based security scanner that integrates directly into AI coding assistants like Claude Code, Cursor, and VS Code. It scans code for vulnerabilities, checks dependencies against CVE databases, and detects insecure patterns - all in real-time during the development process, entirely on your local machine.

How does MCP help with security scanning?
MCP (Model Context Protocol) allows AI assistants to invoke external tools contextually. With an MCP security scanner, the AI can proactively check its own generated code for vulnerabilities, scan dependencies for known CVEs, and flag insecure patterns before the code is ever saved to disk.

What should I do if I installed a compromised version of LiteLLM?
Immediately remove the package, purge your pip cache, rotate all credentials that were accessible on the affected machine (SSH keys, cloud tokens, API keys, database passwords), check for persistence mechanisms, and if running in Kubernetes, audit for unauthorized pods. Consider rebuilding affected systems from a known clean state.

Your AI Coding Assistant is Probably Writing Vulnerabilities. Here's How to Catch Them.

Aditi Bhatnagar — Sat, 28 Feb 2026 10:40:47 +0000

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 ();