CLAWPOD ENGINEERING

How to Govern a Multi-Agent SOC Without an All-Powerful Agent

An operating design for an auditable agentic SOC built on separated authority, canonical case history, exactly-once effects, HumanDecision, and fail-closed recovery.

ClawPod Engineering · 10min read
REVIEWED BYEditorial Review · Security Architecture Review
Security analysts in a modern operations center review incident evidence and coordinate a bounded response

A Security Operations Center (SOC) is both an organization and an operating function that continuously collects security signals, detects threats, investigates evidence, coordinates authorized containment, verifies its effects, and closes incidents. It is not merely a dashboard or an alert-handling team. It combines people, process, and technology to carry responsibility from detection through real response and closure.

A human SOC and an Agent SOC have the same security mission and authority boundaries. Humans carry context through shifts, meetings, tickets, and expert judgment. Agents can continuously re-read canonical case history and execute bounded, repeatable handoffs. Agents do not remove human authority, however. When evidence, authorized scope, or execution outcome cannot be established, they must not guess and continue. They must fail closed.

Suppose a SIEM detects a suspicious source. A safe SOC does not jump from “an alert arrived” to “we blocked it.” It separates who interprets the evidence, who decides the block scope, which system changes the network, and who verifies the result and closes the incident. The three sections below explain SOC composition, its operating sequence, and the concrete attack-response journey.

1. SOC composition: separate operating roles from technical systems

This SOC design distinguishes roles by what they are forbidden to do, not merely by their names.

Component Responsibility Outside its authority
SIEM Detection, evidence, and canonical case history Changing network state
Service Desk Confirm intake, classify the case, route to an eligible role Declare maliciousness or authorize a block
Analyst Interpret evidence, record hypotheses and scope, propose action Execute an external effect or certify its own analysis
Action Executor Validate authorized scope and request an effect with stable execution identity Make a new threat judgment or expand scope
Action Provider / Enforcement Point Apply the approved effect to the control plane and report an outcome Interpret the incident or close the case
Reporter Re-read the record, reconcile evidence, authority, and effect, then close or request Correction Infer missing evidence or manufacture an execution result
Leader Validate organizational routing, role eligibility, and HumanDecision linkage Act as a shadow Analyst, Executor, or closer
Operator Restore platform health, including workers, queues, and connectivity Decide incident meaning, authorize containment, or close the case

A HumanDecision is not simply a human reply. It is an authorization object binding the original request identity, case revision, target and scope digest, and the person’s explicit decision, with the result recorded and read back. A Correction is not a rewind that overwrites history. It is a new, bounded transition correcting analysis or record state. Correction does not itself grant authority to execute again.

The following generic journey contains a suspicious source without exposing a real address, threshold, detection rule, provider, or production topology.

flowchart TD
  S[SIEM detection<br/>and evidence] --> D[Service Desk<br/>intake and routing]
  D --> C[Canonical case<br/>history]
  C --> A[Analyst<br/>meaning and scope]
  A --> H{Authority path}
  H -->|Human judgment needed| L[HumanDecision<br/>Leader validates linkage]
  H -->|Pre-authorized scope| X[Action Executor<br/>validates scope and identity]
  L --> X
  X --> P[Action Provider and<br/>Enforcement Point]
  P --> R[Record outcome<br/>and read back]
  R --> Q[Reporter<br/>independent reconciliation]
  Q -->|Requirements met| Z[Close]
  Q -->|Mismatch| K[Correction or<br/>bounded recovery]
  O[Operator<br/>platform-health support] -. no incident judgment .-> C
  linkStyle default fill:none,stroke:#64748b,stroke-width:1.5px

The Service Desk checks the alert identity and record state, then routes the case to an Analyst. The Analyst reads the SIEM evidence and records more than “this source is malicious”: observations, alternative hypotheses, target scope, and a proposed action belong in the case. Ambiguous evidence, uncertainty about a protected target, or scope outside existing authority stops the path before execution.

If the action is inside a narrow pre-authorized boundary, the Action Executor checks the revision, target, action, expiry, and effect identity. Otherwise, it requires a scope-bound HumanDecision. The Leader may verify that an eligible person and the original request are correctly linked, but does not invent the decision.

The Executor sends the approved request to an Action Provider, and an Enforcement Point changes state. A response receipt alone is not success. The provider’s operation identity and applied state must be read back and appended to the case. The Reporter then re-reads the SIEM history from the beginning and reconciles the analytical basis, authority scope, provider outcome, and enforcement confirmation. Only a complete match permits closure. A mismatch enters Correction or bounded recovery.

The Operator remains outside this decision chain. It may recover a stalled queue, failed worker, or broken connection. Restored platform health does not prove that containment was correct or successful. Letting the Operator take case ownership and decide incident meaning would erase the authority boundary.

The figure below shows how those separated roles form a closed response loop in real infrastructure. Perimeter controls and server protection feed logs into the SIEM. After detection and analysis, the AI SOC can request only authorized initial containment through an Action Provider. FW, WAF, IPS, and EDR Enforcement Points change the actual state, and the applied result must be read back before the case advances.

Defense layers from the internet through firewalls, routers, IPS and IDS, switches, web firewalls, and DMZ and internal server farms feed logs to SIEM; AI SOC applies authorized containment through an Action Provider and actual Enforcement Points, then reads back the applied state
Closed AI SOC infrastructure loop for log collection, authorized policy application, actual enforcement, and read-back

2. SOC operating sequence: from alert intake to closure or Correction

The full operating sequence is alert intake → Canonical Case creation and history → analysis → authority record → conditional handoff → execution → read-back → closure or Correction. The control plane in this design is the SIEM’s canonical case history, not a chat room. The SIEM detects activity and preserves evidence, case state, and transition history. Separately authorized Action Providers and Enforcement Points change network or security state. Keeping the record system separate from the effect system prevents “what we know” from becoming confused with “what we changed.”

At minimum, the case record needs:

  • stable alert and case identities;
  • references to source evidence and analysis results;
  • the current stage, owning role, and revision or version;
  • authorized targets, actions, scope, and expiry conditions;
  • transition history that does not erase prior states; and
  • execution intent, effect identity, provider outcome, and read-back evidence.

Work evidence is analysis, authority, or an execution result that has been appended to the canonical record and independently read back. Transport evidence is a delivery trace, such as a chat message, email, or webhook, that tells an actor where to look. Message arrival does not prove work completion. One webhook delivery does not mean one effect.

Treat the handoff itself as a verifiable transaction. A role reads the current version, appends its result or intent, and reads it back independently. It then transfers ownership conditionally against the expected version and owner, and verifies that the transition took effect. A conflict preserves the current state and stops the flow. The final locator signal is a convenience, never authority.

flowchart TD
  A[Alert intake] --> B[Canonical Case<br/>creation and history]
  B --> C[Evidence analysis and<br/>proposed response scope]
  C --> D{Is the authority<br/>record valid?}
  D -->|Yes| E[Conditional handoff by<br/>revision and owner]
  D -->|No| F[Fail closed<br/>await human judgment]
  E --> G[Execute within<br/>authorized scope]
  G --> H[Append outcome and<br/>independent read-back]
  H --> I{Do evidence, authority,<br/>and effect agree?}
  I -->|Yes| J[Close incident]
  I -->|No| K[Correction or<br/>bounded recovery]
  K --> B
  linkStyle default fill:none,stroke:#64748b,stroke-width:1.5px

3. Attack-response sequence: from security signal to real block

A concrete response proceeds as sensor and log collection → SIEM detection → evidence correlation → block-scope decision → real network-control-layer block → result verification → incident closure. “We sent a block request” is not the same as “the network block is applied.”

flowchart TD
  S[Sensors and logs<br/>collect security signals] --> I[SIEM detection and<br/>case linkage]
  I --> E[Correlate evidence<br/>check impact and false positives]
  E --> B{Decide and authorize<br/>target, scope, and expiry}
  B -->|Authorized| P[Action Provider<br/>translate control request]
  B -->|Unclear| F[Fail closed<br/>human review]
  P --> N[Enforcement Point<br/>real network-layer block]
  N --> R[Verify applied state and<br/>operation identity]
  R --> Q{Do detection, authority,<br/>and effect agree?}
  Q -->|Yes| Z[Close incident]
  Q -->|No| C[Correction or<br/>effect reconciliation]
  linkStyle default fill:none,stroke:#64748b,stroke-width:1.5px

When endpoint sensors and gateway logs identify the same suspicious source, the SIEM links the alert and source evidence to the Canonical Case. The Analyst correlates timing, target assets, other signals, and false-positive possibilities, then proposes which source to block, at which control point, and for how long. Once scope is authorized, the Executor calls the Action Provider with a stable effect identity. An Enforcement Point such as a firewall or gateway applies the block in the real data or network control layer.

A response timeout is not a failure. The first request may already have taken effect, so the flow does not repeat it automatically. It reads back provider and Enforcement Point state to distinguish confirmed success, confirmed failure, and Possible Effect. The Reporter reconciles the detection basis, authorized scope, operation identity, and observed applied state, closing only when they agree. If the outcome is unclear, automatic retry and closure remain blocked until state is reconciled or new authority is granted.

Exactly-once effect discipline, not exactly-once delivery

Delivery can be retried in a distributed system. The goal is therefore not a promise that a webhook arrives exactly once. It is exactly-once effect discipline: identify the same authorized effect across duplicate delivery and either deduplicate it or reconcile its observed state.

A stable execution identity combines elements such as:

case identity + transition identity + action + target
+ authorized revision/scope + idempotency or provider operation identity

Before execution, the Executor checks whether that identity already has a confirmed outcome. After a request, it distinguishes three states.

flowchart TD
  A[Authorized effect] --> B[Provider outcome]
  B -->|Confirmed success| C[Record effect identity<br/>read back, then advance]
  B -->|Confirmed failure| D[Bounded recovery<br/>evaluate retry conditions]
  B -->|Timeout or unknown| E[Possible Effect<br/>block automatic retry]
  E --> F[Reconcile provider state<br/>or obtain new authority]
  D --> G{Retry authority and<br/>safe conditions met?}
  G -->|Yes| A
  G -->|No| H[Preserve and stop]
  linkStyle default fill:none,stroke:#64748b,stroke-width:1.5px

Confirmed success records the effect identity and read-back evidence before advancing. Confirmed failure records the cause and evaluates whether the existing authorization included bounded retry. Unknown or Possible Effect is the dangerous state. A timeout is not a failure. The first request may already have changed state, so automatic retry must remain blocked until the provider state is reconciled or new authority is granted.

This discipline does not guarantee exactly-once network delivery. It is an operating rule for deciding safely from effect identity and observed state despite duplicate requests, worker restarts, or delayed responses.

Correction is not rewind, and email is not authorization

If the Analyst misclassifies a target, the prior record should not be edited away. A new Correction states which conclusion changed, why it changed, and which downstream state needs review. If an effect already occurred, “correct the analysis” and “authorize a reversal” are separate decisions. Automatically executing the inverse action can create a second incident.

Human judgment must also remain separate from its transport. Successful email delivery, message opening, a reply, a thumbs-up in chat, or silence is not authorization by itself. A valid HumanDecision binds the original request identity and revision, exact scope, responding principal, explicit decision, and recorded time, then becomes readable from the canonical case. If scope or revision has changed, the old response cannot be reused.

Fail closed, then recover from evidence

A safe SOC does not keep moving under every condition. It should fail closed when:

  • case version or ownership differs from the expected state;
  • evidence is missing or target scope is ambiguous;
  • protected-target status or authorization scope cannot be established;
  • a HumanDecision cannot be reliably bound to the original request;
  • the provider outcome is unknown and a Possible Effect cannot be excluded; or
  • the execution result or ownership transition cannot be read back.

A stop is not the end of the process. It is an explicit recovery state. The recovery record should state what is currently known, which effects may already have occurred, why the flow stopped, and the exact condition for safe resumption. A fast path does not remove these boundaries. Priority and pre-authorized scope can change, but effect identity, read-back, and independent closure verification remain mandatory.

The public ClawPod Guide describes agents configured with roles, credentials, skills and tools, and organization policy boundaries. That is general context for implementing separated roles. It does not mean that the SIEM, Action Provider, compare-and-set ownership, HumanDecision binding, exactly-once effect handling, or Reporter flow in this article are all generally available ClawPod capabilities. A function visible in a runtime is also not automatically a supported customer product path; deployment and permission context must be verified separately.

Six questions for an architecture review

  • Can every role reconstruct its work by re-reading one canonical case history rather than trusting conversation?
  • Are evidence interpretation, effect authorization, execution, and success attestation separated by authority boundaries?
  • Does every handoff require append, read-back, conditional ownership transfer, and final verification?
  • Does a stable effect identity detect duplicates and block automatic retry after an unknown outcome?
  • Are Correction and HumanDecision bound to identity, revision, and scope, and separated from re-execution authority?
  • Does the system fail closed under conflict or uncertainty and record known state, possible effects, and safe-resume conditions?

If any answer is no, design that boundary before adding more agents. More agents may increase throughput, but they do not create governance automatically. They become valuable when each role has enforceable limits and every decision and effect can be reconstructed from the canonical record.

Sources