What you’ll be able to do
- Explain how an Investigation & Response Intelligence System (IRIS) separates evidence gathering, model reasoning, human approval, and response execution.
- Walk a synthetic alert through evidence, finding, human decision, simulated action, and verification.
- Explain why prompt injection and chat messages cannot grant response authority.
- List a build-first sequence that starts read-only and stays honest about simulation.
A reference architecture for an Agentic SOC
An Agentic SOC uses software agents to gather evidence, propose findings, and prepare responses while humans keep authority over actions that change the world. IRIS stands for Investigation & Response Intelligence System. This educational reference architecture shows how to organize those responsibilities into components with clear boundaries. Use the lesson, the longer guide, and the runnable teaching model to explore the design through synthetic cases before building and validating your own integrations.
The earlier SOC lessons establish the human investigation loop. IRIS is a way to make that loop durable: cases do not live only in Maya’s head, evidence is stored with provenance, workers can crash and resume, and a model that reads attacker-controlled email cannot promote itself to firewall operator. OWASP’s prompt injection guidance is required reading before you let a model see ticket text.
Synthetic walkthrough: the Jordan Hale export
Intake opens case CASE-8821 from the 02:18 alert and deduplicates a second copy of the same identity event. Read-only connectors pull a page of identity-provider logs, a bounded TrackPort export log, and a coverage statement: “identity logs complete for 02:00–03:00; EDR not connected.” Investigation workers propose two hypotheses with citations. A human, Priya, authenticates to the case view, records “Jordan is not scheduled tonight” as a correction, and that evidence is stored as evidence, not as an approval to disable accounts.
A proposed action names target jordan.h, parameter disable, policy version 3, preconditions (no open restore job), expiry 60 minutes. A separately authorized response identity would execute only in a mock sandbox in this lesson. Verification looks for directory state and a failed canary export, not for a model saying “done.” If the worker crashes after a maybe-submitted disable, IRIS must reconcile instead of retrying blindly. All of those actions are simulated here.
- Chat participation is not approval authority.
- Connectors are read-only until a separately authorized executor exists.
- Coverage limits are part of the evidence, including truncated pages.
- Learning from the case does not auto-enable a new response play.
Build the smallest useful version first
Start with one use case, one read-only connector, durable case records, and a mock response adapter. Prove deduplication, crash recovery, approval expiry, and verification on synthetic data before connecting response tools to live systems. One optional platform mapping uses Amazon Elastic Container Service, Simple Queue Service, EventBridge, and Postgres. Evaluate those choices against your requirements for identity, recovery, observability, and cost. The teaching model runs locally without these services.
If you want the long-form architecture, component failure modes, and the example-bundle layout, continue to the IRIS capstone article. If you want the human skills, reread S1–S3. An agent that cannot explain missing evidence is worse than a tired analyst who can.
CHECK YOUR JUDGMENT