Find the AI code that trusts its input too much.
Every LLM feature you ship adds a new place where untrusted text becomes an instruction. This scanner reads your repository for the two patterns that cause it: prompts assembled from request data, and agents handed tools they should never have.
What it detects
Prompts built from untrusted input
Severity: MediumOpenAI- and Anthropic-shaped completion calls where message content is assembled by string interpolation or concatenation. That is the prompt-injection analog of SQL injection: interpolated input can override the instructions above it.
Python f-string prompt construction
Severity: MediumAn f-string or .format() call interpolating into a variable that looks like a prompt, system message, or instruction — the most common way user input silently becomes model instruction.
Agents wired to shell or eval
Severity: HighA tool or function definition — the kind an LLM agent can call — sitting next to exec, eval, subprocess, or os.system. If a model can be talked into calling it, that is remote code execution gated only by the model's judgment.
Findings say “worth reviewing”, never “confirmed”.
These are pattern rules, not taint analysis. Every finding is reported at potential confidence, because matching a shape in source is not proof that untrusted input reaches it. You get a precise pointer and the reasoning — the judgment stays yours.
Not active prompt-injection testing
Testing whether a model actually falls for an injected instruction requires a live endpoint and credentials to probe. This scanner reads source code; it never sends prompts to a model.
Not RAG-leakage testing
Determining whether a retrieval pipeline leaks documents across tenants requires exercising that pipeline with real data. Source alone cannot answer it.
Not agent permission analysis
An agent's true permissions come from runtime configuration that varies per deployment. What is visible statically is the wiring, which is what gets flagged.
Runs with every repo scan
No separate pipeline. AI risk is scanned in the same pass as dependencies, secrets, containers, and SAST, and lands in the same finding list.
Tracked like any other finding
An AI finding moves through new, persisting, fixed, and regressed exactly like a dependency CVE, so you can see whether it actually stayed fixed.
Mapped to CWE-94
Code injection, the same classification the industry already uses — so these findings slot into your existing triage instead of needing a separate vocabulary.
Keep reading
Where most people go next
Field notes on AI security
All articles
Before you connect that MCP server, run these three commands
Connecting an AI assistant to a tool takes four seconds and grants a language model your permissions. Three commands, run first, tell you how the server authenticates and whether it follows the specification at all.
An assistant should be able to do less than you. Never more.
Everyone is connecting AI assistants to their tools by pasting an API key that never expires and isn't scoped to anything. Here is the authorization model we built instead, and the six decisions behind it.
Your AI just imported a package that doesn't exist
LLM assistants keep inventing plausible package names. Unclaimed, those names are an attacker's opportunity — slopsquatting is typosquatting's AI-era cousin, and most teams have no check for it.
Point it at the repository shipping your AI features
Free to start. Findings stay in Webcuris’s own database — no third-party backend receives them.