What does 22 seconds actually measure?

Google Mandiant's M-Trends 2026 report measured the median time between initial access (the moment an attacker first gained a foothold) and handoff to a secondary threat group. The median collapsed from over 8 hours in 2022 to 22 seconds in 2025. The implication for security architecture is that any control that depends on a human reviewing an alert has lost the race at the median attack.

Does the 22-second figure apply to AI-specific attacks?

The Mandiant figure is the cross-industry median. AI-specific attacks compound the problem rather than reduce it: Foresiet measured AI-enabled cyberattacks rising 89% year over year in early 2026, and automated agentic attackers compromised 600+ FortiGate firewalls across 55 countries with no human operator. The architectural answer (inline enforcement, deterministic decisions, identity-bound records) applies regardless of whether the attacker is using AI or not.

Why is sub-50 ms enforcement overhead acceptable?

LLM inference takes 500 ms to 5 seconds. Enforcement overhead of under 50 ms represents a few percent of the model's own latency, which is invisible to the user. The math defeats the log-and-alert default because the inline alternative produces no perceptible latency penalty. Production deployments routinely measure tail-latency under 100 ms for the full enforcement decision plus audit commit.

Where does the enforcement layer sit in our existing service mesh?

Service-mesh integration through Envoy, Istio, or Linkerd is one of the production deployment patterns. The mesh intercepts outbound HTTPS to LLM endpoints and routes through the enforcement proxy. The application continues to call the model API as before; the proxy is transparent to the application's HTTP client. Sidecar deployment and gateway integration are alternative patterns that satisfy the same architectural position.

What is the difference between inline enforcement and a WAF?

A web application firewall evaluates inbound HTTP requests against rule sets for known attack patterns. It operates in front of the application. Inline AI enforcement operates in front of the LLM endpoint, on the application's outbound traffic. The rule sets and the unit of policy (prompt content versus URL patterns and HTTP bodies) are different. The architectural position is also different: WAF protects the application; inline AI enforcement protects the deployer's data from leaving through the model API.

22-Second Breach Windows: Why AI Enforcement Must Be Inline

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. At that tempo, controls that depend on log review, ticket queues, and human acknowledgment have already lost. AI-enabled attacks compound the problem: Foresiet measured AI-enabled cyberattacks rising 89% year over year in early 2026, including an automated tool that compromised 600+ FortiGate firewalls across 55 countries with zero human operator involvement.

I want to walk through what changes at the architecture layer when the response window collapses from hours to seconds, and what inline enforcement at the AI request boundary has to do to operate at that cadence.

AI deployments as high-value targets

An AI deployment is an attractive target for three reasons. The traffic concentrates regulated data into prompt payloads. The same employees who handle customer records, source code, and financial planning paste fragments of those into AI prompts during routine work. The inference latency creates a usable window for an attacker who can intercept or modify the request. And the audit infrastructure for AI traffic is often immature, which means an attacker who exploits an AI request boundary may not be discovered until well after the fact.

IBM's Cost of Data Breach Report studied 600 breached organizations and found that one in five experienced breaches linked to shadow AI. Those breaches cost on average $670,000 more than the cross-industry baseline and took 247 days to detect. Customer PII exposure appeared in 65% of shadow AI breaches versus 53% across all breaches.

The combined picture: AI traffic is high-value, fast-moving, and poorly instrumented. The architecture has to compensate at the request layer.

How most organizations handle AI traffic today

Three patterns dominate, none of which scales to the 22-second tempo.

Network DLP and TLS inspection

The HTTPS POST to the LLM endpoint is encrypted at the network layer. Network DLP runs underneath the encryption. Without TLS inspection configured for AI provider domains and prompt-aware parsing, DLP sees outbound HTTPS to a recognized destination and produces no useful alert. With TLS inspection configured, document-level classification produces false negatives across most prompt traffic because prompt context windows are unstructured natural-language text composed of fragments.

Even when configured correctly, network DLP runs in asynchronous mode: the alert fires after the prompt has reached the model. The prompt has been sent. The data has left the environment. The detection is forensic, not preventive.

Application logs and SIEM

The application logs the model call. The SIEM ingests the log. A rule fires when the log matches a pattern. The pattern requires the log to exist, the application to have committed it correctly, the SIEM to have ingested it within the alerting window, and an analyst to read the alert. Each step has its own latency. The aggregate latency is measured in minutes at best.

Application-controlled logs also fail under selective logging, suppression, and crash-loss conditions. The system under audit is the system generating the audit record.

Model-side guardrails

Model providers ship safety training. The guardrails live inside the inference process. They are probabilistic. Stanford Trustworthy AI research and the AIUC-1 Consortium briefing measured significant degradation under targeted fine-tuning and adversarial pressure. Guardrails reduce some categories of off-policy output and produce no deterministic decision or identity-bound record.

What enforcement at machine speed requires

The control plane has to operate inline. The decision happens before the prompt reaches the model. The blocked request never produces an exfiltration event. The redacted request reaches the model with sensitive fields removed. The audit record is committed before the model response returns.

Five properties define an inline enforcement architecture.

Position in the path

The enforcement layer sits at the HTTP AI request boundary, between the application or agent and the LLM endpoint. The proxy intercepts every call to OpenAI, Anthropic, Bedrock, Azure OpenAI, Vertex, or self-hosted inference endpoints. Sidecar deployment, service-mesh integration through Envoy or Istio, and gateway integration through Kong or Apigee all support this position.

Deterministic policy evaluation

Per-route policies attach to model endpoints. Per-role policies attach to user and agent roles. Per-decision policies attach to the data classification of the prompt. The evaluation is deterministic and fails closed: ambiguity or error defaults to deny.

Prompt-level classification

The classifier reads the prompt body before the request reaches the model. PII, regulated data, source code, and pre-announcement financials are detected at the field level. The classifier feeds into the policy decision point, which selects pass, redact, or block.

Identity binding

The identity object the application supplies (verified user identity, agent identity, role, delegation scope) travels with every request. The policy decision references the identity. The audit record captures the identity verbatim.

Latency math

End-to-end enforcement overhead in production tests measures under 50 ms. LLM inference takes 500 ms to 5 seconds. The enforcement overhead is invisible relative to the model's response time. There is no architectural cost to making enforcement inline. This is the math that defeats the log-and-alert default: the inline alternative produces no user-visible latency penalty.

What enforcement at machine speed prevents

A blocked prompt never reaches the model. The data the prompt contained never leaves the environment. The vendor never sees the regulated fields. The training set never absorbs them.

A redacted prompt reaches the model with the sensitive content removed. The model's response is shaped against the redacted version. The deployer's audit record captures both the original and the redacted prompt with the redaction policy that applied.

An anomalous request is flagged in the audit record before the response returns. Detection is synchronous with the request, which means the response time for follow-up controls runs from the moment of the decision rather than from the moment of log ingestion.

The Mandiant 22-second window does not collapse for inline enforcement. The decision fires in the request-response cycle.

Compliance lens

EU AI Act Article 12 mandates automatic recording of events over the system lifetime for high-risk AI systems, effective August 2, 2026. The automatic recording requirement implies that the records are structural to the system's operation, not optional and not dependent on application code being correct. Inline enforcement produces structural records because every request passes through the proxy.

IBM's launch of an Autonomous Security Service on April 15, 2026 specifically to counter machine-speed threats indicates how the major vendors view the tempo. The architectural answer for AI deployments is the same: inline enforcement, identity-bound decisions, independent audit records.

NIST AI agent identity and authorization framework Pillars 2 (delegated authority) and 3 (action lineage) require per-request evaluation and structured audit records. Inline enforcement is the architectural pattern that satisfies both pillars at machine speed.

DeepInspect

This is the architecture DeepInspect was built to provide. DeepInspect sits at the AI request boundary as an external enforcement layer between the application or agent and the LLM API. The proxy reads the identity object the application supplies, evaluates per-route and per-role policies, applies prompt-level classification, and produces a per-decision audit record signed at the moment of evaluation.

Enforcement overhead measures under 50 ms in production tests. The proxy is model-agnostic and works in front of OpenAI, Anthropic, Bedrock, Azure OpenAI, Vertex, and on-prem inference endpoints.

If your AI security posture depends on logs reviewed after the fact and rules that fire from ticket queues, the 22-second window has already collapsed past the control plane.