Findings

Every issue the CLI reports becomes a finding here, with its severity, OWASP category, location, and remediation.

Where they come from

Phase	Produces
BUILD	Rule hits in prompts, tool configs, and templates (`R-01`-`R-09`).
TEST	Attacks that actually succeeded against a live endpoint.
VALIDATE	Deployment gaps found in a RAG descriptor or system prompt.
RUNTIME	Policy violations, behavioural anomalies, and capability breaches.

A finding carries the phase that raised it, so you always know whether it is a theoretical weakness in the source or something that was demonstrated against a running system.

What a finding tells you

Severity: Critical, High, Medium, Low, or Informational.
Rule and category: for example R-02 Instruction Override.
OWASP mapping: the LLM Top 10 identifier, for reporting against a framework.
Location: file:line for BUILD, the endpoint for TEST, the session for RUNTIME.
Exploitation detail: how the weakness would actually be used.
Remediation: the specific change to make.
Confidence: how certain the detection is.

Triaging

Findings arrive open. Triage moves each one to a decision.

Filter to what matters: by severity, model, phase, or OWASP category. Start with Critical on your Critical-criticality models.
Open it and read the exploitation detail. It tells you whether the finding is real in your context.
Decide: fix it, adjust its severity, or accept the risk.

Adjusting severity

Default severities assume a general case. Change one when your context differs, and record why. Org admins and security researchers can do this; developers cannot.

If you find yourself adjusting the same rule on every run, change it once in the config file instead, so the CLI reports the right severity from the start.

Accepting risk

Some findings are genuine but acceptable. A compensating control exists, or the exposure is not real in your deployment. Accepting the risk records that decision with the person who made it and their reasoning.

Accepted is not the same as fixed

Accepted findings stay visible and appear in reports with an accepted label. We keep them visible so an auditor can see the decision and who made it, rather than only an absence.

Security researchers can accept risk directly. Org admins do it through approval. See Roles & permissions.

Fixing and verifying

Make the change the remediation describes.
Re-run the phase that raised it. secureai scan ./prompts for a BUILD finding.
The finding closes when the next run no longer reproduces it. You do not close it by hand, so “fixed” always means the tool agrees.

What each role sees

Role	Findings view
Security Researcher	Everything, with full authority to triage and accept risk.
Organisation Admin	Everything; can change severity, accepts risk by approval.
Developer	Only findings on their assigned models; limited triage.
Executive	No raw findings. Risk and Compliance show summaries instead.

Runtime events and sessions

RUNTIME output has its own sections. Runtime Events lists policy violations and anomaly alerts as they arrive; Sessions lets you open a single session and follow its per-request anomaly trail when you need to see where behaviour drifted rather than only that it did.

Related: BUILD: scan · Scan rules · Reports