AI SOC Alert Triage Agent A new AI-powered SOC alert triage agent, governed by the open-source AgentAz specification, enriches, correlates, scores, and recommends dispositions for raw security alerts. It reduces alert fatigue by deduplicating incidents and requires human approval for remediation, escalating high-severity or low-confidence cases to on-call analysts. The blueprint is released under Apache-2.0 and CC-BY-4.0 licenses. 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 /agentaz-specifications — 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 https://www.apache.org/licenses/LICENSE-2.0 spec text under CC‑BY‑4.0 — schema and source on GitHub https://github.com/agent-kits/agentaz . 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": "