Overview
Enrich → correlate → score → recommend: turns raw alerts into triaged, evidence-backed incidents with a clear disposition.
Context-aware severity: combines IOC reputation, asset criticality, and user/identity context — not just the raw signature — and maps to MITRE ATT&CK.
Defensive dispositions: auto-remediates only verified low-risk cases with approval, never silently dismisses likely true positives, and escalates suspected targeted activity.
Cuts alert fatigue without cutting corners: correlates duplicates into single incidents and explains every decision so analysts can trust and audit it.
AgentAz™ specification
A lightweight, design-time governance spec for security review. It documents what this agent is authorized to do — and why — and pairs with whatever policy engine you already run. It does not enforce anything at runtime.
Machine-readable contract (agentaz.json), validated against the open AgentAz™ JSON Schema — bundled for offline use and published at a permanent URL:
{
"$schema": "./agentaz.schema.json",
"version": "2.0.0",
"last_reviewed": "2026-06-24",
"agent_id": "alert-triage-enrichment-agent",
"trust_level": "A3",
"dna_pattern": "Escalation",
"worst_case_action": "Stages an inappropriate remediation for human approval, or mis-prioritizes an alert. Cannot auto-execute remediation.",
"authority_boundary": "Enriches and triages alerts; stages verified low-risk remediation for approval. No autonomous execution.",
"tags": [
"security",
"soc",
"alert-triage",
"human-approval"
],
"tool_boundary": {
"allowed_tools": [
"enrich_alert",
"dedupe",
"prioritize",
"stage_remediation"
],
"approval_required_tools": [
"apply_remediation"
],
"execution_tools_absent": false
},
"output_boundary": {
"format": "structured_json",
"never_without_approval": [
"apply_remediation"
]
},
"cost_boundary": {
"max_usd_per_trace_loop": 0.3,
"alert_threshold_usd": 0.2
},
"loop_boundary": {
"max_reasoning_turns": 10
},
"human_handoff": {
"triggers": [
"high_severity",
"remediation_proposed",
"low_confidence"
],
"destination": "soc_oncall"
},
"audit": {
"append_only": true,
"logs": [
"enrichment",
"priority",
"staged_actions",
"approvals"
]
}
}New to this? Read the AgentAz specification guide — Trust Levels, DNA patterns, and how it complements your runtime.
This is a flagship reference blueprint for AgentAz v1.0.0. AgentAz™ is open source under Apache-2.0 (spec text under CC‑BY‑4.0) — schema and source on GitHub.
Governance matrix
A scannable summary of this blueprint's governance coverage, derived from its AgentAz™ specification. It documents the boundaries that already ship — not new functionality.
| Agent goal | Bounded by the authority spec above |
|---|---|
| Trust Level | A3 — Human-Approved |
| Tool access | Scoped tools; high-risk actions gated behind approval |
| Context handling | Grounded in provided inputs; cites or flags rather than guessing |
| Memory strategy | Task-scoped; no persistent cross-session memory |
| Human approval | Required on high severity, remediation proposed, low confidence → soc oncall |
| Audit trail | Append-only log (enrichment, priority, staged actions, approvals) |
| Cost & loop bounds | ≤ $0.3 per loop · ≤ 10 reasoning turns |
| Recovery / escalation | Escalates to soc oncall |
Agent component mapping
A framework-neutral view of how this blueprint maps to standard agent-architecture components (the vocabulary common to ADK-style frameworks). It describes structure for clarity — not an official integration or certified compatibility.
| Agent | Primary reasoner — Human-Approved authority (A3) |
|---|---|
| Tools | enrich alert, dedupe, prioritize, stage remediation; approval-gated: apply remediation |
| Memory | Task-scoped working context; no persistent cross-session memory |
| Guardrails | Worst-case classified (A3); high-risk actions gated; ≤ $0.3/loop · ≤ 10 turns |
| Evaluator | Confidence and authority-boundary checks; low-confidence or out-of-bounds results are flagged, not actioned |
| Handoff | Escalates to soc oncall on high severity, remediation proposed, low confidence |
Failure modes
Specific ways this blueprint can fail, and how it is designed to detect, contain, and recover from each — the boundaries that make it safe to run, stated plainly.
Enriches an alert with a mis-attributed indicator (wrong IP, hash, or owner), skewing severity.
- Detection
- Each enrichment carries a confidence score and source citation; conflicting sources are flagged.
- Mitigation
- Every enrichment is tied to its source; unverified attribution is never asserted.
- Recovery
- The analyst sees the citation and can discard it; low-confidence enrichments are quarantined for review.
Suppresses or deprioritizes a real threat as noise.
- Detection
- Critical severity is never auto-suppressed; suppression is only ever a recommendation.
- Mitigation
- Critical alerts are always surfaced regardless of score.
- Recovery
- Analyst override; any suppressed-then-escalated alert is logged for rule tuning.
An enrichment source is unavailable, producing an incomplete picture.
- Detection
- Source timeout and health checks detect the gap.
- Mitigation
- Degrade gracefully — fields are marked unknown rather than guessed.
- Recovery
- Re-enrich when the source returns; the partial enrichment is flagged.
Evaluation
Recall on true threats, balanced against false-positive noise, is the metric that matters — a suppressed real alert is the worst outcome.
| Enrichment accuracy | Share of enrichments (attribution, severity, context) that match verified ground truth. |
|---|---|
| Precision | Of alerts it escalated, the share that were genuinely actionable — false-positive resistance. |
| Recall | Of true threats in the set, the share it surfaced rather than deprioritized as noise. |
| Escalation rate | Frequency of analyst handoff, split into warranted vs unnecessary. |
| Latency | Time from raw alert to an enriched verdict. |
Recommended approach. Build a gold set of labeled alerts with known dispositions and measure precision and recall against analyst labels. Track suppression decisions separately — a suppressed true positive should be weighted as the costliest error.
When to use
Use it when
- Your SOC is drowning in alerts and analysts spend most of their time on enrichment and obvious false positives.
- You have threat-intel, asset inventory (CMDB), and identity sources the agent can enrich from.
- You want consistent, documented tier-1 triage with MITRE mapping and an audit trail.
- You want to auto-handle verified low-risk noise while ensuring real threats reach humans fast.
- You need correlation that collapses alert storms into single incidents.
Avoid it when
- You have no enrichment sources (threat intel, asset, identity) — triage would be ungrounded.
- You expect it to run incident response and containment fully autonomously on critical assets; those need human authorization.
- You want it to make legal/compliance breach determinations — those are human and counsel decisions.
- You are unwilling to keep analyst review on dismissals and high-severity escalations.
System prompt
You are a Tier-1 SOC Analyst Agent. Your job is to triage one security alert (or a cluster of related alerts): enrich it, judge it on evidence, and recommend a disposition. You are judged on catching true positives (never missing a real threat), on cutting false-positive noise, and on never taking an unsafe containment action without authorization.
== CORE PRINCIPLES ==
1. Evidence-based, never assumed. Base severity and disposition on enrichment you actually gathered — IOC reputation, asset criticality, identity/behavior context, and correlation. Cite what you used.
2. Bias toward catching threats. When the evidence is mixed, treat it as a potential true positive and escalate. A false escalation costs minutes; a missed intrusion costs everything.
3. Explain every call. An analyst must be able to read your reasoning and the evidence and agree or override. No black-box dispositions.
== HARD RULES (NON-NEGOTIABLE) ==
- CONTAINMENT AUTHORITY: You may recommend, and (if enabled) auto-execute, containment ONLY for verified low-risk cases on non-critical assets (e.g. quarantine a single non-critical endpoint with a confirmed commodity-malware detection). Containment of any critical/crown-jewel asset, server, or identity, or anything that disrupts business operations, REQUIRES human approval — propose, do not execute.
- NEVER DISMISS A PLAUSIBLE TRUE POSITIVE. Mark an alert as false positive only with positive evidence that it is benign (known-good process, sanctioned scan, confirmed misconfiguration). Absence of evidence is not benign — when unsure, escalate.
- NO TIPPING OFF. For suspected insider or targeted intrusion, do not take actions that could alert the adversary; recommend coordinated response and escalate.
- DATA HANDLING: Treat user and asset data as sensitive. Redact secrets; never expose credentials. Stay within your read scope for enrichment.
- STAY IN LANE. You do not make breach-notification or legal determinations; you surface evidence and escalate.
== DISPOSITION POLICY (calibrated confidence 0.0-1.0) ==
- AUTO_REMEDIATE: verified low-risk true positive on a non-critical asset, allow-listed action, confidence >= 0.85. (If auto-execution is disabled, downgrade to RECOMMEND.)
- DISMISS (false positive): positive benign evidence and confidence >= 0.85. Document the benign indicator.
- RECOMMEND: actionable but needs an analyst to action or approve (medium severity, or containment on a sensitive asset). Provide the recommendation and evidence.
- ESCALATE (tier-2/IR): high severity, critical asset, suspected targeted/lateral movement or data exfiltration, correlated multi-stage activity, conflicting evidence, or confidence < 0.6.
== ENRICHMENT & CORRELATION ==
Enrich with threat intel (IOC reputation/age), asset criticality (CMDB), and identity/behavior context. Correlate with related recent alerts to detect multi-stage attacks; if several alerts form a chain, treat them as ONE incident and raise severity accordingly. Map observed behavior to MITRE ATT&CK technique IDs.
== COST CONTROL ==
Enrich only the indicators that change the decision; don't query every source for every alert. Reuse enrichment already in context. Cap tool calls; if exceeded, escalate with what you have.
== OUTPUT FORMAT (return ONE JSON object) ==
{
"alert_id": "<id or cluster id>",
"severity": "critical|high|medium|low|informational",
"confidence": <0.0-1.0>,
"verdict": "true_positive|false_positive|suspicious|unknown",
"mitre": ["Txxxx ..."],
"enrichment": { "iocs": ["..."], "asset_criticality": "...", "identity_context": "..." },
"correlation": "<related alerts / multi-stage chain, or 'none'>",
"disposition": "AUTO_REMEDIATE|DISMISS|RECOMMEND|ESCALATE",
"actions": [ { "tool": "<tool>", "args": { ... }, "requires_approval": <bool> } ],
"rationale": "<why, grounded in the enrichment and correlation>",
"analyst_note": "<concise summary + recommended next steps>",
"escalation": { "needed": <bool>, "tier": "tier2|IR|none", "reason": "<why, or empty>" }
}
If verdict is unknown or evidence is mixed, do not DISMISS — RECOMMEND or ESCALATE.Simulate run
Try the agent with a sample task. This is a frontend-only preview that shows how the kit would plan and execute — no API calls, nothing leaves your browser.
Frontend preview only — no data leaves your browser. Tip: press ⌘/Ctrl + Enter to run.
Setup guide
Install and connect sources
Install the agent and connect it (read-only for enrichment) to your SIEM/EDR, threat intel, CMDB, and identity provider.
pipx install soc-triage-agent soc-triage-agent connect --siem splunk --edr crowdstrike --intel virustotal --cmdb servicenow --idp okta soc-triage-agent doctor
Set containment authority and caps
Define what may auto-contain. Critical assets are never autonomous. Limits are enforced outside the model.
cp .env.example .env ANTHROPIC_API_KEY=sk-ant-... SIEM_TOKEN=... INTEL_TOKEN=... MAX_TOOL_CALLS=8 MODE=advise # advise (recommend only) | act (auto low-risk)
Classify critical assets
Tell the agent which assets/identities are crown jewels so it never auto-contains them.
# .soc.yml
critical_assets:
- "domain-controllers/*"
- "prod-db/*"
- "finance/*"
auto_contain_allowed:
- scope: "non_critical_endpoint"
when: "verified_commodity_malware"
never_dismiss_without: "benign_evidence"Backtest on historical alerts
Replay labeled past alerts to measure true/false-positive handling before going live.
soc-triage-agent backtest --range 30d --explain # reports verdict accuracy, FP reduction, and any missed true positives (must be ~0)
Wire into the SIEM as tier-1
Route new alerts to the agent for triage. Start in advise mode (recommends only), enable act mode for allow-listed low-risk containment once backtests look clean.
# SIEM webhook -> POST https://your-host/soc/alert (HMAC) # Promote MODE=act only after a clean backtest with zero missed true positives
Architecture
Tools required
Workflow
1. Intake and dedup
Pull the alert from the SIEM/EDR, normalize its fields, and group obvious duplicates so a storm becomes one case.
2. Enrich the evidence
Enrich the indicators that matter (IOC reputation, asset criticality, identity context) — only the ones that could change the decision.
3. Correlate
Search recent related alerts for a multi-stage chain; if found, merge into one incident and raise severity to match the bigger picture.
4. Score and map
Assign severity and a verdict from the combined evidence and map observed behavior to MITRE ATT&CK technique IDs.
5. Decide the disposition
Auto-remediate only verified low-risk true positives on non-critical assets; dismiss only with positive benign evidence; otherwise recommend or escalate.
6. Act through the gate
The containment gate executes only allow-listed low-risk actions; critical-asset or disruptive actions are staged for analyst approval with the evidence attached.
7. Document and learn
Create/update the case with the full package, route escalations to tier-2/IR, and log analyst agreement to tune detections and confidence.
Examples
Commodity malware on a non-critical endpoint → auto-remediate (with approval)
EDR flags a known malware hash on a standard laptop. Enrichment confirms it's a verified commodity threat on a non-critical asset — a safe candidate for fast remediation.
Input
Alert: EDR detection 'Win.Trojan.GenericKD' hash a1b2c3... on host LT-4471 (user: contractor laptop).
Output
{
"alert_id": "EDR-99812",
"severity": "medium",
"confidence": 0.9,
"verdict": "true_positive",
"mitre": ["T1204 User Execution"],
"enrichment": { "iocs": ["hash a1b2c3 = known commodity trojan, 41/64 vendors, first seen 2024"], "asset_criticality": "low (standard endpoint, no sensitive data)", "identity_context": "contractor, no admin rights, no recent privileged activity" },
"correlation": "none — single isolated detection, no related alerts in the last 24h",
"disposition": "AUTO_REMEDIATE",
"actions": [ { "tool": "contain_host", "args": { "host": "LT-4471", "action": "quarantine", "scope": "non_critical_endpoint" }, "requires_approval": true } ],
"rationale": "Verified commodity malware (high vendor consensus) on a low-criticality endpoint with a non-privileged user and no correlated activity. Low blast radius; quarantine + reimage is the standard safe response.",
"analyst_note": "Quarantine LT-4471 and reimage; reset the contractor's session creds as hygiene. No signs of spread.",
"escalation": { "needed": false, "tier": "none", "reason": "" }
}Note: A clean true positive the SOC wants handled fast — but note containment is still flagged requires_approval=true by default, and would only auto-execute if 'act' mode is on AND the asset is non-critical. The verdict is grounded in vendor consensus, asset criticality, and the lack of correlation.
Correlated credential-stuffing → one incident, recommend response
Dozens of 'failed login' alerts look like noise individually. Correlation reveals a single distributed attack — the agent collapses them and recommends action.
Input
Alerts: 60+ failed-login alerts across 30 accounts in 8 minutes from a rotating set of IPs, then 2 successful logins.
Output
{
"alert_id": "CLUSTER-2207",
"severity": "high",
"confidence": 0.82,
"verdict": "true_positive",
"mitre": ["T1110.004 Credential Stuffing", "T1078 Valid Accounts"],
"enrichment": { "iocs": ["source IPs across 14 ASNs, several on auth-abuse intel lists"], "asset_criticality": "medium (customer-facing auth)", "identity_context": "2 accounts now show successful login from new geo/device after the burst" },
"correlation": "60+ failed logins + 2 successes form one credential-stuffing campaign — merged into a single incident.",
"disposition": "RECOMMEND",
"actions": [
{ "tool": "create_incident", "args": { "title": "Credential stuffing with 2 likely-compromised accounts", "severity": "high" }, "requires_approval": false },
{ "tool": "contain_host", "args": { "action": "force_password_reset+session_revoke", "targets": ["acct_A", "acct_B"] }, "requires_approval": true }
],
"rationale": "Distributed failed logins followed by anomalous successful logins on 2 accounts is classic credential stuffing with probable compromise. Customer-facing auth raises severity; account actions need analyst approval.",
"analyst_note": "Approve forced reset + session revoke for acct_A/acct_B, enable step-up auth, and consider temporary rate-limiting on the auth endpoint.",
"escalation": { "needed": false, "tier": "none", "reason": "" }
}Note: The value here is correlation: 60+ alerts that would each be dismissed as noise become one high-severity incident. The agent recommends account containment but marks it approval-required because forced resets affect real users — it doesn't unilaterally lock customers out.
Suspected lateral movement on a domain controller → escalate, don't touch
Weak-but-worrying signals on a crown-jewel asset. The agent resists both dismissing it and taking a risky containment action that could tip off an adversary.
Input
Alert: unusual SMB + remote-service-creation activity from a workstation to DC-01 (domain controller), outside business hours, by an account that normally never touches DCs.
Output
{
"alert_id": "EDR-99877",
"severity": "critical",
"confidence": 0.55,
"verdict": "suspicious",
"mitre": ["T1021.002 SMB/Admin Shares", "T1543.003 Create/Modify Service", "T1570 Lateral Tool Transfer"],
"enrichment": { "iocs": ["no known-bad hash yet; behavior-based"], "asset_criticality": "critical (domain controller / crown jewel)", "identity_context": "service-desk account, never historically authenticates to DCs, off-hours" },
"correlation": "Possible early lateral movement; checking for prior initial-access alerts on the source workstation.",
"disposition": "ESCALATE",
"actions": [ { "tool": "escalate_to_tier2", "args": { "tier": "IR", "priority": "critical" }, "requires_approval": false } ],
"rationale": "Anomalous remote service creation toward a domain controller by an account that never touches DCs, off-hours, maps to lateral-movement techniques. On a crown-jewel asset this is treated as a potential targeted intrusion despite moderate confidence.",
"analyst_note": "Do NOT auto-isolate the DC or disable the account yet — risk of tipping off the actor and of disrupting the domain. Recommend IR coordinate: capture volatile evidence on source + DC, scope the account's recent activity, then contain in a planned way.",
"escalation": { "needed": true, "tier": "IR", "reason": "Suspected targeted lateral movement toward a domain controller; crown-jewel asset; potential intrusion." }
}Note: The flagship-defining case: confidence is only 0.55, but because the target is a domain controller and the behavior maps to lateral movement, the agent escalates to IR as critical rather than dismissing. Crucially, it explicitly recommends NOT auto-containing — isolating a DC or disabling the account could disrupt the domain and tip off an adversary. It surfaces evidence and defers the response plan to humans.
Implementation notes
- Tune for recall on true positives above all. The cost of a missed intrusion dwarfs the cost of an extra escalation, so 'unknown/mixed evidence' must never resolve to DISMISS.
- Enforce containment authority deterministically from asset criticality. Critical/crown-jewel assets and identities can never be auto-contained; that gate lives outside the model.
- Require positive benign evidence to dismiss. Document the specific known-good indicator on every false-positive call so dismissals are auditable.
- Lead with correlation. Collapsing alert storms into single incidents is where the biggest fatigue reduction comes from — and where multi-stage attacks become visible.
- Map everything to MITRE ATT&CK. It gives analysts a shared language, makes escalations actionable, and supports detection-gap analysis.
- Backtest on labeled history before enabling any auto-action, and track missed-true-positive rate as the primary safety metric (target ~0).
- Reserve the strong model for verdict, correlation, and disposition reasoning; a cheaper model can normalize and enrich.
Variations
Basic
Enrichment & triage assistant
Enriches each alert, scores severity with MITRE mapping, and recommends a disposition with rationale for an analyst to action. No autonomous containment. The safe starting point.
Advanced
Auto-dispositioning with guarded containment
Auto-dismisses evidence-backed false positives and auto-remediates verified low-risk threats on non-critical assets, with correlation into incidents and approval-gated containment for sensitive assets.
Enterprise
Governed SOC automation
Adds multi-source correlation, crown-jewel policies, tier-2/IR routing, full case management and audit, detection-gap analytics, and confidence calibration driven by analyst feedback at scale.
Download the Agent Blueprint
Export
This flagship blueprint and the AgentAz™ specification live in the central AgentKits registry — open source under Apache-2.0 (code & schema) and CC‑BY‑4.0 (text).
Frequently asked questions
Only for verified low-risk cases on non-critical assets, and only if you enable auto-action. Containment of critical assets or identities, or anything business-disrupting, is always proposed for analyst approval — never executed autonomously.
It can only mark an alert false positive with positive benign evidence (a known-good process, sanctioned scan, confirmed misconfig). Mixed or absent evidence never resolves to dismiss — it escalates. Recall on true positives is the primary tuning target.
It escalates to tier-2/IR with a full evidence package and MITRE mapping, and explicitly avoids tipping-off actions — recommending coordinated response rather than unilaterally isolating a crown-jewel asset.
By enriching with real context and correlating related alerts into single incidents, so storms collapse into one case and obvious, evidence-backed false positives are filtered — while anything uncertain still reaches a human.
Every disposition includes the enrichment used, the correlation, a MITRE mapping, and a plain rationale, so analysts can audit and override. You also backtest it on labeled history before enabling any automation.
It enriches only the indicators that could change the decision rather than querying every source for every alert, reuses enrichment already gathered, and caps tool calls — escalating with current evidence if it hits the cap.