How Aevral hunts

People ask "how does Aevral work?" in two ways: what the product does (that is What a scan looks like), and how the security review actually reaches its findings. This page is the second question: the scan method, and the shape of the instruction the detection pass receives. It is documentation, published on purpose. The excerpt below is abridged and paraphrased, not the engine prompt.

What is public, and what is not

Published documentation is not an open-source product. Nothing on this page carries a license to rebuild the engine, and the private parts exist so that measured recall keeps meaning something.

Why one method, not one prompt

A whole-repository read does not fit in one context, and a single-pass read hides cross-file flows. The published method steps on the transparency page list the mechanics; here is the reasoning behind them:

• One context per finding. A finding is only published if the model can quote it from the exact files it saw. Grounding is not a filter applied later; it is a property of how each read is built.
• Whole files, grouped by trust edges. Files are clustered along mechanical edges (location, imports, route registrations, server entry points) so that a read sees the components of one flow together, not fragments of several.
• Cross-batch flows are candidates first. When a flow seems to continue into files outside the batch, it becomes a hint, never a published finding. A stitched read then reunites the entry and the sink so the trace can be proven. If a hint cannot be resolved, the scan says incomplete rather than guessing.
• The model never decides what reaches you. Merging and deduplication are mechanical. No model adjudicates a finding into or out of the report.
• Refutation is part of the job. The detection pass is instructed to attack its own findings before publishing them. Under uncertainty it stays silent, and silence is treated as a correct outcome, not a failure.

The pass instruction (abridged and paraphrased, not the engine prompt)

The detection pass of a whole-repo scan runs under an instruction of this intent:

You read one batch of a repository snapshot frozen at a known commit.
Your single job: prove that an attacker can reach something they should
not, through broken authorization, IDOR, or abuse of the application's
own business logic.

A finding exists only if you can trace it end to end in the code in
front of you: where an attacker enters, which check is missing, and
where the damage lands. Quote the code for every step. If you cannot
quote it, you cannot publish it.

Before you publish anything, try to kill it. Look for the guard you may
have missed earlier in the chain and dismiss your own finding when you
find one. Under uncertainty, dismiss. An empty result is the expected
outcome for most batches.

What the excerpt deliberately leaves out: the response schema and field names the engine expects, everything the pass is told to ignore, and anything that would help reconstruct the corpus or the judge. Those stay private.

What this means for your review

Every published finding arrives as a lead with evidence: the class, the location, the quoted code, and a fix prompt you hand to your own coding agent (Claude Code, Cursor, or Codex). A human decides what to change. Start with What a scan looks like, and read the transparency report for the versioned evaluation matrix and the reproduction protocol.