The Black Hat floor surprised us this year. There’s always AI this and AI that, but this year, there were 60+ vendors from different industries who were all touting the same thing: AI SOC.

So why is it that dozens of booths, from the pure play AI SOCs, to SIEM vendors, to endpoint vendors, and even network vendors, all described the same outcome? Let’s break it down.

(An AI SOC, also called an agentic SOC, is a security operations model in which AI agents triage, investigate, and help respond to alerts within human-defined boundaries, rather than analysts doing that work by hand.)

These are the four shifts that are driving this trend:

1. Context is king when it comes to trusting an AI SOC
2. The SIEM market is ripe for change
3. Services and software are converging: MDR adding agents; AI SOC adding services
4. The Detection Engineering market is emerging

Shift one: Context

How do AI SOC vendors get context?

Nearly every set of materials on that floor leads with context, and a striking number claim the best knowledge graph in the category. Far fewer explain how they get it.

That is the part worth pressing on, because there are four separate problems hiding behind the word.

Capture. Many vendors lead on context. Far fewer have a good way to actually collect it. Context lives in the customer’s environment, spread across systems most security platforms do not integrate with, and you cannot have all of it if you only support a handful of platforms to go and get it. This is why integration breadth stopped being a procurement detail and became the product. Context is a capture problem before it is a reasoning problem.

Time. Some platforms build their context by learning from historical cases. That works eventually. But it means the system is weakest on day one and improves from there, so the honest question for a buyer is how long they are expected to wait. Do you want an AI SOC that is useful in six months, or one that is useful this quarter?

Portability. This is the one that rarely comes up early enough. If your organizational context is accumulated inside a vendor’s platform, it stays there. You cannot take it with you. Every month of learned history raises the cost of ever changing your mind, which is stickiness dressed up as intelligence. The context a team builds about its own environment should belong to that team.

Scope. Most vendors treat context as a security problem. It is not, or not only. Deciding whether an alert matters usually needs business information rather than SecOps information. Who owns this system? What it is worth? Which customers depend on it? Is this behavior expected? Security context alone will not answer those, and a platform that only speaks to security tools is unlikely to see them at all.

Shift two: SIEM

Should you replace your SIEM or add an agentic layer on top?

The second most common message we saw on the floor was around the next generation of SIEM. New approaches to SIEM, from data pipelines to AI detection platforms are all looking to disrupt the monolithic and expensive repository that the SIEM has become.

One approach to SIEM modernization is adding an agentic layer on top of it. Many buyers are looking for the flexibility to build agents and workflows themselves on the stack they have.

Shift three: Services and Software

What is the difference between an AI SOC and an MDR now?

Managed detection providers now position agentic capability. At the same time, AI SOC vendors are moving toward managed services.

(MDR, managed detection and response, is a service model where a third party operates detection and response on your behalf. The distinction that used to be clean, MDR is a service and an AI SOC is software, is exactly what is now blurring.)

The practical effect is that the AI SOC evaluation and the managed service renewal have become one budget conversation. Many times the incumbent teams are looking to replace is a service contract, rather than a product.

This is the shift we’re seeing. It’s not humans watching queues on the customer’s behalf, but agents (built for that customer’s environment) doing the work. Most of the analysts looking at this agree that the future of the SOC is security engineering rather than analysis.

Shift four: Detection Engineering

Is detection engineering now part of the AI SOC?

Triage got commoditized, and that is the story of this shift.

(Detection engineering is the discipline of building, tuning, validating and maintaining the detection rules that decide what a SOC sees in the first place. In 2026 it moved from a background craft to a marketed capability, a shift also tracked by vendor-neutral bodies like SANS.)

The clearest evidence is the mix of vendors making the claim. Roughly half the companies advertising AI SOC on the Black Hat floor are not AI SOC companies at all. It is a capability inside a SIEM, inside an endpoint platform, inside a network platform, inside a managed service. They added it because it was expected of them, not because it is what they sell.

That is what commoditization looks like in practice. The thing that used to be a company is now a line item on somebody else’s roadmap.

Which left the pure plays with a problem. If the capability you were founded on now ships as a feature in products your customer already owns, you have to move. So the field split.

Part of the market moved right, adding response and remediation, because a system that only tells you what is happening does not reduce work. Another part moved left into detection engineering, and standalone platforms appeared selling it as the whole product rather than a feature. At Black Hat we saw detection engineering agents shipped as part of AI SOC platforms rather than beside them.

Very few vendors moved in both directions. That matters, because the SOC does not stop at either end. Detection quality and response depth are the same problem seen from two sides. A system that writes better detections and cannot act on them is half a product. So is the reverse.

Prospects now raise detection engineering unprompted in AI SOC evaluations. Detection audit, coverage measurement, AI assisted rule generation, pipeline health.

What practitioners told us

Three things came up often enough to be worth reporting.

Almost everyone is in. Of the practitioners we spoke to, we did not find many who were neither exploring nor already implementing AI SOC. Adoption intent is close to universal, which also means we are in the middle of the hype, a read consistent with industry analysis placing AI SOC agents still early in real production adoption despite the noise.

Many are not choosing. They are running both. Because most AI SOC platforms cannot respond, teams run them alongside their existing automation for about a year, to see which side closes the gap first. Whether their automation platform gets better at investigation, or their AI SOC gets better at response.

Consolidation is already happening. Most are re-evaluating SIEM spend and managed service spend at the same time. The AI SOC purchase pulls two other budget lines into the room.

That second one is the honest signal. A year long parallel run is what a team does when it does not yet trust either side enough to commit.

The real subject is trust. What makes an AI SOC trustworthy?

Every shift above is the same problem wearing a different jacket.

Dozens of vendors making one claim means the claim cannot be verified. Context a platform cannot capture, cannot capture yet, or will not let you take with you produces confident answers about a company that is not quite yours. Automation that stops at a notification creates work rather than removing it. A parallel run is a team buying time because it cannot yet tell which system to believe.

Trust is not a feature you add at the end. It is an architectural property, and it comes from a few specific things.

Show the work. An investigation you cannot inspect is an assertion. Every step, every query, every piece of evidence and every decision should be readable after the fact, by an analyst and by an auditor. We call this the control room. You watch the work as it happens, you can stop it, and you can replay it later.

Say when you do not know. A system that answers confidently every time is not trustworthy, it is just confident. Real investigations end in three ways. Confident, where the system reached a conclusion it can defend. Escalated, where it did the work and a human makes the call. Inconclusive, where the evidence was not there and it says so instead of inventing a verdict. A system that cannot produce the third outcome is hiding something.

Define what the agents are allowed to do. Autonomy is not a slider from off to on. It is a set of explicit authorities. Which actions run without approval, which need a human, which never run at all, per environment and per team. Agents need a harness. Without one, autonomy is closer to unmonitored access with better marketing.

Keep the deterministic parts deterministic. Reasoning belongs where judgement is needed. It does not belong in approvals, fallbacks, escalation paths or rollback. Those run the same way every time, because that is what makes an outcome predictable enough to audit.

Why the platform, and not the category

This is why we do not describe the Blink Platform as only an AI SOC.

An AI SOC is one solution. The problems it addresses do not stop at the SOC boundary, and neither do the agents, the integrations or the governance model that make it work. The same investigation logic that triages an alert can review an access request. The same response layer that isolates a host can remediate a vulnerability or close a compliance gap. The same audit trail serves the SOC manager and the auditor.

What the SOC needs is an Agentic Security Operations Platform. One foundation. Agents you build and own rather than accept as delivered. Deterministic workflows around them for guardrails, approvals and fallbacks. Response that reaches the systems you actually run. Case management where the work lands. And solutions built on top of it, for the SOC, for identity, for vulnerability management, for governance and for the cloud.

(An Agentic Security Operations Platform (ASOP) is a single foundation of owned agents, deterministic guardrails, response and case management that spans the SOC and adjacent domains (identity, vulnerability management, governance and cloud) rather than a point AI SOC product.)

AI SOC was the theme of this Black Hat. It will be louder at the next RSAC, because it is driving the biggest change to the SOC in a decade.

The vendors who last will not be the ones who said it loudest. They will be the ones whose customers could trust it.

Running an evaluation right now, or have a view on any of this? We are happy to have the practitioner conversation.

‍

Frequently asked questions

What is an AI SOC (agentic SOC)?

An AI SOC is a security operations model where AI agents triage, investigate, and help respond to alerts within human-defined boundaries, instead of analysts doing that work manually. It is a category of capability, not a single product, which is why so many different vendors can claim it.

Do I need to replace my SIEM to adopt an AI SOC?

No. Buyers split into two camps: one wants a single platform holding data, detections and agents; the larger camp keeps the SIEM it already runs and adds an agentic layer on top. SIEM has become the core of the SOC rather than a product to rip out, so the "add a layer" path is viable and increasingly common.

What is the difference between an AI SOC and an MDR?

An MDR is a service: a third party operating detection and response for you. An AI SOC is software. That line is blurring, because MDR providers now add agentic capability and AI SOC vendors add managed services, so the evaluation and the service renewal are becoming one conversation. The key question is what you keep at the end of the contract: a service takes the capability with it, whereas owned agents and workflows stay with you.

Is detection engineering now part of the AI SOC?

Increasingly, yes. Triage got commoditised, so detection engineering, the work of building, tuning and validating the rules that decide what the SOC sees, became a marketed capability in its own right, with agents for detection audit, coverage measurement and AI-assisted rule generation shipping inside AI SOC platforms.

What is an Agentic Security Operations Platform, and how is it different from an AI SOC?

An Agentic Security Operations Platform (ASOP) is a single foundation of owned agents, deterministic guardrails, response and case management that spans the SOC and adjacent domains: identity, vulnerability management, governance and cloud. An AI SOC is one solution on that foundation; the platform is the broader thing.

How do I evaluate whether an AI SOC is trustworthy?

Look for four architectural properties: it shows its work (every step, query and decision is inspectable), it can say "inconclusive" instead of always answering confidently, it defines explicit authorities for what agents may do autonomously, and it keeps deterministic steps (approvals, fallbacks, rollback) deterministic and auditable.