Does DeepInspect replace a SIEM or SOC platform?

No. DeepInspect operates at the AI request boundary as the enforcement layer. A SIEM or SOC platform ingests logs from across the environment and runs detection and investigation. The two layers are complementary. DeepInspect feeds structured per-decision records into the SOC; the SOC correlates those records with cloud, identity, endpoint, and SaaS telemetry.

Why is detection on AI logs insufficient for prevention?

Detection runs after the event has been logged. For AI traffic, the event is the prompt or response leaving the regulated environment. A prompt containing PHI or M&A material that has been sent to a model cannot be unsent. Mandiant's M-Trends 2026 finding of a 22-second median attacker handoff time is the broader machine-speed problem. AI traffic specifically has the additional property that exfiltration through a prompt is one-shot.

What is the architectural difference between Panther and DeepInspect?

Panther ingests events into a customer-controlled data lake and runs Python detection content against the normalized event stream. DeepInspect sits in line between users or agents and LLM endpoints and evaluates each request before it reaches the model. Panther is detection on what was logged. DeepInspect is enforcement on what is being requested.

How do EU AI Act Articles 12 and 19 affect this decision?

Article 12 mandates automatic logging that survives the runtime state of the application. Article 19 specifies what goes in the log and sets the six-month retention floor. The deployer is liable. A log written by the application that consumed the AI response is the application attesting to its own behavior, which is the self-attestation problem. The enforcement layer that made the decision must write the record.

Is a lakehouse SOC enough for an AI-heavy environment?

It is necessary for cross-environment correlation, investigation, and response. It is not sufficient for prevention at the AI request boundary. AI workloads concentrate risk at the prompt-and-response layer, which lives upstream of the lakehouse SOC. Prevention belongs at the AI request boundary; investigation belongs at the lakehouse SOC.

Databricks Buys Panther: What the Security Lakehouse Race Means for Teams Weighing AI Detection Against Inline Enforcement

On June 16, 2026, Databricks announced its intent to acquire Panther, the cloud-native SIEM that has been a fixture in cloud-first security teams since 2020. It is Databricks' third security acquisition after Antimatter and SiftD.ai. SiliconANGLE's coverage describes the strategic intent as extending the Databricks security lakehouse with an "agentic SOC" capability that combines log ingestion, detection content, and AI-assisted investigation in one platform.

The deal is the loudest signal yet that the lakehouse-plus-SIEM-plus-AI category is consolidating. Snowflake bought Hunters. Crowdstrike bought Onum. Now Databricks owns Panther. The financial press will frame this as a SIEM consolidation play. The architectural question for security leaders running production AI workloads is different.

I want to walk through what an agentic SOC built on top of Databricks plus Panther can actually do for AI traffic, where its boundary sits, and what stays in a separate enforcement layer.

What Databricks plus Panther produces

Panther's product runs detection content as Python over normalized log events landing in a customer-controlled data lake. Databricks contributes the lakehouse storage and SQL warehouse layer plus its Mosaic AI agents framework. The combined offering, per the Databricks press release, is meant to let security teams ingest cloud logs, identity events, endpoint telemetry, and SaaS audit trails into one warehouse, then run AI agents over that warehouse to triage alerts, summarize incidents, and propose containment actions.

The architectural pattern is detect-then-respond. An event is logged, the event lands in storage, a detection rule fires, an agent reads the alert, and an analyst or downstream action takes the response step. The cycle time has been compressed by AI assistance from hours to minutes in Panther's own benchmarks, but the cycle still happens after the traffic has already reached the systems that produced the log.

For most enterprise security use cases this is the right architecture. Detection on lateral movement, on credential misuse, on anomalous data egress, on identity drift. The lakehouse-plus-agentic-SOC story is strong for all of them.

Where the architecture lands for AI workloads

AI traffic is a different shape than the traffic the SOC is used to. A prompt to a model is HTTP traffic between an authenticated user or agent and an LLM endpoint. The decision boundary lives at the API call layer, not at the perimeter, not at the endpoint, not at the identity provider.

The lakehouse SOC sees what an LLM endpoint logged. If the endpoint logged the prompt content, the SOC sees the prompt content. If the endpoint logged only the metadata, the SOC sees only the metadata. Detection content can fire on what is in the logs. Detection content cannot fire on what was never logged.

This is the architectural ceiling on detection-based AI security. It is not a product limitation that the next release fixes. It is where the traffic visibility actually sits.

What detection cannot do at machine speed

Google Mandiant's M-Trends 2026 report, based on 500,000+ hours of frontline incident response, found that the median time between initial access and handoff to a secondary threat group collapsed from over 8 hours in 2022 to 22 seconds in 2025. AI-enabled attack tooling has compressed the attacker decision loop into the seconds range.

Detection content reading from a lakehouse runs after ingestion. Even with streaming ingestion, the path is event → ingest → normalize → rule evaluation → alert → triage → response. Each step is measured in seconds or minutes. The aggregate is slower than the 22-second handoff window.

For AI traffic specifically, the relevant question is not "did the SOC catch this alert in three minutes." It is "did the prompt that exfiltrated regulated data ever reach the model in the first place." A prompt that contains PHI, PII, source code, or M&A material is a one-way trip. Once the model has processed it, the data has left the regulated environment. The SOC can document what happened. The SOC cannot put the data back.

This is why prevention at the AI request boundary is a separate architectural concern from detection over AI logs. Both are needed. Neither replaces the other.

What an inline policy gateway adds

An identity-aware policy gateway sits between authenticated users or agents and LLM endpoints. Every request is evaluated against who is asking, what role they hold, what data classification the prompt content carries, and what policy applies to that combination. The decision happens before the request reaches the model. Enforcement overhead in production is under 50 ms. LLM inference takes 500 ms to 5 seconds. The overhead is invisible relative to the model's response time.

A blocked request never reaches the model. A blocked response never reaches the user. The audit record for the decision is written by the gateway, not by the application that issued the request. This is the self-attestation separation that regulators expect under EU AI Act Article 12 and that mortgage regulators expect under Fannie Mae LL-2026-04.

Three properties the gateway provides that the SOC cannot

The gateway produces per-decision audit records bound to identity, classification, policy version, and outcome. The SOC ingests whatever the application emitted, which may omit any of these.

The gateway fails closed on policy ambiguity. The SOC fails open by definition; an event the SOC does not see is an event the SOC does not respond to.

The gateway operates on prompt and response content directly. The SOC operates on whatever the upstream system decided to log about the prompt and response.

How the two architectures fit together

A mature AI security architecture combines both layers. The policy gateway enforces in line and produces the structured audit record. The lakehouse SOC ingests those audit records along with everything else the security data lake consumes. Detection content on the lakehouse fires on patterns that span AI traffic and the rest of the environment. The investigation agents in the SOC read the policy gateway's audit records as evidence, not as the only signal.

The choice is not between detection and enforcement. The choice is between an architecture that has one of them and an architecture that has both. Teams that buy only into the lakehouse SOC story get a strong investigation capability and zero prevention at the AI request boundary. Teams that buy only into the policy gateway story get prevention but lose the cross-environment correlation that the SOC provides.

The June 16 deal makes the lakehouse SOC offering stronger. It does not change where the AI request boundary sits. The independent control plane between users and models is still a separate purchase, and it should be.

Regulatory framing

EU AI Act Article 12 mandates automatic logging that survives the application's runtime state. Article 19 sets the retention floor at six months and requires identity context in the log. Article 99 sets the penalty tier at €15 million or 3% of global annual turnover for high-risk non-compliance. The August 2, 2026 deadline applies to high-risk systems already in scope.

A lakehouse SOC ingests logs after the fact. The question regulators ask is not "did the SOC eventually receive this log." The question is "who decided that this AI request was permitted, and what record proves that decision was made." That record must come from the enforcement layer that made the decision, and the enforcement layer must be independent of the application that consumed the AI response.

NIST's AI agent identity and authorization framework codifies three pillars. Pillar 1 is identity context attached at the request layer, owned by the application. Pillars 2 and 3 are delegated authority and action lineage, owned by the enforcement layer. The SOC consumes Pillar 3 records. The SOC does not produce them.

DeepInspect

This is the gap DeepInspect closes. DeepInspect is the identity-aware policy gateway that sits at the AI request boundary, in front of OpenAI, Anthropic, Bedrock, Azure OpenAI, Vertex, and self-hosted endpoints. Every request is evaluated against identity, role, data classification, and policy version. The decision is made inline, the record is written by DeepInspect rather than by the application, and the record is structured for ingestion into a SOC like the Databricks plus Panther stack.

Teams that already plan to consolidate on Databricks for security telemetry gain a fuller picture when DeepInspect feeds the lakehouse with per-decision AI audit records. The SOC investigates patterns; DeepInspect prevents the request that the pattern would have shown.

Book a technical deep dive at deepinspect.ai.