Intezer's SOC Operating Layer boosts adoption of Claude, Codex, and Cursor in security

Enterprise security teams want AI agents inside the SOC, but raw agent integrations keep failing on the same problem: the agent has no trustworthy context. Wire a frontier model straight into security tooling and it improvises — guessing at alert semantics, missing case history, and stitching together fragments of telemetry it was never given a coherent view of. Intezer's answer is a context layer that sits between the detection stack and the agent: the Intezer SOC Operating Layer, built around a revamped Model Context Protocol server that exposes the company's forensic knowledge to agents teams already use. Intezer's AI SOC blog frames the platform as exactly that — an operating layer for agent-driven security operations rather than another dashboard.

The idea is straightforward. Instead of each agent integration re-solving how to read alerts, interpret verdicts, and recall what happened last time, one shared layer does the forensic work once and serves it to every agent. Intezer positions this as the missing foundation for putting Claude, Codex, and Cursor to work on real SOC tasks, and the company's own writing backs that positioning: a recent post notes that security teams already live inside Claude, Codex, Cursor, and similar workspaces, and argues the job now is to turn those workspaces into genuine security workspaces with real case context behind them.

What the SOC operating layer actually is

At its core, the operating layer is a Model Context Protocol (MCP) server wired into Intezer's triage pipeline. Alerts flow in from SIEM, EDR, cloud, and identity tooling; Intezer's automation investigates them; and the resulting verdicts, histories, and reasoning traces become retrievable context for AI agents through the MCP interface. The agent never touches raw telemetry directly. It asks the layer what is known about an alert, what was decided, and what happened in similar cases before.

This matters because first-generation agent integrations did the opposite: they handed the model credentials or API access and hoped prompt engineering would substitute for domain context. That approach produces the two failure modes SOC leaders complain about most — confident wrong answers on unfamiliar alert types, and zero institutional memory between shifts. A shared operating layer attacks both at once by making the forensic record, not the raw feed, the thing the agent reads.

Intezer's framing goes further. The company describes the layer as a single source of truth that accumulates institutional memory over time — every investigated alert sharpens the record the next agent call draws on. A separate company post on the Intezer Org Brain pushes the same theme: organizational context that learns, recalls, and fetches what it is missing. Whether or not buyers accept the strongest version of that claim, the architectural direction is real and widely shared — context infrastructure, not model size, is now the binding constraint on useful SOC agents.

Why agents need a context layer at all

The Model Context Protocol exists precisely because connecting AI applications to external systems used to mean bespoke glue per tool. MCP is an open standard for those connections: instead of custom code for every data source, the agent speaks one protocol and each system exposes context through it. For security operations this is a natural fit, because a SOC is a federation problem — a dozen detection tools, each with its own schema, each holding part of the story.

Without a layer like this, every agent project replays the same expensive discovery phase. Which fields on this alert type actually matter. Which verdicts can be trusted without re-verification. Who worked a similar case last quarter and what did they conclude. DIY pipelines answer these questions weeks into the project, per integration, and the answers rot as tools change. A maintained operating layer amortizes that work across every agent and every team on the platform — which is the economic argument underneath the product announcement.

None of this removes the human from consequential decisions. It changes where humans spend attention: reviewing the small fraction of cases the automation cannot resolve with confidence, instead of re-reading the large fraction it already understands. That triage pyramid — broad automated coverage with narrow human escalation — is the oldest idea in SOC staffing, now expressed as agent infrastructure.

Claude, Codex, and Cursor in the security workflow

The three named agents cover the realistic surface of where practitioners already work. Claude, via Anthropic's models and coding tools, is the reasoning-heavy analyst: long investigations, report drafting, multi-step case reconstruction. Codex represents OpenAI's coding-agent lineage pointed at detection-as-code and response scripting. And Cursor, the codebase-aware coding agent, is where detection engineers already live when they write and maintain rules, parsers, and integrations — an agent that understands the repository can propose detection logic in context rather than as disconnected snippets.

Intezer's own content strategy confirms the bet. Alongside the operating-layer announcement, the company published a CISO playbook for putting Claude to work in security operations, aimed at leaders who know AI belongs in the SOC but need a practical model for where it fits — alert volume, manual triage, and reporting drag. That is honest positioning: the playbook concedes the problem is organizational (where does the agent fit, who supervises it) as much as technical. Teams evaluating the operating layer should read it as the adoption manual for the product itself.

One caution the source material supports: meeting agents where they already live is a distribution argument, not a capability proof. That Cursor can read your detection repo does not by itself mean its suggested rule is safe to deploy; that Claude can summarize a case file does not mean its verdict is right. The operating layer's value proposition is that these agents stop reasoning from raw feeds and start reasoning from investigated, stored forensic conclusions — which narrows, without eliminating, the verification burden on the human reviewer.

Full-scope triage and the vendor's numbers

Intezer's announcement describes automated investigation across the full alert stream: every incoming alert passes through forensic analysis, producing verdicts and escalating the remainder for human review. The company attaches strong figures to this — full alert coverage with high automated accuracy, per its own announcement materials. Treat those figures as vendor claims, not independently verified benchmarks: no third-party evaluation of the triage accuracy was available at the time of writing, and buyers should ask for measured precision and recall on their own alert mix during any pilot.

What can be said without vendor statistics is structural. Coverage gaps are the silent killer in SOC automation — the alerts nobody looked at because they fell outside the integration's scope. An architecture that ingests from every detection source by default, rather than per-connector opt-in, removes an entire class of blind spot even before accuracy enters the discussion. And escalation-by-exception is the only staffing model that scales as alert volume grows; the question is never whether to triage automatically, but what confidence threshold earns the human's minutes.

Teams should also press on the memory claim during evaluation. An institutional record is only as good as its retrieval: ask how verdicts from six months ago surface in today's investigation, what prevents stale conclusions from poisoning new cases, and how the layer represents uncertainty. These are answerable engineering questions, and the quality of the answers separates a real operating layer from a repackaged alert queue.

Frequently asked questions about the SOC operating layer

Which AI agents does it work with? Intezer names Claude, Codex, and Cursor as supported out of the box, with the MCP interface open to additional agents. The company's own framing — teams already live in these workspaces — suggests support follows user gravity rather than certification depth, so verify the depth of each integration before committing a workflow to it.

How does the MCP server change existing SOC tooling? It sits downstream of detection, not in place of it. SIEM, EDR, and cloud tools keep detecting; the layer investigates and serves context. Nothing in the architecture requires ripping out the current stack, which is the point — adoption without re-platforming.

What is the automation actually doing per alert? Forensic investigation at machine speed: correlating the alert against known-bad indicators and behaviors, recalling similar historical cases, and recording a verdict with its reasoning into the shared record. The human-facing output is the verdict plus the evidence trail, not a bare score.

Where do humans still matter? Reviewing escalated exceptions, auditing the automation's verdicts on a sampling basis, and owning consequential response actions. The layer compresses the routine middle of triage; it does not sign off on containment.

How fast can a team get value? Intezer claims rapid onboarding once alert feeds and agents are connected. As with any context system, expect the value curve to steepen over time — the institutional record compounds, so month three should outperform week one. Ask for that curve explicitly in any trial.

What this means for teams shipping AI features

The pattern generalizes beyond security. Any team putting agents onto an existing operational workflow faces the same choice: bespoke glue per agent, or a maintained context layer every agent reads. The bespoke route feels faster for the first integration and gets slower with each subsequent one; the layer route costs more up front and pays back at the second and third agent. OTF kits are built on the layer instinct — readable, agent-navigable repositories where the context an AI assistant needs (structure, conventions, deployment facts) is maintained in the open rather than re-derived per session. If you are building agent-operated software, start from a kit that treats agent context as infrastructure instead of bolting it on after the demo.

Sources

• Intezer AI SOC blog — Intezer's positioning of its platform as the AI SOC layer.
• Intezer inside your AI workspace — teams living in Claude, Codex, and Cursor; turning them into security workspaces.
• CISO playbook: putting Claude to work in security operations — adoption model for AI in the SOC.
• Model Context Protocol introduction — MCP as the open standard connecting AI applications to external systems.
• Cursor documentation — Cursor as a codebase-aware coding agent.
• Related reading: AI app security checklist, Agent-readable repository structure, AI production background jobs.

---

Originally published at otf-kit.dev — full-stack kits your AI coding agent can actually ship to production. See the kits →