Databricks did something in March 2026 that is worth reading carefully before reading individually. On March 24, the company launched Lakewatch — an agentic SIEM built on what Databricks calls the Open Security Lakehouse, with Adobe and Dropbox cited as private-preview customers. Days earlier, the same security team published DASF v3.0, the third major revision of the Databricks AI Security Framework, adding agentic AI as its thirteenth system component and introducing thirty-five new technical security risks alongside six new mitigation controls. The framework brings the total catalog to ninety-seven risks and seventy-three controls, with mappings to MITRE ATLAS, OWASP, NIST 800-53, and Cloud Security Alliance standards.
The two artifacts serve different functions. Lakewatch is an architecture-grounded product addressing the visibility, retention, and triage problems that have defined SIEM economics for a decade. DASF v3.0 is a risk-and-controls framework that catalogs what can go wrong inside agentic systems and proposes controls to mitigate each risk category. The product addresses one layer. The framework names another. Reading them as a pair is more informative than reading either alone, and it is the reading the corpus thesis is best positioned to do.
What Lakewatch Defines
Lakewatch’s architecture is precise and deserves to be described as Databricks describes it. The product decouples storage from compute. Telemetry lands in customer-owned cloud object storage in open formats — Delta Lake, Apache Iceberg — normalized to the Open Cybersecurity Schema Framework via Lakeflow Connect. Unity Catalog provides governance, access control, audit, and lineage. Compute costs are tied to query and agent execution, not to ingestion volume. Databricks reports up to eighty percent lower total cost of ownership compared with legacy SIEMs at multi-terabyte daily ingestion rates.
The agentic layer sits on top of that substrate. Agent Bricks is the framework for authoring detection-and-triage agents. Genie provides natural-language query and orchestration. The agents perform four publicly named functions: parsing and normalizing new log sources into OCSF, authoring net-new detection rules from threat intelligence, modifying existing rules in response to changed signals, and triaging and investigating alerts across identity, endpoint, and network telemetry. Detection-as-Code brings software-engineering practice — version control, automated testing, CI/CD deployment — to detection authorship.
Two acquisitions shipped alongside the product. SiftD.ai, founded by the creator of Splunk’s Search Processing Language and several lead Splunk search architects, contributes detection-engineering depth and large-scale threat-analytics expertise. Antimatter, founded by UC Berkeley security researchers, contributes what Databricks describes as provably secure authentication and authorization foundations for AI agents. The Antimatter integration is the closest piece of the Lakewatch architecture to in-loop agent governance, and its concrete integration semantics into Agent Bricks warrant separate examination.
The architectural reading: Lakewatch is the detection layer at lakehouse scale. It defines what enterprise-grade detection looks like when the storage tax is removed, when telemetry is unified across security and business data, and when authorship of detection rules becomes a continuous, agent-assisted activity rather than a quarterly review cycle. The product is well-scoped. It does what its architecture is built to do.
Two Layers, Named Carefully
The corpus has been building toward a distinction that this dispatch is the place to name plainly. Agentic security operates at two layers, and the difference between them is structural rather than incremental.
The detection layer reasons over traces. It operates after agent action — sometimes seconds after, sometimes milliseconds after, but always after the action has been emitted into telemetry. Its inputs are logs, alerts, correlated signals, and (with multimodal ingestion) audio and video evidence. Its outputs are detections, triage decisions, and analyst-facing investigation summaries. Detection rules — whether human-authored, agent-authored, or hybrid — describe attack patterns that have been seen well enough to be characterized. Lakewatch is an architecture-focused instance of the detection layer at petabyte scale.
The enforcement layer operates inside the agent loop. Its inputs are the agent’s proposed tool calls, memory reads and writes, planning steps, and authorization checks. Its outputs are gates: allow the tool call, deny it, require human approval, rewrite the parameters, terminate the loop. The enforcement layer does not wait for telemetry. It constrains the agent at the moment of action and refuses the action if a structural condition is not met. Research artifacts at this layer include VeriGuard‘s two-stage formal-policy framework with Nagini Hoare contracts and runtime monitoring (Miculicich et al., Google Cloud AI), AAGATE‘s composite remediation architecture, GuardAgent and AGrail as runtime monitors, Winston SMT-based action checking, and the Cognitive Control Architecture (Liang et al., Sichuan University) with its Intent Graph and Tiered Adjudicator design for indirect prompt injection defense on the AgentDojo benchmark.
The distinction is not a hierarchy. Both layers are necessary. A SIEM without an enforcement layer sees attacks faster but cannot prevent them at the point of action. An enforcement layer without a SIEM stops a known class of action but produces no enterprise-wide visibility into adversary behavior. They share an interface — the trace the detection layer reasons over is produced by the agent loop the enforcement layer constrains — but they do not substitute for one another, and they cannot be combined into a single product without losing the architectural properties that make each effective.
The category error to avoid is treating detection-layer maturity as enforcement-layer presence. An agentic SIEM with sub-second response is still operating on traces. It is not constraining the agent at the moment of action; it is reasoning over what the agent did. The speed of the response narrows the window. It does not close it.
What DASF v3.0 Catalogs
DASF v3.0 is the most carefully worked enumeration of enforcement-layer risks shipped by an industry author to date, and it deserves to be read as such. The framework names thirty-five new risk categories specific to agentic AI, organized around the agent’s operational loop. Memory poisoning, intent breaking, goal manipulation, cascading hallucination attacks, tool poisoning, prompt injection, and the cluster of threats associated with the Model Context Protocol — server-side, client-side, and the configurations between them. The framework explicitly names the Lethal Trifecta condition, the configuration under which indirect prompt injection can hijack an agent’s capabilities to perform malicious actions.
The six new controls address governance, observability, and defense-in-depth at the agent loop. Least privilege for tools, scoped permissions for each agent’s task, blast-radius containment when an agent’s authority exceeds what the immediate work requires. The controls map to platform features including Unity Catalog governance, the Agent Bricks framework, AI Gateway guardrails, and Vector Search security settings.
The framework’s contributor list is worth noting. DASF v3.0 lists practitioner contributors from Atlassian, Experian, and ComplyLeft alongside the Databricks security team. That contribution structure places DASF closer to standards-body adjacency than to vendor specification — a framework with industry practitioner co-authorship that Databricks stewards rather than owns outright.
The architectural reading: DASF v3.0 catalogs the risks that live at the enforcement layer. It names them precisely, maps them to existing risk frameworks, and proposes controls that practitioners can operationalize. This is the framework Databricks publishes for the layer that Lakewatch, as a detection-layer product, does not structurally reach. The relationship between the two artifacts is the standards-and-product relationship the corpus described in Series 11: frameworks define what must be done; products implement parts of that definition; the remainder is where practitioner architecture lives.
The reading is not that Lakewatch should reach the enforcement layer. It is that Databricks itself, in the same month, published the framework that names the enforcement-layer risk taxonomy and the product that addresses the detection-layer architecture. Reading the two together is the reading the practitioner needs.
Where the Architecture Still Lives
The honest accounting at the dispatch’s close.
The detection layer is now well-defined as enterprise-deployable product. Lakewatch is one instance, and the broader agentic-SIEM category — Google’s Agentic SOC, CrowdStrike’s Charlotte AI, SentinelOne’s Purple AI, Microsoft Sentinel’s agent-extension work — is the field’s response to the same problem. The economics arguments are real. The detection-authoring agents are real. The visibility expansion that comes from removing the ingestion tax is structurally important and is changing what defenders can see.
The risk taxonomy at the enforcement layer is also now well-defined. DASF v3.0, the OWASP Agentic Top 10, MAESTRO from the CSA and OWASP lineage, AIUC-1 from CAISI, NIST’s agent standards work, and the Five Eyes joint guidance form an increasingly convergent industry vocabulary for what can go wrong inside an agent loop. The taxonomy exists. The controls map to it.
What is not yet well-defined as enterprise-deployable product is the enforcement layer itself. The research cluster exists — VeriGuard’s near-zero attack success rate on AgentDojo with Hoare-contract policy enforcement, AAGATE’s composite remediation scores, the CCA Intent Graph and Tiered Adjudicator, GuardAgent and AGrail as runtime monitors, and the broader set of in-loop control architectures that have published since Q3 2025. None of these is yet a product category. None is yet a vendor selection a CISO can make in a procurement cycle. The work is architecturally real, empirically validated against benchmarks, and not yet composed into the kind of integrated enforcement-layer platform that detection-layer products like Lakewatch already provide.
Reading the trajectory from where the artifacts sit today: detection-layer maturity is arriving fast, with industry-grade products and standards-body-adjacent frameworks shipping in the same windows. Enforcement-layer maturity is arriving more slowly, with research-grade artifacts and academic benchmarks leading practitioner-deployable systems by some distance. The two layers will eventually compose. The composition is not yet a product.
For the practitioner reading this dispatch, the operational question is not which agentic-SIEM to deploy. The agentic-SIEM choice is a detection-layer choice and is well-supported by the architectures shipping now. The operational question is what to do at the enforcement layer in the meantime — what runtime controls to deploy on the agents the organization is itself shipping, what authorization boundaries to enforce structurally, what tool-call gates and memory-integrity contracts to build, what the in-loop equivalent of a SIEM is for the agents the organization deploys rather than the attackers the organization defends against. That work sits in the research cluster today. It is not yet a product. It is where the architectural work lives.
A separate question — whether a cognitive substrate of the kind described in recent system-theoretic work (Agentic AI for Cyber Resilience, December 2025) and meta-cognitive architecture proposals can serve as a unifying frame across both layers — is the deeper question the field is working toward. That question is not the subject of this dispatch. The subject is the layered reading of the two artifacts Databricks shipped in March 2026 and the layer they both, by construction, do not reach.
