Cyber Incident Response AI Agents
Cyber incident response AI agents are scoped software agents powered by large language models that perform specific incident-handling work under human direction. Each agent has a defined role, scoped permissions, retrieval grounded on the incident ledger, and produces drafts that a named human role approves before release. This page documents the 7-agent architecture: one accountable human commander, seven specialized AI agents, one hash-chained ledger.
The 7-agent architecture
Triage Agent
- Scope
- Classify inbound signals (SIEM, MDR, user reports, supplier disclosures) against the IR plan. Recommend initial severity, command structure, and call-out list.
- Inputs
- Signal payload, IR plan, prior incident patterns, current incident ledger
- Output
- Draft severity classification, draft command structure, draft call-out
- Approver
- Incident Commander
- Cannot
- Open an incident autonomously, page on-call, send notifications
Communications Agent
- Scope
- Draft holding statements, customer letters, board briefs, internal employee updates, and public statements against the approved holding statement library.
- Inputs
- Current incident facts, materiality state, stakeholder map, prior approved templates
- Output
- Drafts ready for review
- Approver
- Legal · Communications Lead · Executive Sponsor
- Cannot
- Send communications, post to social, email customers, brief media
Regulatory Agent
- Scope
- Run the 8 regulatory clocks (SEC 8-K Item 1.05, GDPR Article 33, NY DFS 23 NYCRR 500, HIPAA, PCI DSS 12.10, NIS2, DORA Article 19, CIRCIA) from incident scope. Draft each notification grounded on source paragraphs.
- Inputs
- Data classes, geography, sector, materiality state, regulator-specific templates, source statute text
- Output
- Time-to-deadline countdowns and notification drafts
- Approver
- Counsel of record
- Cannot
- File with regulators, make materiality determinations, waive privilege
Forensics Agent
- Scope
- Reconstruct the incident timeline from EDR logs, identity provider logs, email, ticketing, and chat transcripts. Maintain chain-of-custody summaries for evidence.
- Inputs
- Log feeds, MDR investigation notes, forensic image hashes
- Output
- Canonical incident timeline with source citations, evidence summary
- Approver
- Forensic investigator (in-house or retained)
- Cannot
- Modify forensic images, alter evidence, generate forensic conclusions without investigator signoff
Recovery Agent
- Scope
- Sequence restoration tasks per the IR plan recovery procedures. Track RTO/RPO progress. Surface dependencies and blockers.
- Inputs
- IR plan recovery sequence, backup metadata, system dependency graph
- Output
- Draft restoration sequence, dependency map, progress tracking
- Approver
- Recovery Lead
- Cannot
- Execute restoration commands, restart systems, modify backup state
Stakeholder Agent
- Scope
- Manage cyber insurance first-notice, supplier and customer briefings, and board updates. Coordinate the stakeholder map maintained in the IR plan.
- Inputs
- Cyber insurance policy, stakeholder map, prior briefing cadence
- Output
- First-notice drafts, briefing schedule, supplier and customer letter drafts
- Approver
- Communications Lead · Risk Officer
- Cannot
- Issue first-notice without insurer-broker-counsel review, brief suppliers without counsel approval
Retrospective Agent
- Scope
- Draft the after-action review from the incident ledger. Map adversary behavior to MITRE ATT&CK. Identify lessons learned and recommend IR plan updates.
- Inputs
- Complete incident ledger, IR plan, prior AARs
- Output
- Draft AAR, ATT&CK mapping, IR plan change proposals
- Approver
- Incident Commander · Security Committee
- Cannot
- Modify the IR plan, close the incident, publish AAR externally
Why seven agents, not one
A single general-purpose LLM trying to do every incident response task at once suffers from context contamination, capability ambiguity, and accountability blur. Specialized agents with narrow scopes produce higher-quality drafts because retrieval is targeted, output is structured, and the human approver knows exactly what role is reviewing what.
Seven matches the natural decomposition of incident command work: triage, communications, regulatory, forensics, recovery, stakeholder, retrospective. The decomposition aligns with the canonical role list in the incident command roles reference and the IR plan structure recommended by NIST SP 800-61 Revision 3.
Provenance is the audit substrate
Every AI agent output is committed to the append-only event ledger as an entry with: (1) the agent identifier, (2) the model name and version, (3) the prompt and retrieval context hash, (4) the output text hash, and (5) the named human approval signature. The ledger is hash-chained at SHA-256 granularity. The chain root is published to app.ir-os.com/verify for independent third-party verification.
The reason this matters: when an SEC enforcement inquiry, a GDPR supervisory authority audit, or a litigation discovery request asks how a specific decision was made, the organization can produce a complete provenance record of every AI suggestion, every retrieval source, and every human approval, with cryptographic proof of timestamp and non-tampering. The AI did not act in the dark. The AI acted under a human approver, with a recorded prompt, against a recorded context, at a recorded time.
Capability scoping enforces the boundary
Each agent runs inside a capability scope that defines what tools it can call, what data it can read, and what outputs it can write. The Triage Agent cannot call any external API. The Communications Agent cannot send email. The Regulatory Agent cannot file. The scoping is enforced at the tool layer, not at the prompt layer, because prompt-layer enforcement is bypassable by injection. Tool-layer enforcement is not.
The capability boundary is the technical implementation of the human-in-the-loop principle. Even if an AI agent decided to do something it should not do, the tool layer would refuse the call. The result is that the boundary between "AI can draft this" and "AI cannot release this" is enforced as code, not as policy.
What changes when an agent is wrong
Every AI agent output is a draft. The named human approver catches errors. The catch rate is itself measurable: how often does the approver edit before approving, and how often does the approver reject. These rates are surfaced per agent so the organization can see which agents are performing well and which need prompt or retrieval tuning.
If a flawed output is released because the human approver missed the error, the hash-chained ledger preserves the AI provenance and the human approval. Root-cause review then has the complete record: what did the AI suggest, what did the human approve, what did the regulator receive, where did the error enter, and what change to prompt, retrieval, or approval process closes the gap.
NIST AI Risk Management Framework alignment
The 7-agent architecture is designed to support NIST AI Risk Management Framework 1.0 (AI 100-1, January 2023) and the Generative AI Profile (NIST AI 600-1, July 2024). GOVERN is supported by the approval-bound ledger and capability scoping. MAP is supported by per-agent scope documentation in this page. MEASURE is supported by per-agent approval rates and post-incident accuracy audits. MANAGE is supported by the hash-chained ledger and the public verifier.
The architecture does not by itself produce NIST AI RMF compliance for the customer organization. The customer must perform its own GOVERN-MAP-MEASURE-MANAGE work: AI use policy, risk register, approval rate targets, retention schedules, and an organizational risk owner. IR-OS provides the technical substrate; the customer provides the governance program.
Frequently Asked Questions
What are cyber incident response AI agents?
Cyber incident response AI agents are scoped software agents powered by large language models that perform specific incident-handling work under human direction. Each agent has a defined role (triage, communications, regulatory, forensics, recovery, stakeholder, retrospective), scoped permissions, retrieval grounded on the incident ledger, and produces drafts that a named human role approves before release. Agentic IR is distinct from autonomous AI: it preserves human accountability at every commit.
What is the 7-agent architecture in cyber-IR?
The 7-agent architecture is the IR-OS pattern for agentic cyber incident response: one accountable human Incident Commander orchestrates seven specialized AI agents. Triage Agent classifies inbound signals. Communications Agent drafts statements. Regulatory Agent runs the 8 clocks. Forensics Agent reconstructs timelines. Recovery Agent tracks restoration. Stakeholder Agent handles cyber insurance first-notice, suppliers, and customers. Retrospective Agent drafts the after-action review.
How are AI agents different from SOAR playbooks?
SOAR playbooks execute deterministic steps against alerts and APIs at the detection layer. AI agents operate in the response and recovery phases on novel situations where playbooks run out. SOAR automates the known. Agents reason about the unknown under human direction. The two coexist: SOAR enriches the alerts that feed the Triage Agent, and the Recovery Agent can call SOAR-style automations as a tool.
What permissions do AI agents in cyber-IR have?
AI agents in IR-OS have scoped read permissions to the incident ledger and approved organization data, and scoped write permissions only to draft outputs in the ledger. No agent has authority to file regulator notifications, send external communications, authorize ransomware payments, declare incidents closed, or waive privilege. Every release-level action requires a named human approver bound to the output hash.
How is privilege preserved when AI agents are involved?
Privilege is structural: counsel direction is declared at incident open and bound to every subsequent AI interaction inside the privilege container. AI prompts, retrievals, and drafts are work product under that container. There is no mid-flight redaction. There is no responder-asserted privilege. The privilege structure is captured at incident open and survives counsel rotation and incident escalation. See structural privilege in cyber-IR.
What happens if an AI agent makes a mistake?
Every AI agent output is a draft that requires named human approval before release. A flawed draft is corrected at the approval step. If a flawed output is released because the human approver missed the error, the hash-chained ledger preserves the AI provenance (model, prompt, retrieval), the draft, the human approver identity, and the timestamp. Accountability traces to both the AI's output and the human approval decision, which supports root-cause review and improvement.
Can AI agents run autonomously in cyber-IR?
In IR-OS, no. Agents do not act autonomously on release-level decisions: regulator notifications, public statements, ransomware payments, incident closure, and privilege waiver are all human-only actions. Agents can run autonomously on internal drafts and retrieval steps that produce drafts for human review. This is the boundary between agentic incident response and autonomous AI. The boundary is enforced by capability scoping and the approval-binding ledger.
What models do the AI agents use?
IR-OS routes AI agents through OpenRouter to multiple frontier models with task-specific selection: high-reasoning models for the Regulatory and Retrospective Agents (complex multi-source reasoning), faster cost-efficient models for the Triage and Stakeholder Agents (high-volume tasks). The model identity and version are recorded in the ledger for every agent output. Customers can scope models by data residency requirements (US, EU, UK).
How does the 7-agent architecture handle conflicting agent outputs?
Agent outputs are coordinated through the shared incident ledger, not through direct agent-to-agent messaging. The Incident Commander dashboard surfaces conflicts (for example, a Regulatory Agent draft that disagrees with a Communications Agent draft on materiality language). The human commander resolves the conflict. The resolution is recorded in the ledger. There is no autonomous agent arbitration of release-level conflicts.
Is the 7-agent architecture compliant with NIST AI RMF 1.0?
The architecture is designed to support compliance with NIST AI Risk Management Framework 1.0 (AI 100-1) and the Generative AI Profile (AI 600-1). GOVERN is supported by the approval-bound ledger and capability scoping. MAP is supported by per-agent scope documentation. MEASURE is supported by per-agent approval rates and post-incident accuracy audits. MANAGE is supported by the hash-chained ledger and the public verifier. Customer-specific NIST AI RMF compliance requires customer-side governance work.
See the 7-agent architecture in production
IR-OS runs seven specialized AI agents under one human Incident Commander, with provenance committed to a hash-chained ledger and a public verifier. Five-minute setup. No credit card.
Start your 7-day free trial