Alert Triage

Systematic security alert triage. When activated, the agent scans all connected security systems for recent alerts, classifies them against known patterns, scores severity, and recommends specific response actions for each real finding.

Purpose

Reduce alert-to-response time from hours to minutes. The analyst asks "what happened overnight?" and gets a prioritized, contextualized answer — not a raw alert dump.

When to activate

• Start of shift: "What needs attention?"
• Alert spike: "We're seeing a lot of CrowdStrike detections — triage them"
• On-call handoff: "Summarize what's open"
• Any request to review, scan, or prioritize security alerts

Data gathering (dispatch task agents)

The agent dispatches 3 task agents in parallel:

Agent 1 — Alert Collection Query every connected security system for alerts since lastTriageTimestamp:

• CrowdStrike: detections with severity >= medium
• Splunk: notable events not yet triaged
• PagerDuty: triggered and acknowledged incidents
• Okta: suspicious authentication events (impossible travel, brute force) Return: normalized alert list with source, severity, timestamp, affected entity.

Agent 2 — Context Enrichment For each unique entity (host, user, IP) in the alert set:

• Load KB for known false positives and expected patterns
• Check for prior incidents involving the same entity
• Pull recent activity baseline (is this entity usually active at this time?) Return: context annotations for each alert (known pattern, prior history, baseline deviation).

Agent 3 — IOC Reputation For any IOCs found in alerts (hashes, IPs, domains):

• Query VirusTotal for reputation scores
• Check internal KB for previously investigated IOCs
• Cross-reference with threat intelligence feeds Return: reputation verdict for each IOC (clean, suspicious, malicious, unknown).

Analysis framework

Severity scoring (per alert)

Each alert is scored 0-100 based on:

| Factor | Weight | What it measures | |--------|--------|-----------------| | Source severity | 25% | The severity assigned by the detection tool | | Entity criticality | 20% | Is this a domain controller, exec laptop, service account? | | Pattern match | 20% | Does this match a known attack pattern vs known false positive? | | IOC reputation | 15% | Are associated IOCs known-malicious? | | Behavioral deviation | 10% | How far is this from the entity's baseline? | | Corroboration | 10% | Do multiple sources see the same thing? |

Classification

• Critical (80-100): Confirmed malicious activity, active threat. Immediate action required.
• High (60-79): Strong indicators, not yet confirmed. Investigate within 1 hour.
• Medium (40-59): Suspicious but ambiguous. Investigate within 4 hours.
• Low (20-39): Minor anomaly, likely benign. Review within 24 hours.
• Noise (0-19): Known false positive or expected behavior. Auto-close recommended.

Output format

Present results using:

• status-board widget: overview of alert counts by classification
• alert-card widgets: one per critical/high finding with context and recommended action
• data-table widget: full alert list sortable by score

Rules

• Never auto-close alerts — recommend closure, analyst confirms
• Always cite the source system and detection ID for traceability
• If an alert matches a known false positive in KB, note it but still include in output
• Propose KB updates when new false positive patterns are discovered
• Maximum 50 alerts per triage run — if more exist, triage the top 50 by severity and note the overflow