Claude Inference Hooks: The 2026 DLP Gate and Its Gaps

Claude inference hooks let a Claude Enterprise organization send every governed prompt to its own AI security server for an allow or deny verdict before inference runs. Anthropic launched the feature in beta on August 5, 2026. It inspects prompts and tool results — not model responses.

TL;DR

Anthropic shipped inference hooks in beta for Claude Enterprise on August 5, 2026.¹ When an organization turns them on, Anthropic holds each governed inference request while it asks a server the customer runs — Anthropic calls it an AI security server — whether the request may proceed. The server answers allow or deny, and a denied request never reaches the model.²

The interesting part is not the announcement. It is the documentation, which is unusually candid about what the feature does not do. Only one hook event exists today, prompt; response-side enforcement is "planned as a later event."² Verdicts cannot redact, only block. Raw image bytes are never sent, so a screenshot of a confidential document is not inspected. It does not run on Amazon Bedrock or Google Cloud, and voice mode is not covered.²

Read alongside Anthropic's own finding that Claude Code users approve 97% of permission prompts,³ the direction is hard to miss: the decision about whether an agent's next step is acceptable is being moved off the human at the keyboard and into code — some of it Anthropic's classifiers, some of it the customer's server.

What you'll learn

• What Claude inference hooks are, in Anthropic's own terms
• How the verdict round trip works, including the timeout and retry rules
• What your AI security server actually receives, and what it never sees
• Why the tool-result hook point matters specifically for agents and MCP
• What inference hooks do not cover, straight from Anthropic's own documentation
• How the fail-open and fail-closed setting decides what a DLP outage costs you
• The operational gotchas most likely to break a first deployment
• A transport discrepancy between the announcement and the developer docs
• How this compares with Microsoft Purview's DLP for Microsoft 365 Copilot
• Which security vendors have published integrations
• Why the approval decision is moving off the human, with Anthropic's own numbers

What are Claude inference hooks?

Inference hooks are a Claude Enterprise feature that routes every governed prompt through an HTTPS service the organization or its security vendor operates, before inference runs. Anthropic sends the conversation transcript to that service and waits for an allow or deny verdict; a denied request never reaches the model.²

The architectural detail that matters is where the check executes. Per the documentation, "the hook runs on Anthropic's servers, after the request leaves the client and before the model runs," so it "applies to every governed request uniformly, with nothing to install or deploy on user devices."² The announcement post is explicit about the prior state: "Until today, native inline enforcement was limited to Claude Code's client-side hooks."¹ Those hooks — PreToolUse and friends — run on the developer's machine and are configured per user.⁴ An inference hook is one organization-level configuration that a user cannot opt out of by editing a local settings file.

Configuring it requires the organization:manage permission, which the built-in Admin, Owner and Primary owner roles hold. Anthropic lists four use cases: data loss prevention, which it calls "the most common deployment"; real-time transcript archival via an always-allow server; prompt telemetry; and policy engines enforcing model allowlists, project-scoped restrictions or working-hours controls.²

How the verdict round trip works

A user submits a prompt on a governed surface. Anthropic sends an HTTPS POST to the URL the administrator configured, carrying the conversation transcript. The server evaluates it and responds within the configured verdict timeout. On allow, inference proceeds. On deny, the request is rejected and the user sees a blocked-by-policy message assembled from the deny_reason the server supplied plus a standing message the administrators configure. Every denial is recorded in the organization's Activity Feed.²

The verdict itself is a small JSON object. To allow:

{
  "action": "allow"
}

To deny, with the reason the end user will read:

{
  "action": "deny",
  "deny_reason": "This prompt appears to contain customer payment card data, which your organization's policy does not allow.",
  "reference_id": "scan_01HXPT4R9V"
}

deny_reason is capped at 500 characters and longer values are truncated. reference_id is capped at 50 characters, is recorded on the inference_hooks_request_denied compliance activity, and is never shown to the user — which makes it the join key between your scanner's records and Anthropic's audit trail.⁵

Three operational rules matter:

The timeout is short and configurable. An administrator sets the verdict timeout between 1 and 10,000 ms, with a default of 5,000 ms. That budget covers the whole exchange — connection, TLS handshake, request and response.⁵

The retry rule is narrower than most webhook systems. Anthropic "retries exactly once, after a 100ms delay, and only when the connection attempt fails."⁵ A slow server that eventually answers gets no second chance; once your server has responded, the exchange is never retried.

A non-200 is not a deny. The docs are blunt: "Don't signal a deny with an error status. A non-200 response is a failure, not a deny."⁵ Any action value other than allow or deny is likewise treated as a webhook failure, which hands the outcome to your failure-handling setting instead.

Requests are signed per the Standard Webhooks specification using webhook-id, webhook-timestamp and webhook-signature headers.⁵⁶ Anthropic's own documentation flags the bug most implementations hit: the signing secret is base64 with the standard alphabet, so "a URL-safe decoder derives the wrong key bytes whenever the secret contains + or /, which is most of the time."⁵

What your AI security server actually sees

The transcript is the conversation as the end user sees it, up to the point of inference: text, tool calls and their results, extracted attachment text, and prior turns. Anthropic states it "never includes system prompts, tool definitions, Anthropic-internal context, Claude's hidden reasoning, or raw file bytes."⁵

Here is the shape of a prompt frame, trimmed to the fields that matter:

{
  "type": "prompt",
  "request_id": "req_abc123",
  "tenant_id": "11111111-1111-1111-1111-111111111111",
  "actor": {
    "type": "user",
    "id": "user_01AbCdEfGhIjKlMnOpQrStUv",
    "email_address": "alice@example.com"
  },
  "source": { "application": "claude-ai" },
  "session_id": "22222222-2222-2222-2222-222222222222",
  "model": "claude-sonnet-4-5",
  "messages": [
    {
      "role": "user",
      "content": [
        { "type": "text", "text": "Summarize the attached report." },
        {
          "type": "attachment",
          "file_name": "q2-report.pdf",
          "media_type": "application/pdf",
          "size_bytes": 48213,
          "text": "Q2 revenue grew 14% quarter over quarter..."
        }
      ]
    }
  ],
  "metadata": {}
}

Two fields deserve a policy author's attention. source.application is an open string, not a closed enum — known values today are claude-ai and claude-code, with config-test used for connection tests — and Anthropic warns: "Treat source.application as advisory routing metadata, not a trust boundary."⁵ And actor is a union discriminated on type, where "user" is the only value sent today, so a server that assumes a human principal will need revisiting the moment a non-user actor type appears.

The exclusion of Claude's hidden reasoning is a quiet but consequential design choice. Your scanner sees what the agent did — the tool calls and their arguments — but not the chain of thought that led there. Anthropic made the same exclusion in its Claude Code transcript classifier, which is "reasoning-blind by design" so the agent cannot argue its way past the check.⁷ The motive is not stated here, but the consequence is the same: an inference hook cannot be a chain-of-thought monitor.

Why the tool-result hook matters for agents and MCP

For a chat product, inspecting prompts is a data-loss story. For an agent, the second hook point is the more interesting one.

The announcement states that when Claude calls a tool — "including tools connected through MCP, skills, and plugins — the tool's response is checked before it's sent back to the model."¹ The documentation's flow diagram makes the same point structurally: the hooked points are where the prompt arrives and where the tool result returns.² Mechanically, a returning tool result triggers a further governed inference request, so it arrives at your server as another prompt frame — this time with tool_use and tool_result blocks in the transcript.

tool_result blocks carry content (the output as text, with binary parts replaced by placeholder markers), is_error, tool_use_id, and — usefully — tool_name, "so a policy can condition on tool identity without cross-referencing an earlier block."⁵

That is a policy hook sitting exactly on the boundary where untrusted content enters an agent's context. It is worth being precise about what that does and does not buy you. It does not make Claude injection-proof; it gives your code a look at the text an MCP server returned before the model acts on it, and whether anything is caught depends entirely on the policy you write. What it does change is who can write that policy: previously, tool-result screening on this product was Anthropic's to implement; now a customer can put their own detection logic on the same wire. If you have been treating MCP connectors as an unmonitored ingress path — and Anthropic's own agent-safety work treats tool outputs as "where hostile content enters the context"⁷ — this is a place to instrument it that does not depend on every developer configuring their own machine.

What inference hooks do not cover

This is where the documentation earns its keep. Every row below is Anthropic's own statement, drawn from the overview page's limitations and availability sections, not an inference drawn from silence.

The response-side gap is the one to plan around. A DLP program that only inspects ingress stops an employee pasting a customer list into a prompt; it does nothing about a model response that surfaces regulated data the agent legitimately retrieved. Anthropic points at the Compliance API for the after-the-fact half of that problem: inference hooks act inline before inference, the Compliance API retrieves activity, chats, files and projects for audit and export afterwards.² Inline prevention on egress is, for now, a roadmap item.

The image gap deserves a sentence of its own: it is the workaround a determined user finds first. If the policy blocks pasted text containing account numbers, a screenshot of the same spreadsheet is extracted only insofar as text extraction happens upstream; the raw bytes never reach your scanner.

Fail open or fail closed: the setting that decides what an outage costs

Every synchronous inspection point adds a dependency, and the docs say so plainly: "Enforcement adds your AI security server's round trip to the latency of every governed request in your organization."⁵

If your server is unreachable, errors, or misses the timeout, an organization-level failure-handling setting decides what happens: block the request, or allow it through without inspection.² That is the classic fail-closed versus fail-open trade-off in a new place. Fail closed and your DLP server's bad deploy becomes a company-wide Claude outage. Fail open and the same deploy silently turns your enforcement gate into a pass-through, with no user-visible signal that policy stopped applying.

There is a second-order effect worth knowing before you choose. Sustained webhook failures attributable to your server trip a circuit breaker: Anthropic stops contacting the server entirely and failure handling applies to every request. Recovery is manual — an administrator has to fix the server and turn "Enforce verdicts" back on.⁵ Combine a fail-open setting with a tripped circuit breaker and you have an organization that believes it is enforcing policy and is not, until somebody checks the console.

The rollout controls are the right answer, and they are generous: shadow mode observes verdicts on live traffic without blocking anything, a rollout percentage inspects a chosen fraction of requests, and exclusions exempt chosen roles entirely.² Shadow mode is also the only honest way to size the latency cost before it lands on every employee.

The gotchas that will bite a first deployment

Four details in the integration documentation are easy to miss and expensive to discover in production.

Your body limit is probably too small. Transcripts are sent untruncated, up to a 10 MB ceiling. Anthropic spells out the failure mode: "Several common defaults are much smaller, including nginx client_max_body_size at 1 MB and Express express.json() at 100 kB, and a rejected body counts as a webhook failure, so under Allow the request failure handling an oversized prompt would reach the model uninspected."⁵ The longest, most attachment-heavy conversations — the ones most likely to carry regulated data — are precisely the ones a default nginx config waves through.

Unknown event types must be allowed, by spec. The forward-compatibility rule instructs servers that when the top-level type is unrecognised, "return an allow verdict rather than an error status," because an error is a webhook failure and sustained failures trip the circuit breaker.⁵ That is a sensible protocol design, and it has a consequence worth naming: when response-side enforcement arrives as a new event type, a server written to today's spec will allow those events by default until somebody updates it. The upgrade is not automatic, and the failure is silent.

The endpoint must be publicly reachable and redirect-free. An https:// URL on port 443, a publicly routable host — private, loopback and carrier-grade NAT ranges are refused at connect time — a publicly trusted certificate, and no redirects. Requests arrive from 160.79.106.0/24, which you can allowlist, though Anthropic notes that allowlisting "is not a substitute for signature verification" since that block carries other Anthropic egress traffic.⁵

The beta contract is explicitly unstable. The integration page carries its own warning: "Field names, request shapes, and headers may change before general availability."⁵ Write the server to ignore unknown fields, unknown metadata keys, new source.application values, new actor.type values and unrecognised content-block types — all of which the documentation asks for by name.

One discrepancy worth knowing about the transport

The announcement post and the developer documentation describe the transport differently, and the announcement post disagrees with itself.

The blog says "every inference request routes through a signed WebSocket connection to a security server" — then, two sections later, describes "an open, webhook-based protocol with a published schema."¹ The developer documentation only describes the second: an HTTPS POST per governed request, signed according to the Standard Webhooks specification, with fixed headers including User-Agent: anthropic-dlp/1, and a sample server that keeps the connection open between verdicts via HTTP/1.1 keep-alive.⁵⁶

Build against the documentation. It is the page that specifies the schema you have to implement, and a marketing-page description of a transport is not an interface contract — the security vendors who shipped integrations describe a POST, not a socket.⁸ If a datasheet you are evaluating leads with "WebSocket," it is a small tell about which page the vendor read.

How this compares with Microsoft Purview DLP for Copilot

It would be easy to write that a frontier lab has, for the first time, let customers put their own code inside its inference path. Anthropic does not make that claim, and the comparison that actually helps a buyer is mechanism, not chronology.

Microsoft Purview has had a Microsoft 365 Copilot and Copilot Chat policy location for DLP for some time. Administrators can write policies that keep Copilot from grounding responses in sensitivity-labelled items, and can restrict Copilot from processing prompts that contain sensitive information, matched against Microsoft-provided or custom sensitive information types.⁹ That is first-party, inline, and it predates inference hooks — so anyone selling you novelty here should be asked what they mean by it.

The difference is not detection sophistication. Purview's condition language is mature, and Palo Alto Networks describes its inference-hooks integration reusing the same primitives you would expect of any mature DLP product: exact data matching, pattern detection, trainable classifiers.⁸ The difference is who authors and runs the evaluator. Purview's enforcement logic lives with Microsoft, speaks Microsoft's policy language, and covers Microsoft's products. An inference hook hands the raw transcript to an HTTPS service the customer chose — a commercial DLP engine, an internal classifier, or a hundred lines of Python nobody outside your security team has heard of. One model asks you to express your policy in a vendor's taxonomy; the other asks you to operate a production service in the critical path of every prompt.

Who has published integrations

The announcement names Netskope, Palo Alto Networks, Proofpoint and Zscaler — but read the sentence carefully. It suggests pointing inference hooks "at the same server your other tools already report to including" those vendors.¹ That is a statement about where your DLP infrastructure already lives, not a claim that all four shipped integrations on day one.

Three of the four did. Palo Alto Networks published both a blog post and product documentation for a Prisma AIRS integration that receives the hook and returns the verdict.⁸ Proofpoint published a write-up describing its integration applying existing DLP policies to Claude prompts.¹⁰ Zscaler published one too.¹¹ Beyond the named four, Check Point documents an integration in its Workforce AI Security admin guide,¹² and Akto published one.¹³

Netskope is the interesting omission. It announced a Claude integration on May 21, 2026, but on the Compliance API — the after-the-fact path — rather than inference hooks.¹⁴ Treat this list as a floor rather than a census. It is what surfaced on August 11, 2026, and a vendor that shipped quietly would not appear on it.

Why the approval decision is moving off the human

Inference hooks are one half of a pattern. The other half is what Anthropic has published about the control they sit alongside.

In March 2026, Anthropic's engineering team reported that Claude Code users approve 93% of permission prompts, and built auto mode — a classifier that adjudicates tool calls instead of the user — explicitly to address approval fatigue.⁷ By the August 7 announcement that auto mode would become the default, the figure had moved to 97%, alongside a sharper contrast: users reject 39% of plans Claude presents for approval, but only 3% of individual permission requests.³ People scrutinise the thing that looks like a decision and wave through the thing that looks like a dialog box.

The supporting study is the part worth quoting. In a controlled experiment with 1,053 paid professional testers, a single permission prompt was swapped mid-session for a clearly dangerous command. Human review caught it 13.6% of the time — 143 of 1,053 — while auto mode caught 89%. Head to head, auto mode blocked 800 commands a human approved, and humans blocked 6 that auto mode allowed. Human performance decayed with session length, from roughly 17% early on to about 5% after fifty prior prompts; the classifier's block rate stayed flat.³

Anthropic is not claiming the classifier is excellent. Its March write-up puts the false-negative rate on 52 curated real overeager actions at 17%, calls it "the honest number," and says auto mode "is not a drop-in replacement for careful human review on high-stakes infrastructure."⁷ The August post repeats the caveat.³ The argument is comparative, not absolute.

Note where the default is not changing. Auto mode becomes the default on August 14 for new sessions on Pro, Max and Team plans; it "remains opt-in for now on Claude Enterprise," the Claude API, Bedrock, Google Cloud's Agent Platform and Microsoft Foundry.³ That is the same surface inference hooks govern. On the consumer and team tiers, Anthropic changed the default and supplied the judgment itself. On the enterprise tier, it supplied a hook and let the customer bring their own.

That difference matters for anyone building approval gates into their own agents. Anthropic's classifier decides what an agent may do; your AI security server decides what may reach the model at all, using rules you can point at your own auditor. It is also the honest limit of the feature: moving the checkpoint off the human does not make the check good. It relocates the question from "will the user read this prompt?" to "did anyone tune this policy, and does anyone notice when it stops running?" — the same question every agent containment control eventually poses.

What to check before you turn it on

• Run shadow mode long enough to see your traffic's real latency distribution, not the median. The verdict timeout is 5,000 ms by default and every governed request pays your round trip.⁵
• Decide fail-open versus fail-closed deliberately, write it down, and alert on the circuit breaker. A tripped breaker plus fail-open is silent non-enforcement.⁵
• Raise your server's request body limit toward the 10 MB ceiling before enforcing, or your largest conversations become your least inspected ones.⁵
• Verify signatures over raw bytes with a standard base64 decoder, and keep accepting the previous secret for a minute after rotation.⁵
• Plan the response-side gap now: pair inference hooks with the Compliance API for after-the-fact review, and expect to update your server when a second event type ships.²
• Confirm the surfaces you care about are actually in scope. If your exposure is on Bedrock, Google Cloud, the API, or voice, this feature does not reach it.²

Bottom line

Inference hooks are a well-documented beta that does one thing precisely: it lets a Claude Enterprise organization put its own code in the path of every governed prompt and tool result, and get a binary answer back before the model runs. The documentation is unusually forthcoming about the edges — no response-side enforcement, no redaction, no image bytes, no Bedrock, no Google Cloud, no voice — which is worth more to an evaluator than the announcement is.

The thing to argue about is not whether the gate works. It is what happens on the days it does not: whether your organization chose fail-open or fail-closed on purpose, whether anyone is alerting on the circuit breaker, and whether the policy behind the verdict has an owner. A checkpoint nobody tunes is a slower version of no checkpoint at all — and unlike a tired reviewer, a stale policy leaves no trace of having stopped paying attention.