The Security Architect's Next Deliverable: An Agentic SOC

Series: Building the Agentic SOC – Part 1

What Actually Makes a Security Architect

Ask around what a Security Architect is, and you will mostly hear one answer: the person who knows every technology in the stack deeply, from identity and network to cloud, endpoints, and data. That's true. It's also just the entry ticket.

The second skill gets mentioned less, though it separates architects who ship from architects who present. Real environments are not greenfield. There is a mainframe that processes payroll, an AD forest nobody dares to touch, a business unit running an EOL appliance because the migration budget went elsewhere. A true architect doesn't push colleagues toward the modern stack and call resistance "technical debt." They respect the business need behind the legacy, and they design security that works in a mixed environment, under real financial and human constraints, not in a reference diagram.

But there is a third skill, and this one is almost never on the list. I've seen it missing in strong architects, and I've seen what its absence costs. The third skill is taking the SOC into consideration.

Defense Is Only Half the Job

Look at how organizations actually use their architects: they plan infrastructure. Segmentation, identity boundaries, encryption, hardening baselines. Call it the defense part. And architects are genuinely good at it.

But security has never ended with defense. Every defense has gaps, and the architect knows this better than anyone: they made the trade-offs that created them. That legacy appliance that can't do modern auth. That flat network segment the business refused to split. Each accepted risk is a place where prevention was traded away, and detection and response were left holding the bill.

Here is the uncomfortable question: who told the SOC?

In most organizations, nobody. The architect signs off the design, the risk register absorbs the exceptions, and the SOC finds out about the gap during the incident. The architect who accepted the trade-off never validated whether the response side of the house can actually cover it: whether the telemetry exists, whether a detection is in place, whether anyone would recognize the alert if it fired.

I'm not arguing the architect should run the SOC or write its processes. I'm arguing the SOC is a piece of the same puzzle the architect is assembling. A true architect knows their defense gaps explicitly, walks them over to the SOC, and asks one question: can you cover this? If the answer is no, that's not a note in a risk register. That is a top-priority problem to be solved one way or another (a compensating detection, a telemetry fix, a design change), because an unwatched gap isn't an accepted risk. It's a standing invitation.

That's the pre-story. Now the actual reason I'm writing this.

The SOC Is Becoming Something You Architect

For twenty years, "building a SOC" meant building an organization: hiring analysts, defining tiers, writing runbooks, scheduling shifts, managing burnout and turnover. It was an operational and managerial discipline. Architects contributed inputs (log sources, use cases), but the SOC itself was built by SOC people, out of people.

AI is changing what the SOC is made of. Agentic systems are already taking over triage, enrichment, correlation, and first-line investigation, the layers that consumed most of the human headcount. As that shifts, the demand for human-scale processes shrinks with it: fewer tiers to define, fewer handoffs to script, fewer runbooks written for a person to follow at 3 AM. What remains to be built is not an org chart. It's a system: agents, data flows, context sources, decision boundaries, guardrails.

And building systems is architecture.

Think about what an agentic SOC actually needs to work. Not a chat window bolted onto a SIEM, but a set of agents that can investigate the way a good analyst does. That requires knowing what the environment looks like and why, which trade-offs were accepted and where, where the context lives (in which logs, which configuration stores, which identity systems), and how data flows between all of it. There is exactly one person in the organization who holds that picture end to end. It isn't the SOC manager, and it isn't the AI vendor. It's the Security Architect.

Which means the third skill stops being optional. The architect who used to validate with the SOC now has to build it, or at minimum be an active hand in building it. The requirements are being rewritten in real time: designing the agentic SOC is becoming part of the Security Architect's job description, whether the job description says so yet or not.

This series is a practical answer to that shift. Not "AI will change everything" — you've read that post already. Instead: how to actually construct an agentic SOC, as an architecture problem, starting from what agents need to know, through where they get context, to how you bound what they're allowed to do.

Where This Series Goes

I'm not going to argue this in the abstract. Over the next parts we'll build the case (and the SOC) hands-on, using CDRGoat, the open-source project I built for exactly this purpose: realistic, deployable cloud attack scenarios across AWS, GCP, Azure, and Kubernetes. You'll be able to run everything yourself, and then watch an AI SOC take it apart.

Three spoilers, so you know what you're signing up for.

Spoiler one: one leaked key becomes privileged code execution and a hidden backdoor, in minutes. We'll run a realistic AI-driven attacker in a real cloud account, starting with a single stolen access key. No zero-days, no exotic tooling. Within a few minutes it escalates from a low-privileged user to running its own code as a far more powerful role, and it plants a console backdoor to come back to later. A human SOC does not have those minutes. The alert is still sitting in a triage queue when the backdoor goes in.

Spoiler two: an AI SOC is not one agent per alert. A single attack throws off a burst of separate alerts, and the obvious design spawns an investigation for each one. That rebuilds the human SOC's worst failures at machine speed: the same incident investigated many times over, agents that never realize they are all looking at one attacker, and nobody holding the whole picture. The real design is one linked case that every related alert attaches to, and keeping that case coherent while new alerts keep arriving mid-investigation is an architecture problem, not a prompt.

Spoiler three: the AI can stop the attack, but only because a human decided what it is allowed to do. In the finale, the AI SOC detects the attack, reconstructs the entire chain on its own, and disables the stolen key automatically, before the attacker reaches anything that matters. The catch is that response actions are dangerous. Disabling a leaked key is safe and reversible. Isolating a production host or deleting an identity can cause the exact outage the attacker never managed to. So someone has to decide, in advance, which actions the AI may take on its own, which need a human, and which are off the table. That someone is the Security Architect, and that decision is the heart of the job.

If you're a Security Architect, this series is your job description catching up with reality. Part 2 starts with the attack.

Want to run the scenarios yourself? CDRGoat is open source.