This guide saves a private scenario record for your tenant: a titled, categorized description of the behavior you want tested. Pro plan and above; creation and listing only — running custom records from /runs/new is not wired yet.
Write the record as if a future engineer must reconstruct your intent from it alone: name the behavior, state the expected evidence, and respect the field limits.
1. Describe the scenario
- Open /settings/scenarios and enter a title that names the behavior you intend to test.
- Add a description that states the expected evidence and its limit; do not place hostnames, credentials, or other secrets in these fields.
- Choose one available category: owasp-top10, auth-controls, cloud-misconfiguration, data-exfiltration, or ai-attacks. A category organizes the record; it does not prove coverage.
Keep hostnames, credentials, and secrets out of the title and description — these fields are stored as tenant metadata, not as a secure vault. Pick the closest category; the current form offers owasp-top10, auth-controls, cloud-misconfiguration, data-exfiltration, and ai-attacks.
2. Save and verify the record
- Click Create and confirm that the title and category appear in the tenant's private list.
- The current form stores a standard staging template behind the record and supports listing or deletion. It does not expose template editing or MITRE-tactic selection.
- Do not treat the saved record as an executed test: the current /runs/new flow does not yet select these records. Only a completed run against an allowed target can produce evidence.
After Create, verify the record in the tenant's private list. The stored record is metadata over a standard staging template — it is not an executed test, and the current /runs/new flow does not select these records. Only a completed run is evidence.