Incident Response

Incident Response provides a structured workflow for handling security incidents — from initial detection through containment, evidence collection, and closure. Every action is recorded in an immutable timeline, and the AI assistant can create incidents, execute containment actions, and generate reports on your behalf.

---

Incident Lifecycle

Incidents progress through five statuses with enforced transitions:

Status	Meaning	Allowed transitions
detected	Incident discovered and triaged	analyzing, contained
analyzing	Investigation in progress	contained, recovering
contained	Containment actions executed	recovering, closed
recovering	System recovery underway	contained, closed
closed	Incident resolved	(terminal)

Classifications

Classification	Description
malware	Malware infection
ransomware	Ransomware attack
phishing	Phishing or social engineering
data_breach	Data exfiltration or exposure
unauthorized_access	Unauthorized system access
denial_of_service	Service disruption attack
insider_threat	Internal threat actor
other	Unclassified incident

Severity Levels

Level	Description
p1	Critical — immediate response required
p2	High — respond within hours
p3	Medium — respond within business day
p4	Low — respond within normal workflow

---

Unified Incident Feed

The Incidents view shows a single feed that mixes two kinds of rows:

• Tracked incidents — full incident records created and managed inside Breeze, following the lifecycle described above.
• EDR findings — raw detections surfaced read-only from a connected EDR provider (Huntress or SentinelOne). These aren’t Breeze incidents yet — they’re detections your EDR reported that haven’t been brought into Breeze’s incident workflow.

Both row types are sorted together by severity and detection time. Each EDR finding shows which provider it came from and links out to the originating console — clicking a Huntress finding opens that detection in Huntress; clicking a SentinelOne finding opens it in the SentinelOne console.

Promoting a finding to a tracked incident

Findings are read-only until you decide one is worth tracking. Click Promote to Incident on a finding row to create a real tracked incident from it — the new incident references the originating finding (via sourceType / sourceRef, see Creating an Incident) so Breeze knows it’s already been handled.

Promoting the same finding a second time is blocked — Breeze returns a conflict (“This finding has already been promoted to an incident”) instead of creating a duplicate. If you see this, look for the existing tracked incident in the feed rather than retrying.

Who sees what

• Tracked incidents are visible to anyone with permission to view alerts.
• EDR findings additionally require permission to view devices, because a finding exposes the device that triggered it. A user with alerts access but not device access sees only tracked incidents — no Huntress or SentinelOne rows. This is expected: it’s normal for two users to see different row counts in the same feed.
• EDR findings are also scoped to sites. If your account is restricted to specific sites, you’ll only see findings for devices in sites you have access to. Findings that aren’t tied to a specific device remain visible regardless of site restrictions.

You can filter the feed by row type or provider (?kind=tracked, ?kind=finding, ?source=huntress, ?source=s1) via GET /incidents/feed.

---

Creating an Incident

POST /incidents
Content-Type: application/json
Authorization: Bearer <token>

{
  "title": "Suspicious process on web-server-01",
  "classification": "malware",
  "severity": "p2",
  "summary": "Agent detected unknown process communicating with external IP.",
  "relatedAlerts": ["alert-uuid-1"],
  "affectedDevices": ["device-uuid-1"],
  "assignedTo": "user-uuid"
}

Field	Type	Required	Description
title	string	Yes	Short description
classification	string	Yes	Incident type (see classifications above)
severity	string	Yes	p1, p2, p3, or p4
summary	string	No	Detailed description
relatedAlerts	UUID[]	No	Related alert IDs
affectedDevices	UUID[]	No	Affected device IDs
assignedTo	UUID	No	User to assign
sourceType	string	No	huntress_incident or s1_threat — set when promoting an EDR finding into a tracked incident
sourceRef	string	No	The originating finding’s ID from the EDR provider — set together with sourceType when promoting

The incident is created with status detected and an initial timeline entry.

Setting sourceType and sourceRef together is how a finding is promoted into a tracked incident — it’s what the Promote to Incident button in the feed does under the hood. Breeze only lets a given finding be promoted once: submitting the same sourceType/sourceRef pair again returns 409 Conflict rather than creating a second incident for the same finding.

---

Containment Actions

Execute containment actions to isolate threats during an active incident.

POST /incidents/:id/contain
Content-Type: application/json

{
  "actionType": "process_kill",
  "description": "Killing suspicious svchost.exe (PID 4832)",
  "executedBy": "user-uuid",
  "approvalRef": "approval-123"
}

Action Types

Action	Description	Requires Approval
process_kill	Terminate a process by PID	Yes
network_isolation	Isolate device from network	Yes
account_disable	Disable a compromised user account	Yes
usb_block	Block USB device access	Yes

All containment actions require an approvalRef parameter. Actions are dispatched as agent commands and their results are recorded in the incident timeline.

Action Statuses

Status	Meaning
pending	Awaiting execution
in_progress	Executing on device
completed	Successfully executed
failed	Execution failed
cancelled	Cancelled before execution

---

Evidence Collection

Attach forensic evidence to an incident for investigation and compliance.

POST /incidents/:id/evidence
Content-Type: application/json

{
  "evidenceType": "log",
  "description": "System event logs from 2026-03-28",
  "collectedAt": "2026-03-28T14:00:00Z",
  "collectedBy": "user-uuid",
  "hash": "sha256-hash-of-content",
  "storagePath": "s3://evidence-bucket/incident-001/logs.tar.gz"
}

Evidence Types

Type	Description
file	File artifacts
log	System or application logs
screenshot	Device screenshots
memory	Memory snapshots
network	Network connection data

Evidence integrity is validated using SHA-256 hashes. Storage paths must use approved URI schemes (s3://, gs://, r2://, azblob://, immutable://, https://). Path traversal sequences are blocked.

---

Incident Timeline

Every incident maintains an immutable timeline that records all events:

Entry Type	Description
incident_created	Incident was opened
containment_executed	Containment action completed successfully
containment_attempted	Containment action was attempted but failed
evidence_collected	Evidence was attached
incident_closed	Incident was closed with summary

Each entry includes a timestamp, actor (user, brain, or system), summary, and type-specific metadata.

View the full timeline:

GET /incidents/:id

The response includes the incident details, timeline array, all containment actions, and all collected evidence.

---

Closing an Incident

POST /incidents/:id/close

{
  "summary": "Malware removed, device re-imaged, credentials rotated.",
  "lessonsLearned": "Detection delay was 4 hours. Adding process monitoring rule.",
  "resolvedAt": "2026-03-28T18:00:00Z"
}

Closing records a resolvedAt timestamp, updates the status to closed, and adds a closure entry to the timeline.

---

Incident Reports

Generate a structured report for an incident:

GET /incidents/:id/report

Returns:

• Report metadata — title, classification, severity, duration
• Actions summary — total, completed, failed, pending, action types used
• Evidence summary — total count, breakdown by type
• Full timeline — chronological event list

---

AI-Assisted Incident Response

The AI assistant provides five tools for incident management:

Tool	Tier	Description
create_incident	Tier 2	Create a new incident with classification and severity
execute_containment	Tier 3	Run a containment action on a device (requires approval)
collect_evidence	Tier 2	Collect forensic evidence from a device
get_incident_timeline	Tier 1	View the full incident timeline
generate_incident_report	Tier 1	Generate a structured incident report

The AI can also trigger playbooks as part of incident response. Ask the AI to run a playbook against an affected device, and it will execute the playbook with the incident ID in the execution context for traceability.

Note

execute_containment is Tier 3 and requires human approval before execution. The AI will create a pending approval request that must be reviewed in the AI Risk Engine dashboard.

---

API Reference

Method	Path	Description
POST	/incidents	Create a new incident (or promote a finding, via sourceType/sourceRef)
GET	/incidents	List incidents (?status=&severity=&classification=&assignedTo=&startDate=&endDate=&page=&limit=)
GET	/incidents/feed	Unified feed of tracked incidents and EDR findings (?kind=&source=&orgId=&page=&limit=)
GET	/incidents/:id	Get incident with timeline, actions, and evidence
POST	/incidents/:id/close	Close an incident
GET	/incidents/:id/report	Generate incident report
POST	/incidents/:id/contain	Execute containment action
POST	/incidents/:id/evidence	Collect and attach evidence

All endpoints require authentication and are scoped to the caller’s organization.

---

Troubleshooting

Containment action stuck in pending. Containment actions are dispatched as agent commands. If the target device is offline, the action remains pending until the device reconnects. Check device connectivity.

Evidence upload rejected. The storage path must use an approved URI scheme (s3://, gs://, r2://, azblob://, immutable://, https://). Path traversal sequences (..) are blocked.

Cannot close incident. Only incidents in contained or recovering status can be closed. Progress the incident through containment before closing.

AI containment not executing. execute_containment is Tier 3 and requires human approval. Check Monitoring → AI Risk Engine → Approval History for pending requests.

Promoting a finding fails with “already promoted”. This is expected, not a bug — the finding has already been promoted to a tracked incident (by you or a teammate). Look for the existing tracked incident in the feed instead of promoting again.

Some users don’t see Huntress/SentinelOne findings in the feed. Seeing tracked incidents only requires permission to view alerts. Seeing raw EDR findings additionally requires permission to view devices, and findings are scoped to the sites a user has access to. If a technician is missing device permission or site access, they’ll see fewer rows than an admin looking at the same feed — this is expected.