What's real vs marketed in the agentic SOC.

Before any vendor name appears, the disclosure that governs the whole essay. The practice takes no reseller margins, no kickbacks, and no privileged access from any vendor discussed here. The Capability Matrix scores each vendor against the alternatives for a given workload archetype, not against itself, and if the matrix ranks an alternative higher for a workload, that is the recommendation regardless of any relationship. The fair-broker thesis applies before any partnership consideration, and it's the discipline that makes a vendor-watch read forwardable rather than a pitch.

There is one live relationship worth naming concretely, because the rest of the essay discusses the vendor in question. The practice is in GTM-partnership discussions with Databricks around Lakewatch. No reseller margins, no kickbacks, no privileged access. The matrix evaluates Lakewatch against Snowflake-with-Hunters, Cribl-augmented Splunk, ClickHouse-on-Iceberg, and StarRocks; if the matrix ranks an alternative higher for a given workload, that's the recommendation. That disclosure sits here, once, instead of as a banner repeated above every vendor section, which is the right shape for it: disclosure first, opinion second, and the same rule applied to the vendor I have a relationship with and the five I don't.

I watched a sharper version of the validation failure from the field, and it's the bridge between the ceiling number and everything downstream of it. A large SOC that had just turned on an AI triage tool asked me how to undo all of their alert-reduction tuning, the human suppression that exists so the detection engineers aren't buried, so that the tool, sitting at the very top of the stack, could see the full raw feed and do the filtering magic itself. The raw feed at that layer is enormous; a network-telemetry source can run to millions of events a day against a tuned alert stream that is a tiny curated fraction, so "let the AI see everything" means trusting it to replace detection-engineering discipline rather than measure it.

And the tool sits at the top of a long pipeline, downstream of every parsing, mapping, and correlation stage, so it can only act on what survives all of them, which means reverting the human tuning floods it with volume without answering whether the signals that matter even arrive. You cannot trust that layer until you can measure that the data actually flows through the pipeline to it, and almost nobody measures that. Trusting the AI on an unverified pipeline is the same swamp relocated under a fresh coat of paint. That's the connection back to the data-quality work in the ground you're standing on: the top-of-stack agent is only as good as the parse-map-correlate stages beneath it, and the buyer who hasn't instrumented those stages is buying confidence, not coverage.

When I picture the agentic SOC two or three years out, the bottleneck isn't how much of tier-1 a single agent can automate. It's that the agents won't come from one place. You'll have a triage agent that ships with your SIEM, an enrichment agent from your EDR, a ticketing agent in your ITSM platform, a threat-intel agent from a feed vendor, and quite possibly a model you host yourself for the data you can't send anywhere. Each of those is a different runtime, a different trust boundary, and a different idea of what "authenticated" means, and the moment one of them needs to ask another to run a query or hand over a credential, you're in the problem the cross-vendor trust layer is built for. This is why a single-vendor demo is so misleading about the hard part: inside one vendor's fabric the agents already trust each other because they share an identity provider and a runtime, so discovery is a config file and trust is assumed, and the demo looks clean because it has erased the cross-boundary problem, which is the one you actually have.

The clearest articulation of this layer I've found is MIT's NANDA project, and it's worth being precise about what it is, because this is exactly the kind of research that gets mis-cited as it travels. NANDA is a research initiative at the MIT Media Lab focused on the infrastructure AI agents would need in order to discover, authenticate, and coordinate across organizational boundaries, framed deliberately by analogy to the internet's own naming and trust layer: where DNS and the certificate system let machines that have never met find and trust each other, NANDA asks what the equivalent looks like for agents. The public output is mostly academic (protocol design, an arXiv paper, 2507.14263, Raskar et al., "Beyond DNS: Unlocking the Internet of AI Agents via the NANDA Index and Verified AgentFacts", and reference implementations under the projnanda GitHub organization). The architecture has three pieces worth naming: a NANDA Index that lets an agent discover others by the capability it needs rather than by a hard-coded endpoint; a registry layer that resolves a discovered agent to an actual identity and address, with Ed25519 keys underpinning that identity; and Verified AgentFacts, which are signed attestations of what an agent claims it can do, so a capability lookup returns something a relying party can check rather than something it has to take on faith. It's a clean separation of concerns that borrows the right ideas from DNS, PKI, and service discovery without trying to be any of them, and it is not a SOC-automation benchmark and does not publish an automation percentage for security operations.

The way I'd put the contribution in security terms is that we spent the last decade rebuilding access control around the idea that you don't trust a request because of where it came from, you trust it because the actor proved its identity and its authorization for that specific action. That's zero-trust, and we built it for humans and for services. Agents are a third class of actor, and they break the assumptions of both, because an agent is neither a human with an SSO session nor a service with a pinned certificate and a fixed scope; it's a thing that shows up, claims a capability, and asks to act, and the question of whether to believe it is exactly the question zero-trust was supposed to answer. Verified AgentFacts maps most directly onto that: a signed attestation of what an agent can do, anchored to a cryptographic identity, is the agent-world version of an authorization claim you can verify rather than assume. It doesn't solve the whole problem, because you still have to decide whose attestations you trust (the bootstrap problem), but it moves the question from "take the agent's word for it" to "check a signature against an identity you've decided to trust," which is the right shape for a security control. This is the same instinct I write about in defining what you can own: the durable questions are about what an actor is allowed to own and prove, not about how clever the model is.

Read as infrastructure rather than as an automation claim, NANDA is trying to solve four specific problems that anyone who has built a SOAR integration knows by heart. The first is the N-by-M integration tax: a typical enterprise SOC runs 40-60 security tools, each with its own API, authentication scheme, and rate-limit gotchas, and connecting them point-to-point creates N-by-M complexity where every new tool requires integrations against every other tool. Gartner's 2024 Hype Cycle for Security Operations puts the average tool count at 45-65 across enterprises surveyed, consistent with what I see in practice, and capability-based discovery reduces this to N-plus-M: each tool registers its capabilities once, and other agents query by capability rather than by tool name, the same architectural shift DNS made for hostnames decades ago. The second is trust without infrastructure: most current SOAR integrations authenticate with long-lived API keys, OAuth tokens, or service accounts, and when one is compromised, revocation takes hours to days because the credential is referenced from dozens of places, whereas the cryptographic identity model (Ed25519 keys plus attestation-based trust plus CRDT-backed sub-second revocation) is an upgrade worth taking seriously. The CRDT (Conflict-free Replicated Data Type) piece matters specifically because revocation events can propagate across a distributed agent network without a central coordinator that would itself become a target, and this is the part of the architecture I think security teams should pay attention to even if the agent-coordination layer on top of it doesn't pan out. The third is capability discovery instead of endpoint binding: current automation hard-codes "Splunk API v2.3" or "CrowdStrike Falcon v2.1" into every workflow, and when the vendor updates the API the workflow breaks, whereas a discovery model lets an orchestrator ask for "siem-query" as a capability and get whichever agent currently provides it, analogous to using a service mesh instead of hard-coding IP addresses. The fourth is composability across vendors: Google's Agent-to-Agent (A2A) protocol and Anthropic's Model Context Protocol (MCP) are complementary efforts at the same problem from different angles (A2A handling inter-agent messaging, MCP handling model-to-tool context), while NANDA's contribution is the directory and trust layer that makes the messaging and context layers safer to use across organizational boundaries. None of the three is the final answer yet, but the fact that they're converging is what I'd watch.

Any architecture that introduces a new coordination layer introduces a new attack surface, and the threat model has four classes a security architect should think about. Agent impersonation, where a malicious agent registers false capabilities, gets discovered by orchestrators, and either exfiltrates the queries it receives or returns attacker-controlled results: attestation and reputation help, but the bootstrap problem (how do you trust the first attester) is non-trivial. Discovery enumeration, where an attacker who gets read access to the NANDA Index gets a complete map of your agent network, a more compact recon target than scanning your tools individually, mitigated by access control on the directory itself, which carries the same access-control complexity DNS has. Trust-chain compromise, where, if attestation depends on other agents vouching, an attacker who compromises a high-reputation agent gets to vouch for malicious agents: reputation systems are notoriously hard to design against this, and NANDA does not solve it in any way I find architecturally convincing yet. And coordination disruption, where denial-of-service against the NANDA Index degrades every agent network depending on it, where the CRDT model helps with eventual consistency but doesn't eliminate the dependency. The mitigations NANDA proposes (sub-second revocation, attestation, reputation, audit trails) are sensible and in some cases stronger than what current SOAR integrations offer, but this is not the kind of architecture where "the threat model is solved" is a fair statement; it's the kind where the threat model is well-articulated and the mitigations are partial, which is the right honest place for a research project to be.

This is also the same argument seen from the vendor side. Databricks acquired Antimatter into the Lakewatch launch specifically for agent authentication and authorization, on the underlying assumption that agentic SIEM needs identity and policy primitives that today's SOC infrastructure doesn't have. That's the NANDA argument restated as a product gap: the infrastructure lacks identity primitives for non-human actors, and whether you read it from MIT's research framing or from a vendor's acquisition, the binding constraint is the same. An identity-and-discovery layer like NANDA does not, by itself, move the investigation-automation ceiling; it makes a multi-vendor agent SOC safer to assemble, which is necessary but not sufficient, and the analyst-judgment work that caps the ceiling (is this real, what's the scope, do we notify regulators) is untouched by better discovery and trust. So if anyone shows you a high-nineties SOC-automation figure and attributes it to NANDA or to "agent networks" generally, the right response is that they've crossed two different questions: how agents find and trust each other, which NANDA addresses, and how much of an investigation an agent can close, which it doesn't.

The CVE-to-patch workflow is one of the few in security where the gap between need and capacity is large enough that even partial automation is valuable, and the numbers (from sources I'd treat as Tier A) make the case. The National Vulnerability Database published roughly 28,800 CVEs in 2023, up from about 25,100 in 2022, on the order of 15% year-over-year growth. Mandiant's M-Trends 2024 reports median time-to-remediate for critical vulnerabilities in the 60-day range across surveyed organizations. Qualys's TruRisk research shows roughly 47% of organizations take longer than 30 days to apply patches that already exist. The piece that's structurally hard to close is the gap between CVE disclosure and vendor patch release, frequently 30 to 45 days, during which the organization knows the vulnerability exists and knows there's no official fix, with options limited to deploying a compensating control, accepting the exposure, or developing a custom patch. Custom patches are rare because they require senior engineering time against a vendor's codebase, and few security teams have that capacity.

The math on team capacity is what the argument rests on. A small security engineering team that can develop two or three custom patches per week, against 50+ critical vulnerabilities per quarter, has a backlog that grows faster than it can be drained. AI-assisted patching may not close that gap, but it changes the shape of the constraint, because senior engineers reviewing and finishing candidate patches is a different workload from senior engineers writing patches from scratch, and reviewing scales better than authoring.

A candidate patch that compiles and passes the existing test suite is not the same as a candidate patch that's safe to deploy, and the FFmpeg draft needing hand tweaks is the small version of exactly this, so the risk catalog splits into three categories. Patch quality: AI-generated code requires mandatory human review, because edge cases in complex codebases get missed and the agent may fix the vulnerability and break adjacent functionality in a way the existing tests don't catch, and there's a meta-risk that a generated patch introduces a new vulnerability while addressing the original one, because the model doesn't reason about security properties the way a human auditor does but pattern-matches against examples in its training data. False confidence: not all vulnerabilities are patchable via code changes, since some require architectural redesign (a sandbox boundary moved, a protocol changed, an authorization model rebuilt), and a patch that addresses the symptom while leaving the design flaw in place can be worse than no patch because it discharges the urgency without closing the root cause; "it compiles and the tests pass" is not the same as "it's secure." Testing gaps: automated tests aren't exhaustive, security-specific test cases are frequently missing from the suites the validation step relies on, so manual penetration testing is still required for critical patches, and production monitoring after deployment matters more than usual because the failure mode you can't catch in test is the attacker bypassing the fix through a different code path. The mitigation I'd recommend is structural: AI drafts the candidate, a human reviews and finishes it before deployment, deployment carries enhanced monitoring for the first 30 days, and the feedback from those 30 days flows back to inform when to trust the workflow next time.

Not every vulnerability is a good fit, and not every codebase is. Good candidates: well-understood vulnerability classes where the fix pattern is documented (buffer overflows with bounds checks, XSS with output encoding, SQL injection with parameterized queries); codebases with decent test coverage so the validation step has something to validate against; non-critical systems where a bad patch can be rolled back without major consequence; vulnerabilities with a clear root cause rather than ones that span multiple files or require redesign. Poor candidates: novel vulnerability classes where the model has no pattern to match against; architectural issues where the fix requires moving a boundary, not changing a line; safety-critical systems where the cost of a wrong patch is unacceptable even with human review; vulnerabilities that require coordinated changes across services or repositories, where the agent's context window is the ceiling on how broad a change it can reason about. Any productivity-multiplier claim ("3-5x throughput for patch development") should come from measured outcomes on your own codebase, not extrapolated from adjacent-domain studies on general-purpose coding assistants; I treat the 3-5x figure as Tier D until I see your numbers.

Databricks Lakewatch is the largest-vendor instance of "lakehouse-native security stops being a self-build conversation," and it's worth working through in detail because the question it raises (does the category change when a vendor of Databricks' scale productizes it) is the live one. The launch inventory: Databricks publicly positioned Lakewatch on Unity Catalog, Delta Lake, and Apache Iceberg, open table formats throughout, with OCSF on the Silver layer, under the framing "Open Agentic SIEM." Agentic triage runs on Mosaic AI with Anthropic Claude as the underlying model; Detection-as-Code carries detection content; Genie translates analyst questions into SQL against the lake; Lakeflow Declarative Pipelines and Expectations carry data quality; Lakebase (serverless Postgres) carries case management; DASF 2.0 (62 risks, 64 controls) is the governance overlay sitting on Unity Catalog primitives. Two acquisitions closed into launch: Antimatter brought agent authentication and authorization (the agent-identity gap discussed above), and SiftD.ai brought SPL translation by Tylor Murray, the original SPL author, which is the migration on-ramp Splunk customers will actually use if anyone's going to displace Splunk at scale.

Four durable whitespace gaps are what the launch doesn't ship, and they're worth naming because they're where independent practitioners and partner shops still have to do real work. The first is a first-party asset and identity graph: the Open Agentic SIEM framing implies the agent reasons across entities, yet the entity-resolution surface (CMDB integration, identity-provider linkage, vulnerability-source reconciliation) is still partner territory rather than a Lakewatch primitive. The second is productized OCSF conformance: OCSF shows up on the Silver layer in the marketing diagram, but the validation, mapping coverage, and semantic-drift detection that production OCSF deployments actually need still isn't there, and this is the DataBahn whitespace, the gap where the pipeline-layer vendors and independent shops still earn their keep. The third is a CISO-language maturity model: the launch is engineered for the security engineer who can read the lakehouse stack diagram, while the translation layer that explains the same architecture in compliance, risk, and audit vocabulary (the language a CISO has to use to defend the decision) is still partner-and-PS territory. The fourth is a lakehouse-fluent buyer-enablement curriculum, and it's the one I'd treat as the most important, because the gating constraint on how fast Lakewatch can take share is buyer education rather than technology: even at Databricks' scale the customer base capable of running the platform is smaller than the customer base capable of running a Splunk deployment, so until the curriculum exists the addressable market is "teams that already think lakehouse-native," a smaller cohort than "teams that have heard 'lakehouse-native' is the future."

Three independent analyst reads landed within weeks of the announcement, each surfacing something the marketing didn't, and I read them as things to plan around rather than pitches to repeat. HFS Research's point is that the 80% TCO framing reads as "more efficient," not "automatically cheaper," because for an organization already running Databricks at scale Lakewatch reduces marginal cost, while for an organization standing up Databricks specifically to run Lakewatch the platform cost is additive rather than subtractive, so the TCO math has to be modeled against the customer's starting state rather than against a generic SIEM baseline. Hugo Lu's point is that the "build your own SIEM" GTM motion is structurally different from the one that built Splunk's base: Splunk grew on "ingest everything, search later," a category that didn't require buyers to architect anything, whereas Lakewatch requires buyers to think in lakehouse primitives, a legitimate value proposition for sophisticated buyers but close to a non-starter for much of Splunk's installed base, so the category may take share from the top of the market while leaving most of the middle untouched. InfoTech's is the sharpest reframe of the three: for shops that already run Databricks, Lakewatch reads less as a new vendor decision than as a utilization decision on infrastructure they've already committed to, which is the framing that fits procurement (where "we're using more of what we already paid for" travels better than "we're adding another vendor"), while for shops that don't already run Databricks the framing is the opposite of helpful because the platform cost has to be underwritten before Lakewatch's value can show up.

The migration-from-Splunk story is the thread to track, because SiftD.ai's SPL translation isn't the same as the manual rule conversion existing detection-content migrations have to do. If the translation works at the corner cases (macros, lookups, the weird SPL conventions that pile up at scale), the migration cost curve flattens enough that the migration cost reality analysis may need a revision, and once the evidence lands that revision is probably worth a writing piece of its own. The matrix scores Lakewatch against the same workload archetypes it scores everything against, which means scoring it against the alternatives (Snowflake-with-Hunters, Cribl-augmented Splunk, ClickHouse-on-Iceberg, StarRocks) rather than against itself, and that's the discipline the disclosure at the top of this essay commits to.

Pull it back to the spine. Any vendor pitching 90%+ owes you the scope statement: what counted, against what baseline, in which scenarios, and the production number broken down by enrichment versus end-to-end investigation closure. If they attribute the number to NANDA specifically, or to "agent networks" generally, they've confused a discovery-and-trust result for an automation one, and that tells you how carefully they read. Honest numbers are a competitive advantage, because the discipline of citing a publicly-defensible practitioner number rather than the marketing-claim equivalent is the same discipline that lets you build automation that actually works: the teams that buy into 90%+ narratives tend to under-invest in the validation work that would have moved them from 10% to 30%, while the teams that internalize "the realistic ceiling is 30-40% and most of us are nowhere near it" tend to spend their budget on the analyst skills and detection engineering that get them there.

The maturity argument is the structural reason none of this is a shortcut. SANS publishes a Hunting Maturity Model (HMM) running from HMM0 (no hunting capability) through HMM4 (automated hunting), and the SANS 2024 SOC Survey reports that most organizations sit at HMM1 or HMM2 (ad-hoc and procedural hunting), with HMM3 (innovative, custom analytics) and HMM4 (automated) rare in the field, not because the tooling doesn't exist but because the data foundations and analyst skills don't. An agent-coordination layer doesn't move an organization up the maturity model on its own. If the underlying data is incomplete, the detection logic is stale, or the analyst workflow is built around tier-1 ticket-pushing rather than hypothesis-driven hunting, deploying an agent network on top of all that just automates the existing dysfunction faster, and now with a new identity layer to secure. There's no shortcut from HMM1 to HMM4; the shortcut doesn't exist, and the agent layer doesn't manufacture one. NANDA-style architectures may eventually let HMM3 and HMM4 organizations run their existing capability more efficiently and across more tools, and they may make the multi-vendor version of that safe to build, but they're not a substitute for the foundations, which is the same point at a different altitude as the field anecdote: fix the parse-map-correlate pipeline and instrument that the data flows before you trust the layer on top of it.

I'm not re-arguing two adjacent pieces here, because they carry their own weight. On where AI maturity actually sits, the early-automotive frame (past horseless-carriage to AI-native, but pre-seatbelt, capability outran safety) is the summer-of-AI piece. On grounding and deterministic verifiability (why "below the frontier" is targeting rather than weakness), the dimensional-modeling-for-AI argument is reinvented Kimball. Both are upstream of this one; this essay is the agentic-SOC-reality dimension of the same fair-broker frame.

A short coda on what to actually track, so this page doesn't re-accrete weight per future sweep. Watch the identity layer rather than the automation headline: NANDA, A2A, and MCP converging on agent-coordination primitives, and whether SIEM and EDR vendors ship capability registration. Watch the pipeline-layer consolidation: which of the six independents gets acquired, and whether the acquirers keep the data path open. Watch SPL-translation accuracy in production, because that's the single signal that moves the Splunk-migration cost curve. And watch for the named, scaled, production security reference that would move any of these vendors from Tier C to Tier B, because that's the evidence that's missing today, and its arrival is what would change the read. The honest framing isn't "agent networks will solve SOC automation"; it's that agent networks will need an identity and trust layer before they're safe to run across vendors, the practitioner ceiling for end-to-end investigation sits at 30-40% with most of the field below it, and the durable work is the same work it always was, which is the foundation under the agent rather than the agent on top.