Inside an AI-Driven Security Operations Platform: An Interactive Reference Architecture

Every few weeks someone asks me some version of the same question: can agentic AI actually run security operations, or is it all demos? My honest answer is that the question is framed wrong. Whether a language model can triage an alert is not very interesting — it clearly can, some of the time. The interesting problem is everything around that moment: who authorized the query, which tenant's data it touched, what evidence the conclusion rests on, who approved the response action, and whether any of it can be reconstructed six months later when a customer's auditor asks.

So instead of writing another opinion piece, I did what I would do for a client: a critical gap analysis of the requirements for an AI-driven SOC platform, followed by a full target-state architecture — published as an interactive artifact you can explore rather than a sixty-page document you will not read.

Launch the interactive architecture →

The position the whole architecture defends

One sentence carries the entire design: a deterministic, policy-controlled security platform surrounding bounded probabilistic AI capabilities. Models may classify, summarize, correlate, plan, and draft. They never control authentication, authorization, tenant isolation, secrets, approvals, execution, verification, or audit. Multi-agent orchestration is an implementation technique — not the trust boundary, not the authorization system, and not the evidence model. Agents sit inside the security and assurance foundation. They do not sit above it.

That sounds obvious written down. Almost no agentic SOC design I have reviewed actually holds the line, because holding it requires unglamorous machinery: durable workflow engines instead of framework loops, typed tool brokers instead of raw API access, a context builder that treats every log line and email as hostile input, an action-risk model with dual-control approvals, and an audit log whose failure blocks high-risk execution. That machinery is what the artifact documents.

A preview, embedded below — open it full-screen for the real experience (keyboard navigation and search included; press / to search):

What's inside

The portal is organized the way I would walk a CISO and an engineering lead through it together — assessment first, architecture second, delivery last:

• A blunt executive assessment and gap analysis — forty-six findings across product definition, AI and agent architecture, and platform security, each with severity, consequence, and the required correction.
• A clickable architecture overview covering twenty layers, with every one of sixty-six components opening a full contract: purpose, data handled, tenant boundary, dependencies, failure modes, owner, and open decisions.
• Twelve bounded agents, each with a versioned contract, typed handoffs, budgets, and stop conditions — and an explicit account of where AI is deliberately not used.
• The assurance layers: twelve trust zones, five tenancy tiers, the R0–R5 response-control model, detection-as-code, a five-level evaluation hierarchy with zero-tolerance safety metrics, and a standards mapping.
• The delivery view: a phased roadmap where response authority ships last, fourteen operational runbooks, fourteen architecture decision records, a twenty-four-item risk register, and the fifteen decisions that must be settled before anyone writes code.

Three path traces — alert to finding, response execution, and prompt-injection containment — are the fastest way to understand how the platform actually thinks.

Why the boring parts matter most

The central risk in these systems is not whether a team can build agents. It is an agent reaching the wrong tenant, hostile evidence steering an investigation, an unsupported conclusion being accepted as fact, a broad query exposing sensitive data, an action targeting the wrong asset, a provider change silently degrading outcomes, and incomplete audit at the exact moment a customer needs proof.

Every one of those failure modes is addressed by deterministic machinery, not by better prompting. That is the argument, and the architecture is the evidence for it.

Using this in your own program

If you are building or evaluating something in this space — as an enterprise SOC, an MSSP, or a product team — the transferable parts are the action-risk model, the evidence and provenance schema, and the release gates. Those three turn "we use AI in the SOC" into something you can actually defend in a security review.

If you would like an architecture and assurance package like this built for your actual environment, with your systems, constraints, and compliance obligations, that is exactly the kind of engagement I take on. Start the conversation.