Threat-Detection Platform Architecture with Claude Code

Most security teams drown in signal. A mid-sized SOC can see millions of raw events a day, and the alerts that actually matter are buried under thousands that don't. The traditional answer is a sprawl of correlation rules that turn brittle the moment an attacker shifts one byte of behavior. A more interesting answer in 2026 is to put a reasoning agent in the loop — one that can read logs, pull context from your existing tools, decide whether a sequence of events is genuinely hostile, and hand a tight, evidence-backed case to a human analyst. This post walks through how the internals of such a platform fit together when Claude Code is the reasoning engine underneath it.

I'll keep this architectural rather than aspirational. The goal is to expose the seams — where data enters, where the model reasons, where tools get called, and where humans stay in control — so you can see how the pieces connect end to end rather than as a marketing diagram.

The shape of the system: four planes

It helps to think of a Claude Code threat-detection platform as four planes stacked on top of each other. The ingestion plane normalizes raw telemetry — endpoint logs, network flows, identity events, cloud audit trails — into a consistent event schema. The reasoning plane is where Claude Code runs as an agent, deciding what to investigate and which tools to call. The tool plane is a set of MCP servers that expose your SIEM, threat-intel feeds, asset inventory, and ticketing system as callable capabilities. The governance plane wraps all of it with audit logging, rate limits, and the human approval gate.

The reason to separate these cleanly is that each plane has a different failure mode and a different owner. Ingestion fails loudly and cheaply; the reasoning plane fails subtly and expensively (a wrong verdict on a real intrusion). By keeping the model's reasoning isolated from the raw firehose, you can swap detection logic without touching pipelines, and you can replay any decision later because the reasoning plane only ever sees a curated, versioned slice of the event stream.

Why an agent instead of a rules engine

A rules engine answers one question: does this event match a pattern I was told about in advance? An agent answers a harder one: given everything I can fetch right now, is this behavior consistent with an attacker's goal? A threat-detection agent is a system that uses a language model to reason over security telemetry, autonomously gather supporting context through tools, and produce an explained verdict that a human can audit. That definition matters because it draws the line between automation that merely fires faster and automation that actually investigates.

Claude Code is a natural fit here because it was built as an agentic harness, not a chat box. It runs subagents in parallel, loads Agent Skills dynamically when a task calls for them, connects to external systems through MCP servers, and works inside a large context window — enough to hold an alert, the surrounding events, and the intel it pulls without constant truncation. In practice that means one orchestrating agent can fan out several investigations at once, each subagent chasing a different hypothesis, then reconcile their findings.

flowchart TD
  A["Raw telemetry: EDR, network, identity, cloud"] --> B["Ingestion plane: normalize & dedup"]
  B --> C{"Candidate alert?"}
  C -->|No| H["Drop / archive"]
  C -->|Yes| D["Claude Code orchestrator"]
  D --> E["Subagents call MCP tools: SIEM, intel, asset DB"]
  E --> F["Reasoning: build evidence chain & verdict"]
  F --> G{"Confidence > threshold?"}
  G -->|Auto-contain| I["Governance gate logs action"]
  G -->|Needs review| J["Human analyst confirms"]

How a single investigation flows

Picture a candidate alert: a service account authenticated from a new country, then enumerated several storage buckets. The ingestion plane has already normalized those into events and flagged the pair as worth investigating. The orchestrator receives this minimal seed — not the whole log, just the trigger and identifiers — and decides what it needs to know.

It spawns subagents. One queries the identity MCP server for that account's normal login geography over the last 90 days. Another asks the asset-inventory server what those buckets contain and how sensitive they are. A third checks a threat-intel server to see whether the source IP appears in any recent campaign. Each subagent returns structured findings, not prose, so the orchestrator can weigh them. The model then assembles an evidence chain: anomalous geography plus access to high-sensitivity assets plus a known-bad IP equals a high-confidence verdict; any one of those alone is weaker. This is the part a rules engine struggles with — the weighting is contextual, and the context was fetched at investigation time, not hard-coded last quarter.

The governance plane is not optional

The moment an agent can take action — disable an account, isolate a host, open a ticket — you need a governance plane that no investigation can bypass. Every tool call routes through it. It enforces which actions are auto-approved (read-only lookups, enrichment) versus which require a human (containment, credential revocation). It writes an immutable audit record of every prompt, tool call, tool result, and final verdict, so a later review can reconstruct exactly why the agent did what it did. And it applies rate and cost limits, because multi-agent runs consume several times more tokens than a single-agent pass and a runaway investigation loop is both a budget problem and a denial-of-service risk against your own MCP servers.

A useful design principle: the agent proposes, the governance plane disposes. Claude Code is excellent at proposing a containment plan with reasoning attached. Whether that plan executes automatically depends on policy you encode outside the model, keyed on asset sensitivity and confidence. High-confidence action on a low-value test host can auto-execute; the same action on a production database should always wait for a human click.

State, memory, and replay

Threat detection is rarely one-shot. An attacker's behavior unfolds over hours, and an investigation may need to remember what it concluded an hour ago. The architecture handles this by persisting each investigation as a durable case record — the seed, every tool result, the evidence chain, and the verdict — outside the model's context window. When new events arrive that match an open case, the orchestrator reloads the case summary (a compact digest, not the raw transcript) and continues. This keeps context lean while preserving continuity, and it gives you something invaluable: the ability to replay a historical case against an updated agent to see whether your detection logic improved.

Frequently asked questions

Does the agent replace my SIEM?

No. The SIEM remains your system of record and your fast, deterministic correlation layer. The Claude Code agent sits above it as an investigation layer, fetching from the SIEM through an MCP tool and reasoning over what it returns. You get the SIEM's speed and the agent's judgment, not one instead of the other.

How do you keep the model from acting on bad data?

You separate reasoning from action with the governance plane, and you make every verdict carry its evidence chain. Because the model must cite the specific tool results that justify a verdict, a reviewer can spot when a conclusion rests on a single weak signal and reject it before any action runs.

Is a multi-agent design worth the extra cost?

Often, for genuinely ambiguous alerts where several independent lines of evidence need chasing in parallel. For clearly benign or clearly malicious events, a single agent — or even a rule — is cheaper and just as good. The architecture should route easy cases away from the expensive path.

Bringing agentic AI to your phone lines

CallSphere takes these same architectural ideas — orchestrators, tool calls mid-task, and a human-controlled action gate — and applies them to voice and chat, so every call and message is answered, enriched, and acted on around the clock. See it working at callsphere.ai.

Source & attribution: This is an independent, original explainer inspired by Anthropic's coverage on the Claude blog. Claude, Claude Code, Claude Cowork, Claude Opus, and the Model Context Protocol are products and trademarks of Anthropic. CallSphere is not affiliated with or endorsed by Anthropic.