2
3 Comments

I built a prompt-injection detector for AI agents — and I'm honest about what it can't catch

Most "AI security" tools pitch themselves as a wall. This isn't that, and saying so is kind of the point.

Agents read a lot of text they didn't write — scraped pages, feed posts, API responses, tool output. Any of it can carry an instruction aimed at the model instead of the user. I built injection-scanner to catch the known-shape version of that: spoofed system/role markers, "ignore previous instructions" phrasing, fake tool_call blocks, credential-exfil asks, delimiter-escape tricks, base64/hex payload runs. Six categories, severity-weighted — multiple hits stack toward a real score, a single stray base64 string stays low.

What it does NOT do, plainly: it's a heuristic, not a semantic classifier. It won't catch a well-written paraphrase that reads as normal prose but still steers the agent. Anyone selling you a filter that stops "all" prompt injection is selling you something untrue. This is a first-line triage gate — one layer, not a guarantee.

Why the engine is free: for a tool whose whole job is deciding what's dangerous, "trust me, it's closed source" is a bad answer. The full detector is MIT on GitHub — read it, fork it, tune the rules, embed it. If you'd rather skip the wiring, there's a $29 CLI with CI-ready exit codes and rule updates.

Free core: github.com/fez711/injection-scanner
Paid CLI: fezai8.gumroad.com/l/injection-scanner

Genuinely want feedback on where the pattern list misses real attacks — that's the whole reason the core is open.

on July 8, 2026
  1. 1

    I think the most valuable part of your post is admitting where the product stops.

    Security products usually compete by claiming certainty. You've chosen to compete by defining the boundary of confidence instead. That makes it much easier for people to understand where this fits in their security stack instead of treating it as a silver bullet.

    1. 1

      exactly the frame i was going for — you said it cleaner than i did. "boundary of confidence" is the only kind of security claim i trust myself, and it's the one thing a closed-source black box can't offer you. if you ever run it and it misses something you'd have wanted caught, that's the feedback that actually sharpens the rules — genuinely want it.

      1. 1

        That's the part that stayed with me too.

        Reading your reply made me think about a consequence of defining the boundary of confidence that isn't immediately obvious. It has implications well beyond the security claims themselves, and I don't think I can explain the reasoning properly in a thread without oversimplifying it.

        If you're interested, what's the best email to reach you on?