Remediation actions
Every finding ships with a prioritized remediation plan: control class, suggested change, and the evidence that justifies it.
Findings are only useful when they turn into changes. Remediation actions are the concrete responses attached to a finding — from prompt hardening to spend limits — each with an owner and a verification path.
The catalogue below describes the action types the platform recognizes and the workflow that closes the loop after a fix ships.
Key points
- Remediations are decision-support, not auto-apply — a human must approve each one.
- Each action links back to the finding(s) and the transcripts that produced it.
- Actions are versioned alongside the run that generated them.
- Use the finding detail and Evidence Pack to route approved actions through your existing workflow while tenant webhook delivery is planned.
Action types
- Control upgrade (keyword filter → semantic classifier).
- Scope narrowing (reduce tool allowlist).
- Budget enforcement (token cap, rate limit).
Action types are deliberately concrete. 'Improve the prompt' is not an action; restricting tool scope, adding an output filter, or capping spend are, because each can be observed and re-tested by the engine.
Each action names the control it upgrades and how the change gets validated: a scope narrowing can be confirmed from the tool allowlist itself, while a control upgrade needs the replay to prove the new filter catches the variant that slipped through.
Workflow
- Triage in the findings inbox.
- Assign to the owning service team.
- Verify by re-running the same scenario after the fix lands.
Verification is a replay, not a promise: rerun the same scenario after the fix and compare verdicts. The platform keeps the original request so the retest exercises the same path the finding proved, within the declared scenario version.
Related resources