Anthropic will hold every Enterprise prompt for your server's verdict

Anthropic's platform release notes for 5 August 2026 carry one line that changes where an enterprise security team can stand:

"Inference hooks are now in beta for Claude Enterprise organizations. Point Claude at your organization's AI security server, and each governed prompt across claude.ai, Cowork, and Claude Code is held for the server's allow or deny verdict before inference proceeds."

The documented protocol behind that sentence is unusually complete for a beta, and it repays a careful read — mostly because of where it chooses to fail.

What is actually being hooked

An inference hook is a synchronous webhook. A Claude Enterprise organization configures an HTTPS endpoint it runs; when a user submits a prompt on a governed surface, Anthropic POSTs the conversation transcript there and waits. The docs are explicit about the placement: "Because the hook runs on Anthropic's servers, after the request leaves the client and before the model runs, it applies to every governed request uniformly, with nothing to install or deploy on user devices."

That is the interesting part. Endpoint DLP agents can be uninstalled, bypassed by the browser, or simply not present on a contractor's laptop. A gate on the server side of the API boundary covers claude.ai, Cowork and Claude Code sessions "whether they run on the web, in the desktop app, or in the CLI".

There is exactly one hook event today, prompt, fired once per governed inference request. "Response-side enforcement is planned as a later event" — so today the control inspects what goes in, not what comes back.

The wire protocol

Requests arrive with Content-Type: application/json, User-Agent: anthropic-dlp/1 and Accept-Encoding: identity, signed per the Standard Webhooks specification using webhook-id, webhook-timestamp and webhook-signature headers. The signature is an HMAC-SHA256 over {webhook-id}.{webhook-timestamp}.{raw body bytes}, verified with a constant-time comparison, rejecting any timestamp more than five minutes from your clock.

The verdict is a small JSON object. Allow:

{"action": "allow"}

Deny:

{
  "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 is shown to the end user, prepended to a standing message administrators configure. reference_id is at most 50 characters from [A-Za-z0-9._:/-], never shown to the user, and lands on the inference_hooks_request_denied compliance activity so denials can be joined back to your own records.

The verdict timeout is administrator-set between 1 and 10,000 ms, defaulting to 5,000 ms, and the budget covers "connection, TLS handshake, request, and response". Anthropic "retries exactly once, after a 100ms delay, and only when the connection attempt fails", reusing the same webhook-id and signature — so webhook-id doubles as an idempotency key. At most 64 KiB of the response body is read, uncompressed, with redirects not followed. Traffic originates from 160.79.106.0/24, and the docs warn that this is the outbound range, not the inbound ranges published on the same page.

One implementation note deserves wider circulation, because it is a bug class rather than a Claude quirk: the signing secret after the whsec_ prefix uses the standard base64 alphabet, and "A URL-safe decoder derives the wrong key bytes whenever the secret contains + or /, which is most of the time." Reference verifiers are provided in Python, TypeScript, C#, Go, Java, PHP and Ruby, standard library only.

Every ambiguity resolves toward allow

Read the failure semantics as a set and a posture emerges. "A webhook failure never becomes a deny." A non-200 status is a failure, not a deny — "Don't signal a deny with an error status." Any action value other than allow or deny is a failure. An unparseable or oversized response body is a failure. And when a future hook event type arrives that your server does not recognize, the guidance is to "return an allow verdict rather than an error status", because sustained errors trip a circuit breaker that stops enforcement altogether until an administrator turns Enforce verdicts back on.

What a failure means is a single organization-wide toggle: block the request, or allow it to proceed without inspection.

This is defensible. A security control that takes claude.ai offline for an entire organization because a scanner ran out of memory is its own incident. But the choice should be made deliberately, not inherited. If you pick allow-on-failure, your DLP policy has an availability-shaped hole in it, and the circuit breaker means a bad afternoon on your side silently widens that hole to 100% of traffic.

The 10 MB trap

Transcripts are sent untruncated, up to a 10 MB ceiling. The documentation then says the quiet part out loud:

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.

Anthropic, "Develop an Inference hooks integration"

The incentive is inverted in the worst possible way. The prompts most likely to carry regulated material are the long ones with attachments — and those are exactly the ones a stock reverse proxy rejects before your policy engine ever sees them. Raise the limit at the proxy, not only in the application, and alert on the rejection rate.

What the gate cannot see

The blind spots are documented plainly, which is more than most vendors manage:

• Raw file and image bytes are never sent, so "image-only content (for example, a screenshot of a document) is not inspected". Attachments arrive as metadata plus extracted text.
• "Verdicts are allow or deny. Rewriting or redacting a prompt is not supported." There is no middle setting between blocking a user and letting the data through.
• System prompts, tool definitions, Anthropic-internal context and "Claude's hidden reasoning" are never included.
• Voice mode is not covered. Ancillary requests such as conversation title generation are not sent.
• Inference hooks "are not available on Amazon Bedrock or Google Cloud", and "Platform organizations (API access through the Claude Platform) are out of scope" — so this governs the seat-based products, not your API keys.
• source.application is an open string, and the docs are blunt: "Treat source.application as advisory routing metadata, not a trust boundary."

The cost of looking

Two trade-offs are worth naming before anyone signs off on a rollout.

The first is latency: "Enforcement adds your AI security server's round trip to the latency of every governed request in your organization." A five-second default timeout is a five-second worst case in front of every prompt, every user, all day.

The second is the inversion at the center of the design. To stop sensitive material from reaching Anthropic's model, you now stream every transcript — user text, tool calls, tool results, extracted attachment text — to a second HTTPS service, quite possibly one a security vendor operates. That may still be the right trade, because the scanner can be inside your own perimeter while the model is not. But it is a new copy of the data, in a new place, and it should be threat-modeled as one rather than filed under "DLP" and forgotten.

Anthropic at least makes the ramp gentle: shadow mode observes verdicts on live traffic without blocking, a rollout percentage inspects a chosen fraction of requests, and role exclusions exempt chosen groups. Start there, watch the failure rate, and only then decide what a timeout should mean.

Primary sources: Claude Platform release notes, Inference hooks, Develop an Inference hooks integration, read 2026-08-11.