On August 5, 2026, Anthropic shipped inference hooks for Claude Enterprise: an inline checkpoint that lets an organization allow or deny each governed request before the model runs. Anthropic's announcement presents the feature as inline data loss prevention. The label is accurate, and it undersells what shipped. The hook is a general enforcement point at the model boundary, and it deserves a closer reading than a feature name allows: what does it receive, what can it decide, and where does its authority end?
We read the full protocol documentation, end to end. Here is what the mechanism provides.
What Anthropic shipped
The idea is simple to state. When a user in a Claude Enterprise organization submits a prompt, Anthropic pauses. Before the model runs, it sends the conversation transcript over HTTPS to a server your organization operates (Anthropic calls it an "AI security server"). Your server answers with a small JSON verdict: {"action": "allow"} or {"action": "deny"}. A denied request never reaches the model. The user sees a block message assembled from your per-request deny_reason plus a standing message your admins configure, and the denial lands in the org's compliance Activity Feed. Figure 1 traces the full round trip.
Your server gets a configurable verdict window of 1 to 10,000 milliseconds, 5 seconds by default, and that budget covers the whole exchange: connection, TLS handshake, request, and response. Anthropic retries exactly once, after 100ms, and only if the connection attempt failed. Every request is signed with HMAC-SHA256 per the Standard Webhooks spec, so your server can prove the caller is Anthropic and not someone who found your endpoint URL.
Three details tell you Anthropic thought about production reality:
- Shadow mode. You can run verdicts against live traffic without blocking anything, tune your policy on real usage, then flip to enforcement. Nobody has to get blocked on day one.
- A rollout percentage. Inspect 5% of requests, then 50%, then 100%.
- A circuit breaker. If your server fails persistently, Anthropic stops calling it and applies your failure policy to everything until an admin intervenes.
Figure 1 · The verdict round trip. Steps 2 and 3 repeat for every governed inference request, including each iteration of an agentic session.
The architectural significance is easy to miss under the DLP branding. Inline controls at the model boundary exist elsewhere: Google's Model Armor screens Gemini Enterprise traffic on Google's infrastructure, and Microsoft's Purview DLP can block Copilot prompts that carry sensitive data. Both are first-party filters the customer configures but the platform evaluates. Amazon's Bedrock Guardrails follows the same pattern for teams building on Bedrock, and OpenAI currently offers no inline control on ChatGPT Enterprise at all; its Compliance API exports activity after the fact. Anthropic went a step further than any of these: here the verdict comes from a server the customer or its security vendor operates, running arbitrary policy code against the full transcript. Not a browser plugin, not a network proxy, not an endpoint agent. The hook runs after the request leaves the client and before the model sees it, which means it covers claude.ai on the web, the desktop app, Claude Code in a terminal, and Cowork sessions, uniformly, with nothing installed on any device. If a request is governed, it goes through the hook. There is no route around it from the client side.
That is a real property, and it comes from the position itself: no client-side or network control sees governed traffic with the same uniformity.
What your server sees
The request body is the conversation as the end user sees it, up to the moment of inference. Concretely, each frame carries:
- The full message transcript, untruncated, up to 10 MB
- Tool calls (tool_use blocks with the tool name and arguments) and tool results (output text, error flag, tool name)
- Attachments as metadata plus extracted text: filename, media type, size, and the document text, audio transcript, or link metadata when available
- The actor: a stable user ID and email address when available
- The source application (claude-ai, claude-code), the model ID, and a session identifier
Equally important is what it never sees: system prompts, tool definitions, Claude's hidden reasoning, Anthropic-internal context, and raw file or image bytes. The transcript is the user-visible conversation, nothing more.
Two consequences follow directly.
First, your policy engine has real material to work with. It can condition on who is asking, from which surface, with which model, carrying which tool traffic. The tool_result block even repeats the tool name so a policy can key on tool identity without reconstructing the conversation graph. This is enough to build serious enforcement, not just regex-over-prompt.
Second, the blind spots are structural, not incidental. A screenshot of a customer database goes through as metadata only; raw image bytes are never sent, so image-only content is uninspected. That's not a bug in any vendor's integration. It's the shape of the primitive.
The hook gates every governed inference request, including tool results
The most interesting property of the hook is easy to miss in the DLP framing.
The prompt event fires once per governed inference request, not once per user message. In an agentic session, those are very different things. When Claude Code calls a tool, the tool result comes back and triggers a new inference request, and that request goes through the hook again, carrying the tool result in the transcript (steps 5 and 6 in Figure 1).
Think about what that means for indirect prompt injection. The classic worry with connected agents is that the user's prompt is clean but a tool result is poisoned: a web page, a Jira ticket, a document from a connector carrying instructions the model will obey. Network DLP that inspects only the user's outbound message never sees this. The inference hook does, because the poisoned tool result must pass through a verdict before the model consumes it on the next turn.
The hook is therefore more than DLP for prompts. It is a per-iteration gate on the agent's loop, positioned exactly at the trust boundary where external content enters the model's context. A security server that only scans the latest user message is using a fraction of what the hook offers. The transcript hands you every tool result at the moment of maximum leverage, before the model has acted on it.
That's the strongest version of this feature. Now the limits.
What the hook cannot do
None of what follows is hidden. It's all in Anthropic's documentation, stated plainly. It is also the material a one-line feature description drops, so it's worth spelling out.
The verdict is binary. Allow or deny. No redaction, no rewriting, no "strip the credit card number and pass the rest along." A network-inline DLP can transform payloads; the hook cannot. If one paragraph of a 40-page attachment trips your policy, your choices are to block the entire request or let it through. Expect this to shape user experience in ways your policy team should think about before turning enforcement on: coarse verdicts mean either permissive policies or frustrated users.
Prompts only, for now. The single event today fires before inference. There is no response-side event, so what the model says is not enforced, only what it is given. Anthropic says response-side enforcement is planned. Until it ships, claims about controlling "every prompt and response" describe a roadmap, not the beta. If a model produces something your policy would have blocked on the way in, the hook never sees it. (Audit-wise you can still reconstruct outputs after the fact, because each new request carries prior assistant turns in the transcript. But that is forensics, not prevention: by the time the next hook fires, the response has already been on the user's screen, and there is no next hook after the final turn.)
The failure mode is a policy decision, and the default is open. If your server is down, slow, or returns garbage, the request doesn't hang forever. Your org's failure handling decides: block the request, or let it proceed uninspected. The default on first save is "allow," and the latency economics push hard in that direction, because every millisecond of your verdict is added to every governed request in the org. Sustained failures trip the circuit breaker, at which point enforcement stops entirely until a human turns it back on. A control that degrades to "off" is materially different from one that degrades to "closed," and which one you have is a dropdown setting.
There is even a mundane trap hiding in there: transcripts arrive untruncated up to 10 MB, and a request your infrastructure rejects for being too large counts as a webhook failure. nginx defaults to a 1 MB body limit. Under fail-open, that configuration line means your longest conversations, the ones with the big attachments, are precisely the ones that sail through uninspected.
Coverage has a hard perimeter. The hook governs Claude Enterprise surfaces: claude.ai, Claude Code, Cowork. It does not cover the Claude Platform (API), Amazon Bedrock, Google Cloud, or voice mode. It obviously does not cover ChatGPT, Gemini, Copilot, a local Llama, or the personal account an employee uses when the corporate one blocks them. Inside a governed org, a rollout percentage below 100 leaves the remainder uninspected even in block mode, and excluded roles are never inspected at all. "Every prompt goes through the hook" is true only inside a carefully drawn boundary, and your actual AI estate is bigger than that boundary. Figure 2 maps the perimeter.
Figure 2 · The coverage perimeter: governed surfaces, surfaces outside the boundary, and gaps that remain inside governed traffic.
One field deserves special caution. The source.application value is an open string that the docs explicitly tell you not to treat as a trust boundary. A policy that says "be stricter with claude-code traffic" is routing logic, fine. A policy that says "this is safe because the source says claude-ai" rests a security decision on advisory metadata.
What the spec settles before a proof of concept
Security products will build on this hook, and the protocol itself answers several evaluation questions before any demo runs:
- Response-side inspection cannot be offered yet. The only event today fires on the prompt side; anything beyond that is roadmap.
- Redaction cannot happen at this layer. The verdict schema is allow or deny, so a product that modifies content is intercepting somewhere else (a client, a proxy) and should say where.
- "Complete coverage" can only mean governed Claude Enterprise requests. The Bedrock deployment your platform team runs and the ChatGPT tab in the next browser window are out of frame.
- Verdict latency is a hard budget, and worth asking about directly. At a 5-second ceiling with LLM-based policy evaluation in the loop, an integration is either very fast, very selective about what it deeply inspects, or leaning on fail-open. What is the p99 verdict time, and what happens to traffic when it is missed?
Standing inline at the model boundary is exactly where an enforcement product should want to be. An enterprise evaluating one should simply know which promises come from the primitive and which need separate proof.
If you're turning this on
For security teams adopting inference hooks, in rough order:
- Start in shadow mode and leave it there longer than feels necessary. You'll learn your real block rate, your verdict latency distribution, and your false-positive load on live traffic with zero user impact. The settings page shows failures per minute, and block rate while your rollout percentage is below 100; watch both before you enforce.
- Treat the failure-handling dropdown as the most important security decision in the feature. Fail-closed makes your security server a single point of failure for every Claude user in the company. Fail-open makes it a best-effort control. There is no third option, so pick one deliberately and write it down, including who gets paged when the circuit breaker trips.
- Set the timeout to what your server actually achieves, not the 5-second default. A slow verdict counts as a failure, and failures accumulate toward the breaker.
- Write deny_reason for the human being blocked. They get 500 characters. "Remove the customer account numbers and resend" changes behavior; "policy violation DLP-7734" generates a support ticket.
- Inspect the tool results, not just the newest user message. As above, that's where indirect injection lives, and the transcript is handing it to you.
- Join your reference_ids to the Activity Feed's denial records so every block is explainable end to end.
- Verify signatures properly. The docs call out the two mistakes that cause most verification failures: computing the HMAC over parsed-and-re-encoded JSON instead of the raw body bytes, and decoding the secret with a URL-safe base64 decoder instead of a standard one.
And whether you build or buy, keep an inventory of what the hook does not govern. The gap list is stable and knowable: image-only content, model responses (for now), non-Enterprise Claude, other vendors' models, excluded roles, uninspected rollout remainders, and every AI tool that isn't Claude. Those gaps don't disappear because one gate is well built. They're just somewhere else.
One checkpoint is not a perimeter
Inference hooks are a good primitive. The protocol is clean, the operational affordances (shadow mode, staged rollout, breaker) are what you'd want, and the position is unusual: no other frontier vendor currently lets a server you operate sit between the user and the model on the vendor's own infrastructure, seeing every governed tool result before the model does. If you run Claude Enterprise, you should probably be running something at this hook, even if it's just an always-allow archiver feeding your SIEM.
But one checkpoint is not a perimeter, and the checkpoint itself decides nothing. The hook is an enabler: it delivers a transcript and collects a verdict inside a five-second budget, and what that verdict is worth is determined entirely by the analysis behind it. Telling a legitimate bulk export from staged exfiltration, or a poisoned tool result from a merely malformed one, is a question about the agent's intent, and intent does not yield to keyword lists and regular expressions. It takes detection logic built for agent behavior, reasoning over the whole session rather than scanning the newest message.
The transcript alone is often not enough to reason with, either. The agent lives on the endpoint: the MCP servers and skills it loads, the folders and credentials within reach, the connections it holds, the other assistants installed beside it, the model responses that turn into actions. Whether a given tool call is routine or alarming depends on that context, and the hook does not carry it. Judging an agent's goal takes both views joined: the conversation as it crosses the model boundary, and what the agent can actually touch on the machine where it runs.
Enforcement at the model boundary is necessary, and the spec, to Anthropic's credit, never claims it is sufficient. The hook opens the door. What the verdict is worth depends on what stands behind it.
Sources: Anthropic's inference hooks overview, integration protocol, and configuration guide, plus the launch announcement.
