AI security

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.

Scan a repository All code security

agent/tools.py:41                       high

  Agent tool wiring grants shell access

  tools = [{"name": "run", "fn": subprocess.run}]
                                  ~~~~~~~~~~~~~~

  A model persuaded to call this tool executes
  arbitrary commands. Expose an allowlisted set
  of actions and validate arguments server-side.

  CWE-94 · confidence: potential

What it detects

Prompts built from untrusted input

Severity: Medium

OpenAI- 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: Medium

An 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: High

A 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