One Case, Not a Swarm: Organizing the AI SOC

Series: Building the Agentic SOC – Part 3

The Same Attack, Four Alerts

Go back to the Part 2 attack and count what it lit up. A management Lambda whose code and configuration were modified and then invoked. A burst of twelve thousand bucket-name guesses against S3. A flood of access-key creation calls hammering IAM in a brute-force pattern, with new keys appearing on several users. And, at the end, a normally quiet identity suddenly enumerating IAM, S3, Secrets Manager, and SSM. Four kinds of detection, on different resources, spread across the same half hour.

They are not four problems. They are four fragments of one attack: a single stolen key, a single chain from a hijacked Lambda to a brute-forced admin identity. Everything in this part follows from taking that seriously.

So you reach for the tool you now have. You have agents, so you wire one to every alert: an alert fires, an investigation agent spawns, digs in, reports. Four alerts, four agents, all at once. It feels like exactly what agents are for. It is worth being precise about why it is not.

Why Agent-Per-Alert Fails

• Duplicate work. Each agent starts from its own alert and works outward, and because they are all downstream of the same actor, they keep arriving at the same place. The agent on the Lambda tampering pulls the function, its execution role, the principal that modified it, the recent history. The agent on the access-key brute-force pulls the same principal, the same history. So does the agent on the anomalous enumeration. You pay for the same investigation three or four times, and none of the copies is more complete than the others.
• No shared record of what's been done. This is the expensive one, and it is not that the agents are blind. Each one pulls the related logs and rebuilds the chain for itself, and the later an agent starts, the more of the picture it can see. What none of them has is a shared record of what the others concluded and, worse, what the others already did. There is no single case file that says this verdict is reached, this key is disabled, this Lambda is reverted. So no agent can trust what another has settled, and none can build on it. They are four investigators working the same case with four private notebooks and no shared file. Each can work out on its own that this is one actor. None of them can see what the others already decided or did about it.
• Uncoordinated response. Now give them the power to act, and the missing case file turns costly. By the time the last alert fires, the agent handling it can see the earlier steps, so it works the whole chain and tries to respond to every part of it: disable the key, revert the Lambda, disable the forged key. But the earlier agents already took those actions. This one spends its time re-issuing responses that are already done, watching them fail, and it cannot tell whether a failure means "someone already handled this" or "this genuinely did not work." Nobody is tracking which actions have been taken, or by whom. Multiply that across every agent and you get wasted effort, a response state nobody can read, and the standing risk that two of them reach for different actions on the same resource at once.
• Cost scales with the attacker's noise. You pay your AI vendor per investigation. Four alerts, four investigations. A louder attack throws more alerts and you spawn more agents, each fully investigating what is still one incident. The attacker sets your bill, and the worse the attack, the more you overpay to look at it four, ten, twenty times.

None of these are bugs you can patch. They follow directly from making the alert the unit of work.

The Alert Is Not the Unit. The Case Is.

The reframe is small to state and changes everything: the thing you investigate is the case, not the alert. Before you spend a single investigation, you assemble the one case out of the four fragments. Four alerts become one case, with one actor, one timeline, one blast radius. Then you investigate that, once.

This is not a new idea. It is what a good analyst does when they recognize that four tickets are the same attacker and merge them, and it is the highest-value work in the room. The problem was never that humans cannot do it. It is that at this attack's speed, no human gets the chance. The point of building it with agents is to do that correlation continuously and instantly, not to skip it.

So the first job of an AI SOC is not investigation. It is assembly: turn a stream of alerts into a small set of live cases, and keep them current as new alerts arrive.

A Few Roles, and a Chain of Command

Once the case is the unit, you do not want N identical general-purpose agents. You want a small set of roles with a clear chain of command. Two of them run the case. The rest work it.

Start with the two that most designs leave implicit, and pay for leaving implicit:

• Dispatcher. The intake, and the first thing that moves when any alert fires. Its only job is routing: does this alert belong to a case that already exists, or does it start a new one? It does not investigate. It links, or it creates. Get this one decision wrong under load and a single attack becomes four half-cases that each think they are the whole story.
• Case leader. Once a case exists, one leader owns it, start to finish. It spawns the worker agents below and coordinates them, holds the shared case state so two of them never act on the same resource blindly, and keeps watching the case after it is opened. When the dispatcher links a new alert into a case that is already being worked, the leader is the one that decides what that change means and folds it in. One case, one owner.

Under the leader sit the workers, each doing one job well:

• Triage. Assesses the case: is this malicious, how confident, how severe? Its output is a verdict with reasoning, and it sharpens that verdict as evidence accumulates.
• Investigation. Reconstructs the chain. Given the case, it works out what the actor did, in what order, and how far it got, and pulls the context each step needs. It runs once per case, not once per alert.
• Hunting. Looks outward from the case for what the alerts missed: the same principal touching other resources, the same technique elsewhere, the quiet steps that never tripped a detection.
• Response. Acts, within limits set in advance. That is the whole subject of Part 4, so here I will only place it: response operates on the case, with a bounded set of actions and a clear line where it stops and asks a human.

These are roles, not copies. The dispatcher routes, the leader owns and coordinates, the workers each do one thing well.

What Makes It Work: Shared Context

Specialized skills only help if they share what they know. Give each its own private view and you are back to the swarm with fancier titles. What holds it together is a common substrate every skill reads from and writes to: one model of the case, sitting on one model of the environment.

The case model is the live incident: which alerts belong to it, the reconstructed timeline, the resources and identities involved, what is confirmed, what has been done. The dispatcher opens it or attaches an alert to it, the leader maintains it, triage assesses it, investigation enriches it, hunting extends it, response records against it. No agent starts blind.

The environment model is the deeper one, and it is the thread back to Part 1. To reconstruct an attacker's chain you have to know what the environment actually is: which identity can assume which role, which Lambda runs as what, which host reaches which data, how the pieces connect. That is the same map the Security Architect holds. In an AI SOC that map is not documentation, it is a live data structure the agents reason over. Stream.Security calls its version CloudTwin, a unified model of identity, runtime, network, and configuration. Without a shared model of the environment, "correlate these four alerts" is a request no agent can fulfill, because correlation is a statement about how the environment connects, and nothing else holds that map.

The Hard Part: Cases That Change While You Investigate

Here is the piece that looks simple in a diagram and is genuinely hard in practice, and it is pure architecture.

Assembly is not a one-time sort. Alerts arrive continuously, and they arrive out of order and late, because different logs land at different speeds. So when an alert comes in, the first question is never "investigate this." It is "does this belong to a case that already exists?" If it does, it attaches to that case, and the agents working the case pick it up. If it does not, it opens a new one. Getting that decision right, every time, under load, is the difference between one coherent case and four half-cases that each think they are the whole story.

Now the genuinely hard version, and it is the case leader's problem. Investigation is halfway through a case, building the timeline, closing in on a response, when the dispatcher links a new alert into that same case. The new alert might change the picture completely: it might be the step that reveals a persistence backdoor, or the one that proves the actor already reached data. What does the leader do with its in-flight investigation? Let it finish and risk acting on a stale picture? Kill it and restart, and pay for the investigation twice? Fold the new evidence in mid-flight without losing what it has done? Each choice is a real design with real failure modes: stale decisions, wasted spend, race conditions where two updates to the same case collide.

There is no default answer the vendor ships that is right for every environment. How aggressively the leader re-opens a case, how long it waits for late-arriving logs before it lets a decision stand, when a change is big enough to force a fresh investigation instead of an update, how it keeps two workers off the same resource at once: these are decisions someone has to make deliberately, and they depend on knowing the environment, the log sources, and their timing. That someone is the architect. The concurrency of the case model is not an implementation detail. It is a security design decision, because a case that updates badly is a case that acts on the wrong picture.

What This Buys You

Run the Part 2 attack through this instead of the swarm. The four alerts arrive over a few minutes and attach to one case as they land, correlated by the shared principal and the connected resources. Investigation runs once, on the whole chain, and produces one story: leaked key, Lambda weaponized, execution role abused, admin identity brute-forced. Hunting checks whether the same key touched anything else. Response, in Part 4, acts once, precisely. You investigated one case one time, over shared context, with no duplicated work and no conflicting actions. Your cost tracked the number of real incidents, which was one, not the number of alerts, which the attacker controls.

That is the difference between a swarm and an architecture. The swarm scales with the attacker. The architecture scales with the number of real incidents, which is the number you actually care about.

Next: What Is the AI Allowed to Do About It?

We now have agents organized around one shared, always-current picture of the case and the environment. They can see the whole attack, once, in time. But seeing is not stopping. In Part 4 we watch a real AI SOC take the Part 2 attack apart in the backend, step by step, and then disable the attacker's key on its own, before it reaches anything that matters. And we get to the decision that makes any of that safe to switch on: which response actions you trust the AI to take, which stay in human hands, and why that decision belongs to the architect.

Want the attack scenarios these posts are built on? CDRGoat is open source.