I came across a Hacker News article this week referencing the SOC-CMM 2026 Maturity Report, an annual study of about 200 SOCs worldwide. The number that stopped me: only 10% of SOCs report excellent value from their AI deployments. 71% report partial or no value. Eighteen months after large-scale deployments began.

That didn’t surprise me. But it deserved a serious conversation.

What the Report Actually Says

The report doesn’t say AI doesn’t work. It says most SOCs adopted it without strategy. Concretely: 57% of SOCs have no AI adoption strategy in place. 65% use LLMs without modification, straight out of the box. 40% have no customization of their AI tools. 42% use them without formally integrating them into operations.

That’s the picture of a sector that adopted AI by reflex, not by design.

AI types in use are varied: generic LLMs, copilots integrated into existing tools (Microsoft Sentinel, CrowdStrike, Splunk), AI agents for triage and enrichment, and a rise in agentic AI. Automation has progressed strongly in enrichment (+56%), automated response (+117%), and deduplication (+81%). What works is well-bounded automation. What disappoints is generative AI used without a framework.

The Real Problem: Context

I’ve built and restructured several SOCs over the years. When I look at why AI doesn’t deliver value, the answer is almost always the same: the agent doesn’t have the right context.

An AI agent without context produces generalities. It misses weak signals. It stays stuck in its silo (SIEM, EDR, or ticketing system). It doesn’t know that the alert on this workstation belongs to a privileged account, that this user already triggered a similar false positive three times this month, or that this asset is critical for production.

Without that context, the agent triages poorly. And bad triage with speed is worse than good triage slowly.

On the other hand, if you give the agent ungoverned access to the entire environment to fix that problem, you create another risk: too many permissions, too many error surfaces, and no traceability of automated decisions.

What’s missing between the two is a context and governance architecture.

What This Means in Practice

On the context to provide:

For an AI agent to be useful in a SOC, it must have access, in a structured and bounded way, to the user’s identity and risk profile, the criticality of the affected asset, incident history and analyst decisions, documented exceptions and false positives, and active detection rules with their logic.

Platforms like Recorded Future, ThreatConnect, or MISP can feed the intelligence layer. Tools like ServiceNow Security Operations or Jira Service Management retain decision history. The CMDB remains the source of truth on assets. If these sources aren’t connected to the agent, it operates in a vacuum.

On the governance to put in place:

The report identifies governance as the number one challenge for SOCs, cited by 39% of respondents. That’s no accident. Deploying AI without governance just moves the problem.

Concretely, that means defining in writing what the agent can do alone (enrichment, deduplication, priority scoring), what requires human validation (workstation isolation, escalation, incident closure), how agent decisions are audited and reviewed, and who is responsible when the agent is wrong.

Tools like Microsoft Sentinel with Logic Apps Playbooks, Palo Alto XSOAR, or Splunk SOAR allow defining these guardrails operationally. Agentic AI, available in platforms such as Cortex XSIAM or Elastic Security, must be subject to the same constraints.

What the Report Recommends to Progress

The SOC-CMM report is clear on the areas where SOCs must invest to escape the 90%.

Automation before generative AI. The most measurable gains come from well-bounded automation: automatic alert enrichment, deduplication, ticket generation. These use cases are mature, traceable, and reversible. That’s the foundation before moving to generative or agentic AI.

Document known false positives. That’s one of the most under-exploited context sources. An AI agent that doesn’t know a rule generates 95% noise on a specific environment will repeat the same errors as the tired analyst you were trying to help.

Formalize detection engineering before automating. SOCs that get value from AI first structured their detection backlog, ideally aligned with MITRE ATT&CK. An agent working on poorly defined rules will prioritize poorly. Garbage in, garbage out.

Measure real value, not adoption. Many SOCs measure whether they use AI, not what it gives them. Metrics to track are enrichment time per alert before/after, the rate of false positives handled automatically, and time freed for level 2 and 3 analysts. Without these metrics, impossible to know whether you’re in the 10% or the 90%.

What I Take Away

AI in the SOC is not a technology problem. The tools exist. Platforms are improving fast. The problem is operational and governance-related.

Years running SOCs the old-fashioned way give an advantage here that newer teams don’t have yet: we know exactly where information is lost, where responsibility handoffs break the chain, and where poorly defined access becomes a security problem.

AI won’t fix a poorly structured SOC. But a well-structured SOC can use AI to do in 2 minutes what took a overwhelmed analyst 20 minutes.

The real question for teams running a SOC right now: have you defined what your AI agent is allowed to do, and how you will audit its decisions? If the answer is no, you’re in the 90%.

👉 And you — which camp is your SOC in?