AI explanations

An AI explanation turns a security finding into plain language. It is interpretation, never detection.

The contract

The scan decides what is true. The MCP security rules produce the findings, the severities, the score and the grade. The model explains them, and nothing more.

The AI cannot produce a finding. It cannot create, alter, or remove one; it cannot move a score; it cannot change a grade. An explanation writes nothing to a scan or a finding. An AI review saves its opinion beside the findings, in the scan's engine report, and changes nothing else.

A failure changes nothing. If no provider is configured, or a vendor is down, the interface shows a quiet line of text next to a finding that remains entirely valid. The API returns a normal 200 with available: false, deliberately. Returning an error would make an AI outage look like a scanner outage.

It is always labelled. Explanations render in a visually distinct panel marked "AI explanation", carrying the provider and model that produced it. A verified finding and a model's prose are different kinds of claim and are never presentable as the same thing.

Where explanations appear

• On a scan result, next to its grade, as "Why is this grade C?" (or "Explain this result" when the scan could not be graded)
• On an individual finding
• On an agent, next to its safety score, as "Why is this agent high risk?"

All of these are on your own scans and agents. Anyone else asking about the same scan gets a "not found", which does not even confirm the scan exists.

There is no AI button on decorative elements.

AI review of a scan

On a finished scan with findings, the scan page has an AI second look card. Click Run AI review and your own AI provider reads each finding again and gives its opinion:

• AI: likely real: the AI thinks the problem is real.
• AI: maybe not real: the AI thinks it may be a false alarm.
• AI: not sure.

Each comes with a short reason, and the card shows a summary and how many findings got each opinion. Every finding then carries its chip, and the finding page shows the AI's reason in its own card, marked with the provider and model that wrote it.

It is a second opinion, not part of the result. It never changes a finding, a severity, the score or the grade, and it never removes a finding: a finding the AI calls "maybe not real" is still there until you mark it yourself (see Triage).

• Only when you ask. It never runs by itself after a scan. You can run it again; the new opinions replace the old ones. At most 10 reviews an hour.
• Your provider, your key. It uses the AI provider you added under Settings, in your order, trying the next one if one fails. Your key is used by Aevrin's API for that one request and never enters the sandbox the scanned server runs in. Your provider bills you, not Aevrin.
• Untrusted text is fenced. Tool descriptions and evidence come from the scanned code, so they are marked as data and cleaned of anything that looks like a secret before they are sent.
• When it cannot run, the card says why: no provider is set up, or each provider failed. Your scan result is still complete, and nothing is saved.
• What it covers. Up to the first 40 findings of the scan. A scan from before full reports were kept, or one uploaded by an older CLI, cannot be reviewed.

The API route is POST /scans/{id}/ai-review (see API reference).

What the model receives

A structured evidence document, and nothing else. It is not given the repository, the environment, your configuration, or your conversation.

Included: findings (title, severity, OWASP category, file path, line, remediation), the scan's grade and risk score, the target type, and coverage. For an agent: the points it lost and why, what it can reach with the rule that allows each, its rules as written, which kinds of password or key are present (never a value or a location), its skill names, its score, risk level and confidence, and coverage. File paths are left out.

Explanations are written for someone with no security background: short sentences and everyday words, with any technical word explained. The model is told never to state a different grade, score, severity or risk level than the scan did, and never to add, remove or soften a finding.

Excluded, by construction:

• The scanner's raw payload, which can contain a matched credential verbatim.
• Any credential value. Credential metadata carries kind, source and presence, never a value.
• Source code, environment variables, and full file contents.
• Anything matching a credential pattern, in any field. Tokens, keys, JWTs and private-key headers are stripped before the document is built, including from fields that "should not" contain them, which is exactly where secrets keep turning up.

Every free-text field is length-bounded, so a hostile README cannot push the real evidence out of the context window.

Coverage is always stated

If a scan had incomplete coverage, the document says so and the system prompt instructs the model to report unscanned categories as unknown rather than safe.

Without this, a model reading zero findings in a category would explain that the category is clean, which is the precise failure this product exists to prevent.

Prompt injection

MCP tool descriptions and READMEs are attacker-controlled text, and a hostile one can certainly contain instructions. Three things limit what that achieves:

1. The text arrives as a JSON value under a named key, presented as evidence to be explained rather than as instructions to follow.
2. It is length-bounded.
3. The model has no tools, no write access, and no ability to alter a finding. The worst outcome is a misleading paragraph beside a finding that is itself unchanged, which is why the finding, not the explanation, is what the interface treats as authoritative.

Caching

Explanations are cached against a hash of the exact evidence shown to the model.

Two callers whose evidence documents hash identically genuinely are asking the same question, and one answer serves both. Evidence built from a private scan hashes differently, so nothing crosses a tenant boundary. When a rescan changes the evidence the hash changes and the next reader gets a fresh explanation; there is nothing to invalidate by hand.

A forced rescan additionally clears cached explanations for that subject.

Cost control

• A hard ceiling on output tokens, independent of what you configure
• A hard ceiling on input size
• Identical evidence is never paid for twice
• Only the cache-bypassing refresh path is rate limited; a cached read costs nothing and is not throttled
• Per-plan monthly limits through the existing usage system