Inference Hooks and the New DLP Boundary for AI Prompts

In Brief

Anthropic’s inference hooks beta routes every governed Claude Enterprise prompt and tool result to a customer-operated security server for an allow-or-deny verdict before inference — moving DLP enforcement from the network path into the model vendor’s own request path.
The boundary sees the transcript as the user sees it, including MCP tool results and extracted attachment text, but never raw image bytes — so a screenshot of a document passes uninspected — and verdicts can only allow or deny, not redact.
Enforcement adds a policy-server round trip to every model turn under a five-second default timeout, and Anthropic publishes no added-latency figure; shadow mode on your own traffic is currently the only way to price it.
A webhook failure is never treated as a deny: the fail-open-or-fail-closed setting, combined with a circuit breaker that only an administrator resets, means a broken deployment can silently stop enforcing.
Whether an LLM classifier at this boundary beats the regex DLP it replaces appears to depend on the threat model: vendor-reported false-positive reductions address accidental leakage, while published evasion research reaches up to 100% bypass against shipped guardrail classifiers in some configurations.

Why This Matters

For a decade, stopping sensitive data from leaving the organization meant owning the network path — a forward proxy, TLS interception, an agent on the endpoint. Within roughly two weeks this summer, a model vendor, a hyperscaler, and an academic group each shipped or proposed the same alternative: inspect the content inside the inference request path, and gate inference on a policy verdict the customer defines. The July authorization-wave research that moved the tool-call decision outside the agent’s context answered who may act. This boundary answers the complementary question — what data may cross — and any team running Claude Enterprise, an Azure AI estate, or an MCP tool fleet now has to decide whether to operate it, what it genuinely covers, and what it costs on every single request.

Key Findings

Three arrivals in two weeks say the architecture is convergent, not proprietary

Anthropic launched inference hooks on August 5, 2026, in beta for Claude Enterprise. The pitch is a checkpoint that lets compliance teams “inspect and enforce policy on every prompt and tool call response before they reach Claude.” Before the model runs, Anthropic sends the conversation to an AI security server the organization or its vendor operates; the server returns allow or deny, and a denied request never reaches the model. Bandwidth’s VP of Information Security, quoted in the announcement, calls it a “checkpoint to inspect what’s flowing to Claude in real time, before the model ever sees it.”

Microsoft occupies the same position for API traffic. The AI Gateway tier of Azure API Management entered public preview in late July: one governed runtime endpoint in front of Foundry, Azure OpenAI, AWS Bedrock, Google Vertex, OpenAI, and Anthropic models, with policies configured as portal cards. Microsoft’s framing is explicit that “the AI Gateway extends governance beyond models to the MCP servers and tools agents use to interact with enterprise systems.” InfoQ’s coverage reads it as a control plane built around models, MCP servers, and tools rather than APIs.

The academic arrival came two days before Anthropic’s. PolicyGuard, posted August 3, proposed pre-model interception for coding agents in which an LLM classifier evaluates prompts against plaintext policy files, in place of regex rules or vendor-managed classifiers. The paper was withdrawn days later — “submitted prior to completion of a required institutional review process,” with a stated intent to resubmit — so its evaluation claims carry no weight until it reappears. What survives the withdrawal is the timing: an independent group converged on the same interception architecture in the same week it shipped as a product.

The topologies are not the same — Anthropic’s request path calls out to a customer-operated verdict server, Azure’s is a managed gateway that applications call instead of the backends, and PolicyGuard’s classifier runs inside the agent itself — but all three put a policy decision in front of the model. Convergence from three directions at once suggests the position, not any one implementation, is the finding. TheNextWeb’s coverage frames the launch against a wave of startups raising hundreds of millions to build AI security control layers — the vendor is now opening a native socket where that layer plugs in.

Three topologies, one interposition: each design puts a policy verdict between the request and the model — from a customer-run verdict server, a managed gateway, or a classifier inside the agent itself. Adapted from Anthropic’s inference-hooks documentation, Microsoft’s AI Gateway overview, and the PolicyGuard paper.

The position being vacated is the TLS-intercepting proxy

The incumbent answer to AI data loss is network DLP. Zscaler’s guidance for securing generative AI is representative: “Zscaler’s inline SSL decryption provides complete visibility into the content/queries that users post to the ChatGPT site and the downloaded content,” with DLP dictionaries blocking uploads of card numbers or source code at the proxy. That works where the organization owns the path.

Check Point’s analysis of why the native hook matters names the cost of that ownership: “Web gateways and Data Loss Prevention (DLP) tools were designed for websites and SaaS applications, not conversations with AI models,” and conventional enforcement meant “owning the path to it: a forward proxy, TLS interception, an agent on every laptop. Each one is a deployment project, and each one breaks somewhere.” The hook inverts the geometry. Evaluation happens inside the vendor’s infrastructure against the customer’s server, so there is nothing to install on devices and no TLS to break. Check Point reports its own integration takes minutes: paste an endpoint URL and a signing secret into Claude Enterprise settings.

The integration market formed immediately. Published integrations in the first week included Palo Alto Networks, Proofpoint, Zscaler, Check Point, and Akto, per one running analysis of the launch, which also notes Netskope chose to integrate the after-the-fact Compliance API instead. One protocol detail deserves a flag for anyone building rather than buying: the launch post describes the transport as “a signed WebSocket connection to a security server,” while the beta protocol documentation specifies per-request HTTPS POSTs signed under the Standard Webhooks specification. Build against the documentation, not the press release.

Anthropic’s documentation is unusually precise about visibility, which makes the coverage map checkable rather than inferred. The security server “sees what the user sees: transcript text, tool calls and their results, and text extracted from attachments. It never receives raw file or image bytes, system prompts, or Anthropic-internal context.” Each request carries the untruncated conversation, the acting user’s identity, the model, and a session identifier.

The blind spots are just as enumerable, and they matter more:

Images are invisible. Attachments arrive as metadata plus extracted text; the docs state plainly that “image-only content (for example, a screenshot of a document) is not inspected.” Screenshotting a document is among the oldest DLP evasion moves, and it survives this boundary entirely.
Verdicts are binary. Allow or deny; “rewriting or redacting a prompt is not supported.” Traditional DLP practice — mask the card number, let the rest through — has no equivalent here yet.
Egress is not gated. The only hook event shipped is prompt, which fires before inference; “response-side enforcement is planned as a later event.” The model’s own output appears in the transcript of the next turn, so the server eventually sees it, but it cannot block delivery to the user. The exfiltration channel that runs through model output is uncontrolled for now.
Scope has hard edges. The hook governs claude.ai, Cowork, and Claude Code sessions in a Claude Enterprise org. Platform (API) organizations are out of scope, Bedrock and Google Cloud deployments are excluded, and voice mode is not covered.

None of this makes the boundary useless — it makes it one layer. But a team retiring its network controls because “DLP now runs at the model” would be trading enumerated coverage for enumerated gaps.

Tool results are prompts too, which quietly turns DLP into an MCP checkpoint

The architecturally interesting property is what happens in agentic sessions. When Claude calls a tool — an MCP connector, a skill, a plugin — the tool’s result enters the next inference request, and each inference request fires the hook. The documentation’s own flow diagram marks two hooked points: where the user’s prompt arrives, and where the tool result returns. The announcement states the same inspection covers “MCP connectors, skills, and plugins.”

The transcript schema is built for this: tool_result blocks carry the tool’s name explicitly, “so a policy can condition on tool identity without cross-referencing an earlier block.” A policy server can therefore treat data returned by a connector differently from data typed by a user — deny a CRM connector’s response that carries bulk PII toward the model, say, while allowing the user’s question about it. Akto’s integration leans on exactly this, scanning MCP connector responses before they return to the model and screening for injection patterns alongside credentials and PII. In effect the DLP boundary doubles as a second-line prompt-injection checkpoint for tool-borne content.

Two cautions temper the enthusiasm. The docs warn that the source.application field is “advisory routing metadata, not a trust boundary: don’t rest a security-critical policy decision on it alone.” And the inspection point sits downstream of the tool call itself — the boundary sees what the tool returned, not what the agent sent to the tool, so data pushed out through a tool’s arguments is visible only as tool_use input in the transcript of the following turn.

On the Azure side, the gateway federates remote MCP servers, OpenAPI-defined backends, and a built-in connector library behind one endpoint with a content-safety policy card covering “safety checks for prompts and responses” per Microsoft’s overview — but its preview access model is coarse: “A key is gateway-scoped: it reaches every model and tool.” The enterprise MCP gateway pattern mapped in the spring anticipated this consolidation; what is new is a hyperscaler shipping it as a managed tier.

The latency price is a round trip per model turn, and nobody has published the bill

The protocol’s numbers are documented; the operational cost is not.

Figure	Value
Verdict timeout	5,000 ms default; configurable 1–10,000 ms
Timeout budget covers	connection, TLS handshake, request, and response
Retries	exactly one, after 100 ms, on connection failure only
Maximum request body	10 MB; transcript sent untruncated
Verdict response read	first 64 KiB
Hook events shipped	one (`prompt`); response-side planned
Anthropic-published added-latency figure	none

All figures are from the integration documentation, whose own statement of the cost model is blunt: “Enforcement adds your AI security server’s round trip to the latency of every governed request in your organization.” The guidance beyond that is qualitative — keep the verdict fast, load-test before a large rollout.

The multiplier for agent workloads is the part worth doing arithmetic on. A Claude Code session that makes forty tool calls fires the hook on every resulting inference request, and each request re-sends the full transcript, which grows as the session does. The payload ceiling is 10 MB per request.

Anthropic’s sample servers all carry the same comment — drain the body, “transcripts can be megabytes” — which reads as a warning from load testing. A policy server that adds 200 ms per verdict adds it per turn, not per session, and a slow one can consume a large fraction of the five-second default budget on transfer alone. No vendor in the integration ecosystem has published verdict-latency benchmarks either, which for a component on the critical path of every request is a gap worth pressing sales teams on.

Fail-open or fail-closed is the real policy decision, and the failure semantics are subtle

The protocol takes a firm position on failure: a webhook failure is never converted into a deny. Timeouts, non-200 responses, unreachable endpoints, and unparseable verdicts all fall through to an org-level failure-handling setting — block the request, or let it proceed uninspected. That single toggle is the deployment’s actual security posture. Fail-closed puts the policy server in the availability path of every Claude request in the company. Fail-open means any outage, however brief, is an enforcement gap.

Two documented mechanics sharpen the choice. First, sustained failures trip a circuit breaker: Anthropic stops contacting the server and applies failure handling to everything, and recovery is manual — an administrator must fix the server and re-enable enforcement. One analysis of the launch draws the resulting failure state precisely: a fail-open setting plus a tripped breaker yields “an organization that believes it is enforcing policy and is not, until somebody checks the console.” Second, a mundane configuration error produces the same hole: transcripts run to 10 MB, common server defaults cap request bodies far lower (nginx at 1 MB), and per the docs a rejected body is a webhook failure — so “under Allow the request failure handling an oversized prompt would reach the model uninspected.” The largest prompts, often exactly the ones carrying bulk pasted data, would be the ones that skip inspection.

The rollout tooling acknowledges the stakes: shadow mode observes verdicts on live traffic without blocking, a percentage rollout inspects a chosen fraction of requests, and role exclusions exempt chosen groups. Denials land in the org’s compliance activity feed with the server’s reference ID, so enforcement is at least auditable after the fact.

An LLM classifier at the boundary trades regex’s noise for adversarial brittleness

The interception point is settled architecture; what evaluates content there is not. The incumbent is pattern matching, and its failure mode is noise. Cyberhaven’s survey data puts the average share of DLP alerts that are false positives at 51%, with 65% of security teams reporting they are overwhelmed by benign alerts; its canonical example — “a policy built to detect Social Security numbers will fire on any nine-digit string in the right format” — is the whole genre in one sentence.

Semantic classification is the pitched replacement: Spin.AI claims organizations adopting AI-powered DLP report up to 90% fewer false positives — a figure that traces back to Cyberhaven’s claim for its own product, which pairs AI classification with data lineage, not to any measurement of a standalone LLM classifier at an inference boundary. Read it as marketing until measured on your own traffic; the direction still matches the well-documented weakness it targets. PolicyGuard’s policy-as-prompt design is the maximal version of the same bet, and its withdrawal means the bet currently has no peer-reviewed evidence behind it.

The other side of the trade is documented too. Hackett and colleagues tested six shipped guardrail classifiers — Microsoft’s Azure Prompt Shield and Meta’s Prompt Guard among them — against character-injection and adversarial-ML evasion, “achieving in some instances up to 100% evasion success.” The attack class matters more than the number: Unicode homoglyphs and zero-width characters that preserve meaning for the downstream model while shifting what the classifier sees are a plausible threat to any text classifier sitting in the same request path — though transfer beyond the tested systems is a hypothesis, not a result, and the paper’s own limitations section confines generalizability to the guardrails it evaluated. That study targeted injection and jailbreak detectors rather than DLP scanners, and no published work has yet attacked an inference-hook-style DLP deployment specifically.

The honest synthesis splits by threat model. Against accidental leakage (an engineer pasting a customer export into a prompt) there is no adversary, evasion research is irrelevant, and semantic classification plausibly wins on noise — the case for better recall is structural rather than measured, since no published source pits an inference-boundary classifier against regex on the same traffic.

Against deliberate exfiltration, by an insider or by an injected agent, an LLM classifier has to be treated as bypassable — the published attack recipes target its nearest classifier neighbors, not DLP itself — and deterministic detectors (entropy-based secret detection, exact fingerprints) retain the virtue of being hard to talk out of a match. A boundary policy that layers both, rather than replacing one with the other, is the defensible configuration. There is also a cost asymmetry: classifying semantically at the boundary means running another model on every request, which compounds the latency and availability questions above.

Practical Implications

If you run Claude Enterprise, deploy in shadow mode this quarter — even with an always-allow server. An archive-only server that returns allow and persists each frame is the documented minimal integration, it produces a real-time transcript feed as a side effect, and it measures your organization’s actual latency distribution and would-be denial rate before anything blocks. The enforcement decision then rests on your data instead of the vendor’s.
Treat the failure-handling toggle as the security decision it is, and monitor the breaker. Fail-closed requires engineering the policy server like tier-one infrastructure — it now sits in the critical path of every governed request. Fail-open requires alerting on webhook failure rates and circuit-breaker state, because the documented failure mode is silent non-enforcement until someone checks the console. Choosing without monitoring is choosing fail-open with extra steps.
Engineer the boring parts of the server first. Raise body limits to the 10 MB ceiling, verify signatures over raw bytes with a standard base64 decode, deduplicate on the delivery ID, keep verdicts well under a second, and accept both secrets during rotation. Several of these have documented sharp edges, and the body-limit one silently un-enforces your largest prompts.
Write tool-identity-aware policy from day one. The transcript hands you the tool name on every result block. A policy that distinguishes connector-returned data from user-typed data — and screens tool results for injection patterns, not just secrets — extracts the boundary’s real advantage over the network proxy it replaces.
Do not retire the network layer yet. Images pass uninspected, model output is ungated until the response-side event ships, and API organizations, Bedrock, Vertex, and voice sit outside the hook entirely. Gusto’s pattern from the auto-mode rollout — routing “its MCP traffic through a governed proxy layer with tool guards and prompt inspection” so scoping happens before any classifier weighs in, per Anthropic’s production write-up — is the right shape: the hook is one layer in depth, not the boundary.
On Azure, pilot the AI Gateway tier but design around key scope. It is preview software in two regions (East US 2 and Sweden Central) with no SLA and unannounced pricing, and a runtime key currently reaches every published model and tool. Issue one key per application and environment, as Microsoft itself advises, and treat finer-grained authorization as a gap the preview has not yet closed.

Open Questions

What does the response-side event look like, and when? Egress enforcement is “planned as a later event” with no published date or schema. Until it ships, the boundary inspects what enters the model but cannot stop what leaves it — and whether the verdict vocabulary grows beyond allow/deny (redaction, rewriting) is unstated.
What is the real latency distribution at fleet scale? Neither Anthropic nor any integration vendor has published verdict-latency benchmarks, and the per-turn, full-transcript re-send model means agentic workloads pay a cost that grows with session length. Public p95 figures from a large deployment would settle whether five seconds of default budget is generous or optimistic.
Does allow/deny survive contact with users? A hard deny with a 500-character reason is a very different UX from the coach-and-redact patterns mature DLP programs use. Whether enterprises hold the line on deny verdicts or pressure the vocabulary toward masking is an open product question with a security consequence either way.
Will the verdict protocol standardize across vendors? The request-signing already rides the Standard Webhooks specification, and several major DLP vendors built to the schema within days of launch. Whether OpenAI and Google ship compatible hooks — turning the AI security server into a portable, vendor-neutral component — or each opens a proprietary socket will decide whether this becomes an interface or a lock-in surface.
How resistant are boundary DLP classifiers to deliberate evasion? The published evasion results target injection and jailbreak classifiers, not DLP scanners at an inference hook. Someone will run that study; a result showing homoglyph-smuggled secrets sailing past shipped semantic DLP would reset the classifier-versus-regex debate on the adversarial half of the threat model.
Does PolicyGuard survive review? If the withdrawn evaluation reappears intact, the policy-as-prompt design gets its first citable evidence; if it does not, the architecture still stands on the shipped products, but the research record for LLM-classified DLP stays empty.

Scout: DLP at the Inference Boundary — Inspecting Prompts and Tool Results Before the Model Sees Them