Claude Enterprise Inference Hooks Inspect Every Prompt. They Never Open Your Screenshots.

Anthropic shipped a way to put your own DLP server in front of every Claude request. The most useful paragraph in the docs is the one listing what it cannot see.

The most honest sentence in Anthropic's new enterprise security feature is buried under a heading called Current limitations: "Raw file and image bytes are never sent, so image-only content (for example, a screenshot of a document) is not inspected."

Read that next to the marketing line and you get the shape of the whole product. Inference hooks, launched in beta on August 5, routes every governed prompt in a Claude Enterprise organization through a security server the customer runs, and waits for an allow or deny verdict before the model generates anything. One toggle covers claude.ai, Claude Code, and Cowork. Nothing gets installed on user machines. That is a real control, and it closes a real gap.

And a user who screenshots the regulated spreadsheet instead of pasting it walks straight through.

Both of those things are true, which is why the interesting question is not whether inference hooks works. It is which of the settings you pick during rollout turn it into enforcement rather than a line item on a compliance questionnaire. There are three that matter, and Anthropic documents all of them.

What actually happens on the wire

The mechanism is simpler than the category name suggests, and worth understanding before you argue about it.

A user submits a prompt on a governed surface. Anthropic's servers send an HTTPS POST to the endpoint your organization configured, carrying the conversation transcript. The request is signed under the Standard Webhooks specification once your org generates a signing secret, so your server can prove Anthropic sent it. Your server evaluates the content and returns a small JSON object. {"action": "allow"} and inference proceeds. A deny carries a deny_reason string, and the user sees that reason followed by a standing message your admins wrote, usually naming who to email for an exception. Every denial lands in the organization's Activity Feed.

The default verdict timeout is five seconds.

Worth being precise about what your server sees, because this is where people guess wrong in both directions. It gets transcript text, tool calls and their results, and text extracted from attachments. It does not get raw file or image bytes, system prompts, or Anthropic-internal context. So your DLP scanner reads what the user reads, and nothing more.

Tool results get checked too, which is the part with real teeth for anyone running MCP connectors. Anthropic's flow diagram traces a Cowork request that calls an O365 tool and marks two hooked points: the arriving prompt, and the returning tool result. That second one matters because a tool result is where data from a connected system enters the conversation. If your Claude has read access to a SharePoint site through a connector, the hook is the layer that gets to look at what came back before the model does.

There is a wrinkle in the docs on this. The overview page says "Today the only hook event is prompt, which fires once per governed inference request," while the same page's diagram shows the tool-result exchange. Both can be right: a tool result kicks off a fresh inference request, so it arrives as another prompt event with a longer transcript. Response-side enforcement, meaning a check on what Claude wrote before the user sees it, is listed as a later event that does not exist yet.

One more discrepancy worth flagging. Anthropic's launch post describes the transport as "a signed WebSocket connection to a security server." The documentation describes signed HTTPS POSTs against a Standard Webhooks schema. Those are different protocols. If you are scoping the build, trust the docs page and the integration guide it links, not the blog.

The three settings that decide whether this is real

The failure-handling flag. If your security server is unreachable, errors, or blows the timeout, your organization's configured behavior decides what happens: block the request, or let it through uninspected. That is the entire security posture compressed into one dropdown. Fail-open means an attacker who can degrade your DLP endpoint has turned inspection off for everyone, and a bad deploy on your side does the same thing by accident. Fail-closed means your DLP server is now a hard dependency of every Claude session in the company, and its uptime is your engineering team's uptime.

Most orgs will pick fail-open and never revisit it. Pick deliberately, then write down which one you chose and why.

The five-second timeout. You are adding a synchronous network round trip in front of every inference request. Not the average request. Every one. A DLP scanner that answers in 80 milliseconds at p50 and 4 seconds at p99 will feel fine in testing and awful in an agentic Claude Code session that fires dozens of tool calls in sequence, because each one pays the tail again. Measure the p99, not the median, and measure it against your own traffic shape.

Rollout scope. Shadow mode observes verdicts on live traffic without blocking anything. Rollout percentage inspects a fraction of requests. Role exclusions exempt whole groups. Each of these is genuinely useful for getting to production without an incident, and each is also a way to ship something that looks deployed and inspects almost nothing. If your rollout has been at 10 percent with the security team excluded for two months, you do not have a control. You have a pilot.

Putting this into practice

The lowest-friction version of this is smaller than it sounds, and you can get a real answer in an afternoon.

Start by standing up an endpoint that always returns {"action": "allow"} and logs the transcript. That is a legitimate deployment on its own. Anthropic lists real-time transcript archival as a supported use case, and it is a push-based replacement for polling the Compliance API. You get complete visibility with zero risk of blocking anyone, and you learn your actual traffic volume before you tune anything.

Turn on shadow mode and leave it there for at least two weeks. Log what your DLP rules would have denied. Almost everybody discovers their existing rules are tuned for email and fire constantly on code, because a source file full of API-key-shaped test fixtures looks exactly like a leak.

Now measure. Chart your endpoint's latency against Claude Code sessions specifically, since those generate the longest chains of hooked requests. If your p99 sits anywhere near five seconds, fix that before you enforce anything.

Then enforce narrowly. One rule, one high-confidence pattern, one team. Watch the Activity Feed and see what the denial message actually reads like to a user who did nothing wrong, because your deny_reason string is now product copy and most first drafts are unhelpful.

The whole sequence is testable without committing to a vendor. If you already run Netskope, Palo Alto Networks, Proofpoint, or Zscaler, the schema is published and point-at-your-existing-server is the intended path.

What this does not cover

The screenshot gap is the headline, and it is not a bug so much as a consequence of the design. Since raw image bytes never leave Anthropic's side, a user who wants to move a regulated document past the check has an obvious route, and it takes four seconds. Any threat model where the insider is deliberate rather than careless should treat inference hooks as covering accidents only.

Verdicts are binary. Your server can allow or deny, and it cannot redact. That kills the most humane version of DLP, where the system strips the customer record and lets the rest of the question through. Instead the user gets blocked and has to figure out which part of their prompt was the problem.

The coverage boundaries are worth memorizing because they are all places a governed employee still reaches a model. Platform organizations, meaning API access through the Claude Platform, are out of scope. Bedrock and Google Cloud deployments are not covered. Voice mode is not covered. Ancillary requests such as conversation title generation never reach your endpoint, which is fine for policy and mildly interesting for archival, since your transcript record will not be a complete record.

The structural limit is the one that bothers me most. Inference hooks inspects prompts and tool results. That is the model's input channel. The past two weeks of agent security news have been about attacks that never touch that channel: forged tool calls that skip the model turn entirely, and worms that write themselves into an agent's config file and wait for the next session to start. A poisoned .claude/settings.json is neither a prompt nor a tool result. It will never generate a hook event. Deploying this and calling the coding agent covered would be a mistake.

Configuring it requires the organization:manage permission, which Admin, Owner, and Primary owner roles hold. Beta, so expect the schema to move.

What to do with this

If you run security for an organization on Claude Enterprise, the honest read is that this is the first native control that sees every surface at once, and it is worth deploying in log-only mode this month purely for the visibility. That part has no downside and answers questions you probably cannot answer today, starting with how much of your Claude traffic is Claude Code and what is in it.

Enforcement is a bigger decision, and it hinges on whether your risk is careless people or motivated ones. For careless, this is a strong control. For motivated, it is a speed bump next to a screenshot key.

The document to read is the limitations section, not the launch post. Anthropic wrote an unusually direct one. Take it at face value, map each line to something in your own threat model, and you will know within an hour whether this closes your gap or just changes its shape.

Sources: Anthropic, "Inference hooks: inline data loss prevention for Claude Enterprise" (August 5, 2026); Claude Platform Docs, "Inference hooks"; Standard Webhooks specification.