Webcuris

Running a scan

AI security

An inventory of the AI components in your code, and 18 rules over how they are wired together.

How to run it

AI security is produced by a repository scan. There is no separate AI scan to start — connect or scan a repository and the AI findings appear alongside the rest.

  1. Open Recon → Scan a repository.
  2. Choose GitHub repository and pick the repo, or use the CLI to scan it on your own machine if the code must not leave your network.
  3. Start the scan and wait for it to finish. Repository scans take longer than website scans because the dependency tree has to be resolved.
  4. Open AI Security in the sidebar. Components are grouped by what they can do — a model client and an agent framework are not comparable risks.
  5. Open Findings and filter by the llm category to see the rule hits on their own.
The AI security page listing detected AI components grouped by capability.
AI Security populates from a repository scan. With no repository scanned, it is empty — that is not an error.

What is inventoried

The scan identifies AI components from the dependency tree first, falling back to import statements at lower confidence. Each is classified by capability rather than by package name.

  • Model clients and provider SDKs — code that sends text to a model and receives text back.
  • Agent frameworks — code that can hold tools and act on the model's output.
  • Vector stores and retrieval — where retrieved content enters a prompt.
  • Assistant configuration and MCP servers — the tools an assistant has been granted, read from the configuration files that declare them.
  • AI-generated code surfaces — commits attributed to an assistant, so review effort can be pointed at them.

The 18 rules, by what goes wrong

The rules are about wiring, not about the model. Every one of them describes a path where untrusted text reaches somewhere it should not, or where the model's output is trusted more than it has earned.

  • Model output reaching something dangerous — passed to eval or exec, reaching a shell, interpolated into a database query, or deserialized. These are the critical ones: the model becomes an execution path.
  • Model output trusted as a decision — used directly as a control-flow branch or an identifier, where a hallucinated value becomes an authorisation.
  • Untrusted input reaching the prompt — request input concatenated into the system prompt, retrieved content placed into a prompt without delimiting, user or retrieved content placed in the system role.
  • Secrets and leakage — a credential interpolated into a prompt, prompts or output written to logs, the system prompt reachable by the client.
  • Isolation — vector search with no tenant filter, conversation memory shared across requests.
  • Agent authority — a tool that performs a destructive action with no approval, a tool exposing unbounded filesystem, shell or network access.
  • Operational — a model call with no output or cost limit, TLS verification disabled on a model or vector-store endpoint, and training or fine-tuning on unvalidated user-supplied data.

What cannot be assessed from source

Several properties belong to a trained model rather than to a repository. They are marked not implemented with the reason rather than left as a silent gap.

  • Adversarial suffix susceptibility — a runtime property of the model. Nothing in a repository indicates it.
  • Model inversion and membership inference risk — properties of trained weights and the data behind them.
  • Whether a managed vector store encrypts at rest — a property of that provider's infrastructure, visible in neither your source nor your agent's behaviour.

What this does not do

Nothing here sends your code, your prompts or your model output to a language model. The analysis is static pattern matching over source you already have.