Analyst firm SACR recognizes Intezer as Pioneer in the AI SOC category

Software Analyst Cyber Research just published the two-part AI SOC Technoscope Series, Building the Trusted SOC and The AI SOC Market, 2026. It is SACR's third consecutive year of original research on this category, built on structured interviews with 20 security leaders, briefings and live demonstrations with 23 vendors, and targeted surveys across the market. Out of a landscape that peer trackers now count at close to 140 vendors, SACR treats more than 60 as pure-play AI SOC platforms and evaluated 18 in depth.

We are glad to be among the 18. More than that, we think Sean Sosnowski and the SACR team have written the most useful framing of this market so far, because they went looking for the thing most of the category is avoiding.

The gap nobody wants to talk about

SACR's starting point is what they call the action gap, the distance between a validated incident and a safe, verified, state-changing response an organization is willing to stand behind. Their diagnosis is blunt. AI made investigation faster. It did very little for the part that actually changes risk.

Anyone who has run a SOC recognizes the shape of this. Triage that felt novel two years ago now ships inside every SIEM, EDR, XDR and SOAR product you already own. Every demo looks the same. Summaries, enrichment, entity extraction and guided investigation now produce a nearly identical analyst experience even when the evidence handling underneath differs enormously. As SACR puts it, because investigation has commoditized, front-of-funnel capability no longer separates products. The real differences moved downstream into governance, execution, verification and proof, which are exactly the things a demo does not show well.

Trusted Security Response Operations

The model SACR introduces is Trusted Security Response Operations, or TSRO. It defines how a security team grants software bounded authority to recommend, prepare, execute and verify specific response actions, under explicit requirements for evidence, policy, credentials, scope and accountability.

The reframe that matters most is this. You are not making one decision about whether to trust AI in your SOC. You are making a portfolio of narrow delegation decisions, one action at a time, each of which can be granted, expanded, narrowed or withdrawn on evidence. SACR calls the result the authority portfolio, and it is measured across four stages. Advisory authority, where the system proposes and humans decide. Approval-bounded authority, where the system prepares the action and routes it to an accountable owner. Policy-bounded authority, where approved action types execute without case-by-case sign-off. And proven authority, earned over time against measured thresholds.

The same platform can sit at four different stages on four different actions on the same day. Proven authority to quarantine confirmed malicious email. Approval-bounded authority to isolate an endpoint. Advisory only for privileged identity revocation. That is a far more honest picture of how security teams actually work than any platform-wide autonomy percentage, which SACR flags as a particularly weak metric.

Everything rests on the evidence layer

TSRO is built on a five-layer chain. Evidence, decision, authority and action, proof, and improvement. Weakness in any layer is justification to limit what the system is allowed to do.

Evidence comes first for a reason. SACR is direct about it. A lack of evidence should not be treated as justification for safe action, it should be a warning sign. And when they look at where the market actually separates, they land on the same place. Outcome verification remains the clearest dividing line across the market. Many vendors can show that an action was initiated or that an API request was accepted. Far fewer can re-query the source system, prove the intended state changed, and connect the result to a measurable reduction in risk.

This is the part of the report we find most validating, because it is the bet Intezer made years ago and it is the one thing you cannot retrofit. If the evidence underneath a verdict is thin, no amount of governance tooling on top makes the resulting action defensible. It just makes the wrong action auditable.

With Intezer AI SOC every alert gets investigated at forensic depth, using genetic code analysis and binary similarity down to assembly-level code fragments, live memory analysis, process trees, endpoint and network forensics, phishing analysis and threat intelligence. SACR described our differentiation as the combination of AI-led SOC automation with deep forensic analysis, and grouped us among the vendors providing strong evidence assembly and reasoning. They also noted our compartmentalized design, where model outputs are separated by triage component so that a single anomalous response does not directly determine the final verdict.

That depth is what makes a verdict something you can act on rather than something you have to check.

Context decides what a signal means

The practitioner theme SACR calls the context moat is the second half of the same problem. Security telemetry alone rarely contains enough to justify a response. The same behavior means different things in a media company and a regulated bank. The platforms worth trusting, practitioners told SACR, are the ones that let an operator inspect the context behind a conclusion, add what is missing, challenge the hypothesis, and watch the recommendation change.

This is precisely what Intezer's Org Brain does. It holds the durable model of your environment, your asset criticality, your identities and ownership, your accepted tools and known-good behavior, your standard operating procedures and the accumulated history of how your team has handled similar cases. It is inspectable, editable and continuously refreshed, so an analyst can see why a verdict landed where it did and correct the context rather than argue with a black box.

Detection quality is the third leg. SACR found that weak upstream signals and poor context correlation undermine every investigation and response decision built on them, which is why detection engineering has been pulled back into the AI SOC conversation. Intezer detection engineering work covers posture reviews, MITRE ATT&CK gap analysis and ongoing rule assessment, with the resulting detection content owned by the customer. And every verdict coming from our forensic analysis, feeds back into the rule creation, for continually optimized detection.

Where the reports placed us, and what they were written before

SACR placed Intezer in the Pioneer category, which recognizes strong architectural alignment with developing production delivery. Their stated reason is that our architecture connects deep forensic reasoning, cross-source investigation and routine-case automation, while approvals, policy hierarchy, rollback, audit export and broad outcome verification were under-evidenced at the time of research.

We will take that on the chin, with one clarification that matters for anyone reading the placement today.

The ranked cohort was limited to products whose relevant AI SOC offering was publicly identifiable by December 31, 2025, and SACR was explicit that beta, private-preview and roadmap capabilities were separated from mature functionality and did not receive equivalent credit. The findings, in their own words, represent the best evidence available during the research period.

Intezer Workflows shipped after that window closed. Workflows is the governed execution layer that sits directly on the gaps SACR identified. Customer-defined action paths, approval routing to the accountable owner, policy conditions that vary by action type, asset criticality, user privilege and incident severity, and execution that is recorded end to end. Alongside it, Custom Agents let teams build environment-specific reporting, hunting and operational routines on top of the same forensic engine, and our MCP server exposes that engine to the AI platforms and analyst interfaces teams already use. SACR did note the custom agent and MCP capabilities in our profile. What they could not evaluate is the governed response layer that now runs underneath them.

Read the Pioneer placement as a snapshot of a fast-moving product taken at a fixed date, and read the architectural half of it as the durable signal. The report's own logic is that broader verified execution and stronger production evidence move a vendor toward the Innovator category. That is exactly the work Workflows was built to do.

Why the order matters

There is a reason we built forensic depth and organizational context first and governed execution second, and the SACR model explains it very well.

Governance layered over shallow evidence produces confident wrong actions with a clean audit trail. Forensic evidence and real organizational context produce verdicts strong enough that delegating authority against them is a reasonable business decision. 

SACR wrote that our combination of autonomous triage and investigation with forensic evidence is designed to raise confidence before response actions are taken, and that it gives the platform a credible role as an operating layer across existing SOC infrastructure rather than an isolated AI assistant. That is the role we want. An operating layer with enough evidence behind it to be handed real authority. And now we have the workflows to respond with customers confident in the results.

AI executes. Humans supervise. The Trusted SOC is how that gets governed, and the evidence layer is how it gets earned.

Our thanks to Sean Sosnowski and SACR for research that asked the harder question.

Learn more about Intezer AI SOC.