malprompt
Back to docs

How scanning works

From a public URL to a published report: fetching, triage, analysis, scoring, and the human review before anything goes live.

A scan turns a public URL into a report someone can read. Five steps, and a person at the end of them.

1. You submit a link

We check the link before we touch the network: it has to be https, it has to be a host we support (GitHub, Bitbucket or Pastebin), and it can't be a URL shortener or a lookalike domain. Then we canonicalize it, so github.com/Owner/Repo/ and github.com/owner/repo are the same target and share the same history.

If someone scanned the same target in the last day, we attach your submission to that scan instead of running it again. You get the fresh result immediately.

2. We fetch the content

We read the repository or paste through the public API — the same way anyone could. There are hard limits on how many files we read and how big they can be, and requests can't be pointed at private networks.

What we fetch is stored as evidence: the file path, a hash of the content, and the bytes themselves. It is never executed, installed, or rendered as code. Nothing we download is treated as an instruction to anyone, human or machine.

3. Triage

A quick, cheap pass over each file asks one question: is there anything here that looks like it's talking to an AI assistant rather than to a person? Deterministic checks run alongside it, looking for the mechanical signs — invisible characters, base64 blobs, instruction-shaped text in files an agent reads automatically.

Most files are ordinary code and stop here. That keeps a scan affordable, which keeps the service free.

4. Analysis

Anything that survives triage goes to the careful pass, which decides what the content actually tries to do: which technique it uses, what its intent is, and where it lives — a README reads differently from an agent config file.

Two rules govern that model call. It has no tools — it cannot fetch, write, or run anything, so instructions inside the content have nothing to act on. And its answer must arrive in a fixed shape with a marker we planted; if the marker is missing or the shape is wrong, we assume the content got to the model and send the whole thing to a human instead of publishing it.

The model classifies. It never decides the score.

5. Scoring

The score is arithmetic we control, not a number the model picks. It starts from the technique, then adjusts for intent, for where the content sits, for whether it's still public, and for how many people are likely to run into it. The result is 0–100 and maps onto the five severity levels — the severity guide shows the whole calculation.

6. A person reviews it

Nothing publishes itself. A reviewer reads the findings, the evidence and the score, and decides whether it goes on the Wall. They can edit an explanation, change a finding's severity, remove a finding, or reject the report entirely. That's why a scan takes minutes rather than seconds.

Once it's published, the report gets a page, a place on the Wall, and an entry in the feeds. We re-check the target afterwards to see whether the content is still public, and the report says which.

What we never do

  • Run, install, or evaluate anything we fetch.
  • Follow instructions found in fetched content, wherever they appear to come from.
  • Publish the original bytes. Public excerpts are defanged: links broken, invisible characters shown as markers, length capped.
  • Scan anything that isn't already public.