SIRIWAIT — Security Incident Response Investigations With Agentic Intelligence Tools¶
- Product: Security Incident Response Investigations With Agentic Intelligence Tools
- Family: Security Analyst Toolset
Objective¶
Provide a shared, git-based repository structure for active security incident investigations where multiple responders and their AI agents collaborate in real-time — producing, sharing, and building on investigative artifacts during live incidents.
Context¶
During active security incidents, multiple people run their own AI agents (Bits, Claude, etc.) to investigate different facets — log analysis, IOC correlation, blast radius assessment, timeline reconstruction. Currently, each person's agent context is siloed. There's no shared workspace where one responder's agent-generated findings feed into another's investigation.
SIRIWAIT provides that shared workspace as git repositories — version-controlled, auditable, and structured so both humans and agents can produce and consume artifacts collaboratively during an active incident.
Tools In Use¶
- GitHub (repository hosting, collaboration, PR workflow)
- Kiro (primary AI agent for investigations)
Scope¶
In scope¶
- Repository structure/template for incident investigations
- Conventions for agent-generated artifacts (reports, timelines, IOC lists, queries)
- Multi-agent collaboration patterns (how agents discover and build on each other's work)
- Repo-per-incident or branch-per-incident lifecycle management
- Artifact retention and archival post-incident
Out of scope¶
- Building new AI agents (uses existing agents)
- Replacing incident response tooling (PagerDuty, Datadog Incident Management)
- Real-time chat/communication (complements Slack, not replaces it)
Risks¶
| Risk | Likelihood | Impact | Mitigation |
|---|---|---|---|
| Sensitive data committed during incident (credentials, PII) | High | High | Secret scanning, .gitignore templates, ephemeral repos with short retention |
| Repo sprawl from frequent incidents | Medium | Low | Automated archival/cleanup lifecycle |
| Agents producing conflicting or duplicative artifacts | Medium | Medium | Structured directory conventions and artifact naming |
| Latency of git workflow slows incident response | Low | Medium | Agents push directly to branches; review happens post-incident |
Success Criteria¶
Not yet defined. Success criteria depend on the structural decisions in Open Questions (repo topology, artifact conventions, discovery mechanism, retention, access control), which the project team will settle at project initiation.
Open Questions¶
The questions below are deliberately unresolved and are for the project team to answer when the project is initiated.
- One repo per incident, or a monorepo with branches/directories per incident?
- Who creates the repo — automated on incident declaration, or manual?
- What artifact formats should agents produce? (Markdown reports, JSON IOCs, YAML timelines?)
- How do agents discover what other agents have already produced? (convention-based file paths? index file?)
- Retention policy — how long do incident repos live before archival?
- Access control — all responders get write, or per-incident team scoping?
- Where is the boundary with MACP? Both provide a shared surface for multiple agents working one investigation — SIRIWAIT as git-tracked artifacts, MACP as a queryable findings/entity store. Do both get built, or does one absorb the other?
Decisions¶
| Date | Decision | Rationale |
|---|---|---|
| — | — | — |
Changelog¶
| Date | Status | Change |
|---|---|---|
| 2026-06-17 | draft | Initial draft |
| 2026-07-24 | planned | Status active → planned: the product is registered but no work has started |
| 2026-07-24 | planned | Review pass: replaced the empty success criteria with an explicit deferral to project initiation; noted that the six structural questions are for the project team; added an open question on the boundary with MACP; removed duplicated status and product-key lines from the body |