Autonomous SOC & incident response — architecture blueprint

A SOC has three jobs after something fires: work out what is really happening (triage and investigation), stop it spreading (containment), and put things back (eradication and recovery). Agents are genuinely good at the first job — it is pattern-matching over large volumes of telemetry under time pressure, which is exactly where a tireless reader helps most. The middle job is safe to automate only for reversible actions on a confirmed, bounded scope. The last job is not safe to automate at all.

Eradication means removing persistence, rotating credentials at scale, and rebuilding systems; recovery means declaring the threat gone and restoring connectivity. Both are high blast radius, both are hard to walk back, and both depend on a judgement call — "are we actually clean?" — that an agent should inform but not make. A premature "all clear" that re-enables a compromised account or reconnects an un-eradicated host turns one incident into two.

This is the same rule this project's own AGENT.md runs under — "anything irreversible, legally gray, or strange → write it down and wait" — applied to incident response: automate the reversible reads and the reversible holding actions, keep a person on the irreversible ones.

Every detection, decision, and action lands in one place: the SIEM for the telemetry and the alerts, the SOAR / case-management layer for the incident record, its state, and its timeline. The agents do not keep their own parallel notion of "what is going on" — the case in the SOAR platform is the shared state, and it is a projection of an append-only stream of observations and actions (the same model the coordination protocol uses for ticket state).

Practically that means: alerts arrive as events, the triage agent groups them into a case, every subsequent agent reads and writes that case, and the human gate approves or denies against the case as it stands at that moment. There is no side channel. If it is not in the case timeline, it did not happen.

Detection sources feed the SIEM/SOAR; the orchestrator scores and scopes, then routes to the eight SOC agents. The supporting-systems band is colour-coded by category (see legend). Every agent and the gate write append-only entries to the case timeline, teed to an external audit log (omitted above for clarity). The orchestrator holds no response credentials itself — only the containment and identity agents do, leased just-in-time per action. The dashed SOC-ops box supervises the framework and its detection coverage; it is not a ninth agent with response authority.

Each agent owns one function of the response pipeline. As with the service-desk design, every agent can read, enrich, and propose without limit; only two of them (containment, identity) can act on a production system, and only on a plan that already cleared the severity gate.

Note what is absent: there is no agent that performs eradication (removing persistence, rebuilding, estate-wide credential rotation) or recovery (declaring clean, restoring connectivity). Those are human workflows the agents feed, not automate — see the three gates, below.

The blue spine is the happy path. The two diamonds are the only places the flow branches: an auto-close for known-benign noise, and the severity gate that decides whether containment runs autonomously or waits for a person. Eradication and recovery are always human-owned. A containment action that fails its effect check re-scopes rather than proceeding.

Severity here is not "how bad does the alert look" — it is "how much blast radius does an autonomous response carry, and how reversible is it." That is what decides whether an agent acts alone.

The deny-list below sits above every rung — those actions are never agent-executable regardless of severity or who approves.

A fixed deny-list sits above all four severities and applies no matter who approves:

• No automated isolation of domain controllers, core network devices, or hypervisor hosts.
• No automated mass account disable or mass password reset above a small fixed threshold.
• No automated block of a business-critical destination (payment processor, cloud control plane, DNS root) without a human.
• No automated wipe or reimage of any system before evidence is preserved.
• No automated change to the SIEM/SOAR, the logging pipeline, or the detection content in production — a compromised agent must not be able to blind the SOC.
• No automated external notification — regulators, customers, law enforcement, and press are always a human decision.

The three response phases are governed differently on purpose. The difference is reversibility.

The containment gate is the only one an agent can pass on its own, and only for reversible actions on a bounded scope. Everything past it is a person's call.

Autonomous response earns its scope one phase at a time, against evidence from the phase before it — not by being switched on at full trust on day one.

Eradication, recovery, and the deny-list do not move across these phases. What widens is the set of reversible containment actions the agents may take unattended, and the severity ceiling under which they may take them.

• Reversible containment first. Given a choice, the agent takes the action it can undo — isolate a host rather than wipe it, disable an account rather than delete it, block at the proxy rather than at the firewall core.
• Least-privilege response. Each agent holds only the response API scopes its function needs; credentials are leased just-in-time from the vault per action and expire immediately after.
• Blast-radius precondition. A containment action re-reads the current confirmed scope immediately before it fires. If investigation has narrowed the scope since the plan was made, the action narrows with it; if it has widened past a threshold, the action stops and re-escalates.
• Immutable case timeline. Every observation, decision, and action is hash-chained and written to a store outside the managed estate, so a compromised agent cannot rewrite the record of what it did.
• Circuit breakers per target. Repeated failed or blocked response actions against one system trip a breaker: further actions against that target require a human until it is manually reset.
• A kill switch. One control halts all autonomous response and reverts the framework to advise-only. It is tested on a schedule, not left as a theoretical capability.
• Analyst override, always. Any in-flight autonomous action can be cancelled by a person, and every autonomous action is surfaced in the queue as it happens — not buried in a log to be found later.

An incident that closes without improving detection is a half-finished incident. Every closed case runs through three questions, and the detection-engineering agent drafts the change for whichever ones apply:

• Should something have fired earlier? If the timeline shows activity that no rule caught, draft a detection for it.
• Did something fire that shouldn't have? If the case was noise, draft a tuning or suppression — scoped tightly, never a blanket mute.
• Was there a coverage gap for this technique? Map the case to ATT&CK and check whether that technique is covered elsewhere in the estate.

Each drafted rule is backtested against historical events, carries an estimated false-positive rate, and cites the incident that motivated it. It is then submitted to the gate as a change a human approves — a bad detection either floods the SOC or blinds it, so detection content is never edited autonomously. Rules are versioned and every change is reversible.

1. Alerts fire. Email security flags a user who clicked through to a lookalike domain; the IdP then reports an impossible-travel sign-in for the same account; EDR is quiet. The triage agent groups the two alerts into one case at Sev 3.
2. Enrichment re-scores it. The account belongs to a finance-team member with access to the payment portal; the sign-in is from a hosting-provider ASN; a mailbox rule was just created to auto-forward and delete inbound mail. The enrichment agent raises the case to Sev 2.
3. Intel attributes it. The threat-intel agent matches the lookalike domain and the forward-and-delete rule to a known business-email-compromise campaign (ATT&CK T1114.003, T1078).
4. Investigation bounds it. The investigation agent builds the timeline: credential entry → token minted → mailbox rule created → two outbound emails to accounts-payable staff referencing a wire-transfer change. Confirmed scope: one identity, one mailbox, two sent messages. No endpoint compromise, no lateral movement.
5. The orchestrator assembles a containment proposal: revoke the user's refresh tokens and sessions, force a password reset, delete the mailbox rule, quarantine the two sent messages recipient-side, and block the lookalike domain at the proxy. Every action is reversible — but the case is Sev 2, so it routes to the incident-commander gate as an approval request carrying the full timeline and the exact action list.
6. A person approves with one addition — also revoke a standing app-password on the account. The containment agent and identity-response agent execute via just-in-time credentials; every step is written to the case timeline and teed to the audit log.
7. Verify. Sign-ins with the old token now fail; the mailbox rule is gone; the two messages are quarantined. The eradication gate (human): a hunt sweep across mail logs for the lookalike domain finds two more recipients who opened it but did not enter credentials — folded into the case, no further compromise.
8. Recover. The recovery gate (human) re-enables the account only after the user re-enrols MFA on a managed device, and sets a 14-day elevated-monitoring watch. The case closes.
9. Detection feedback. The detection-engineering agent proposes a correlation rule — "credential-phish alert plus a new auto-forward-and-delete mailbox rule within one hour" → auto Sev 2 — backtested at roughly 0.3 false positives per week, and submits it to the gate.

• Service desk architecture — the sibling design for IT operations. Same shape: a system of record, an orchestrator, domain/function agents, and one mandatory human gate. This page is that pattern applied to detection and response instead of change and request.
• Agent-to-agent coordination protocol — the wire format between the boxes in the architecture diagram above: the message envelope, the closed message-type set, the synchronous audit tee, and the rule that only the orchestrator advances a case's state.
• Operations model & SOP — the human-side procedures. Where this page says "the incident commander approves containment," the SOP defines who holds that role, the on-call rotation, and the major-incident comms process.
• Integration guide — setup and API detail for the supporting systems, including the EDR, SIEM, secrets vault, and backup platform this architecture leans on.

This is an architecture blueprint, written the way a design should be written before anyone connects an agent to a live response API: the shape of the pipeline, the trust boundaries, and the checkpoints, worked out on paper first. It is deliberately not a running SOC. This box has no SIEM, no EDR tenant, no identity provider to defend, and no response tooling — and even with them, standing up autonomous write-access to isolate hosts, kill sessions, and disable accounts across a real estate is a decision the estate's owner makes deliberately, with scoped credentials and their own incident-command process wrapped around it. That process is what the human gate on this page is designed to plug into, not replace.

More to go with the blueprint above, all free, no signup:

• Service desk architecture — the companion design for autonomous IT operations, with the full domain-agent taxonomy, risk-tier model, and deployment guide.
• Agent-to-agent coordination protocol — the message envelope and delivery guarantees the agents on this page use to coordinate.
• Operations model & SOP — roles, on-call, incident response, and review cadence for running a framework like this day to day.
• Integration guide — setup steps, API auth, and a working MCP server for each supporting system.