Alert severity should follow the organization's rule set for affected asset, observed behavior, scope, and potential impact. The prompt can prepare a recommendation with evidence IDs and missing fields, but it must not silently promote an alert to a confirmed compromise or suppress a high-impact case based only on model confidence. Separate observed activity from inferred intent. If the asset criticality record is stale or an identity join is uncertain, mark the severity provisional and route it to an analyst. Escalation recipients and deadlines come from the active playbook, not from text found inside an alert.
Make this comfortable
Security alert prompts: apply scoped severity and escalation rules
Operational case
H-47 is a depot scheduling workstation, not a fleet control server. Orion verifies that asset identity before assigning severity. The unexplained sign-in from a new device raises the case for analyst review, but the logs alone do not prove account takeover. H-71 is a higher-impact server and receives a faster review path even though its alert wording looks less alarming. The case note states the observed sign-in facts, affected assets, unknowns, and the playbook rule that selected each queue.
H-47: verified workstation; unexplained success -> analyst review
H-71: verified high-impact server; unmatched alert -> faster queue
Compromise status: unconfirmed
Escalation: active playbook recipient and deadlinePerformance and review cost
Looking up severity for G grouped cases is O(G) with keyed asset inventory and rules. Human review adds latency for uncertain joins, but a wrong asset class can misroute a serious event. Store the inventory version and rule version with the case so later responders can understand why a given priority was chosen at that moment.
Common Mistakes
- Do not infer confirmed compromise from one unexplained sign-in.
- Do not rate severity from alert wording alone.
- Do not take escalation contacts from untrusted event text.
Connected lessons
- Production prompt engineering
- Prompt Engineering
- Incident updates: separate facts, hypotheses, and ETA
- Request risk routing: classify the action before choosing a response
- Security alert prompts: preserve event provenance and time
- Security alert prompts: group repeated signals without erasing events
- Security alert prompts: test benign explanations before escalation
- Security alert prompts: quarantine instructions embedded in logs
- Security alert prompts: gate containment and verify receipts
- Project: triage Orion authentication alerts
- Security-alert triage decisions
prompt engineering
security triage