This workflow turns one finding into one handled case: parse what the run observed, classify and route it to the responsible team, and ship a detection rule only after the evidence supports it.
The order is deliberate — evidence before routing, routing before detection. Each step narrows who needs to act and what they need to see.
1. Receive and parse the finding
- Use the authenticated run detail to review the finding identifier, severity, ATT&CK technique, OWASP category, detection gap, and recommended defense. The detection gap describes what the defender failed to catch.
- Severity helps order the queue, but it does not by itself prove impact, reach, or exploitation in production. Confirm the observed behavior and affected asset.
- Cross-reference owasp_category (e.g. LLM01, LLM06) with /docs/concepts/owasp-llm-coverage to understand what the category covers and which assets it touches in your stack.
Start from the authenticated run detail: identifier, severity, ATT&CK technique, OWASP category, and detection gap. Severity orders the queue; it does not prove impact or exploitation in production — confirm the observed behavior before escalating.
2. Classify and escalate
- For a confirmed Critical or High finding, follow your organization's incident matrix and, for an eligible Starter+ run, attach the evidence pack to the ticket.
- Use detection_gap + attack_technique to route: prompt injection findings → prompt-engineering owner; data exfiltration → guardrail owner; auth bypass → API gateway owner.
- If `remediation.verified=true`, the suggested patch passed the recorded replay for that case. It still needs human review and system-level tests before production.
Route by detection_gap plus attack_technique: prompt injection goes to the prompt-engineering owner, data exfiltration to the guardrails owner. For a confirmed Critical or High finding, follow your incident matrix — and for an eligible Starter+ run, the documented pack can accompany the escalation.
3. Ship the detection rule
- Download the Sigma rule from the run page or GET /v1/runs/{run_id}/sigma. Each rule is scoped to the specific attack pattern — not a broad signature.
- Import to your SIEM using sigma-cli or your platform's native import. Map the log source to your LLM request log index.
- Record the tests that justify moving from `starter` to `tuned` and then `verified`; elapsed time alone is not evidence.
Download the Sigma rule scoped to the specific attack pattern, import it with sigma-cli or native import, and map the log source to your LLM request log index. Record the tests that justify starter to tuned to verified — elapsed time alone is not evidence.