I have Owner on a Claude Enterprise tenant at the moment, which is the only reason I can tell you what this looks like rather than what the changelog says it does. Under Data and privacy there is a section that was not there in the spring, carrying a Beta badge and a single toggle.

Send prompts to your endpoint for inspection before Claude processes them. Eleven words, off by default, and the most interesting control Anthropic has shipped for enterprises this year.

Here is why it matters. Every AI data-loss control I have been asked to review over the last two years has lived on the wrong side of the problem. Browser extensions that watch a text box. Proxies that inspect traffic and cannot read the app. Policies in a wiki. All of them sit outside the thing they are trying to govern, and all of them are defeated by a user who opens the desktop app instead. An inference hook runs on Anthropic’s servers, after the request leaves the client and before the model sees it, which means there is nothing on the laptop to bypass. That is a real architectural change and it deserves the attention it is getting.

It also has a hole in it that nobody selling you an integration is going to lead with.

What the hook actually sees

The mechanics are published, which is a good sign in itself. Anthropic sends an HTTPS POST to an endpoint you run, carrying the conversation transcript, signed per the Standard Webhooks specification so you can prove it came from them. Your server reads it and answers with a small JSON verdict. Allow, and inference proceeds. Deny, and the request never reaches the model, the user gets a blocked-by-policy message assembled from your reason plus a standing note your admins write, and the denial lands in the organisation’s activity feed. You get five seconds by default to decide, configurable.

Read the boundary of what arrives, because this is the whole post. Per Anthropic’s documentation, your 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.

That is a sensible privacy boundary and I would draw it the same way. It is also the shape of the gap.

Why does image-only content walk straight through?

Because extraction is the only path in, and a picture has nothing to extract. Anthropic states the consequence plainly under Current limitations: raw file and image bytes are never sent, so image-only content, and their own example is a screenshot of a document, is not inspected.

Sit with what that means operationally. The archetypal exfiltration a DLP programme is built to catch is somebody putting regulated material into a tool that should not have it. The move is almost never a careful paste of structured text. It is a screenshot. Somebody grabs a region of a spreadsheet, drops the PNG into the chat, and asks what it means. That is faster than copying, it survives formatting, and it is what people already do a hundred times a day for perfectly innocent reasons.

Your inference hook will not see a single pixel of it.

Mind you, this is not Anthropic being careless. Shipping raw bytes to a customer-run endpoint would be a worse privacy posture, and they were straightforward about the limit in the docs rather than leaving it to be discovered. But a control whose gap is documented is still a gap, and the specific gap here is aligned exactly with the highest-frequency behaviour it is meant to govern. If you buy an inference-hook integration and tell your risk committee that prompts are now inspected, that sentence is true and the impression it leaves is wrong.

The mitigation is not clever, it is just work. Either you deny attachments of image type outright at the hook, which is blunt and will make you unpopular, or you accept that images are covered by something else, or you turn off image uploads at the org level and take the complaints. Whichever you choose, choose it on purpose and write down which one you picked.

Set the failure mode before you set anything else

The second thing to settle is what happens when your own server has a bad afternoon. From the docs: if your AI security server is unreachable, returns an error, or does not respond within the timeout, your organisation’s failure-handling setting decides the outcome, block the request or allow it to proceed without inspection.

Both options are defensible, which is what makes this dangerous. Block, and a deploy that breaks your endpoint takes Claude away from the whole company until somebody notices. Allow, and every outage is a window where nothing is inspected and nobody gets paged, because from a user’s seat an uninspected prompt looks exactly like an inspected one.

I have written before about the Claude Code controls that fail open, and the pattern repeats here with one improvement worth crediting. This time the direction is yours to choose rather than a default you discover later. Take that seriously. The convenient answer under rollout pressure is allow, because it cannot break anybody, and a control set to allow-on-failure is a control that stops working precisely when your infrastructure is having the sort of day that also produces careless behaviour.

If you pick allow, at minimum alert on the rate. A hook that has silently returned nothing for six hours should page somebody, the same way a firewall that stopped logging would.

Shadow mode is the part worth copying

The rollout design is the bit I would steal for other projects. You get shadow mode, which observes verdicts on live traffic and blocks nothing, a rollout percentage so you can inspect a fraction of requests, and exclusions that exempt chosen roles.

That combination lets you answer the question everybody asks and nobody can usually answer: how many of our prompts would this rule have refused? Run it in shadow for a fortnight, count the denies, and read the list before a single user is blocked. Any policy engine that goes live without that step generates a week of angry tickets and a rollback, and I have watched it happen with three different classes of tool.

There are two more limits worth knowing straightaway, both from the same page. Verdicts are allow or deny, with no support for rewriting or redacting a prompt, so a request that is mostly fine and slightly regulated is refused whole rather than cleaned. And the only hook event today is prompt, which fires before inference; response-side enforcement is on the roadmap rather than in your hands. Whatever the model says back is not passing through your server yet.

Where this leaves a DLP programme

Turn it on, and be precise about what you have bought.

You have bought inline enforcement on text, across claude.ai, Cowork and Claude Code, on the web, desktop and CLI, from one setting, with nothing to install on anybody’s machine. That is a lot, and it is more than any bolt-on was ever going to give you. It sits in front of the model rather than beside it, and the Compliance API remains the after-the-fact half of the same job.

You have not bought coverage of images, of voice mode, of Bedrock or Vertex, or of anything the model says on the way back. Those are four separate gaps and only one of them is on a roadmap.

The reason I am labouring this is that the failure I keep meeting in companies is never the missing control. It is the control that exists, works as documented, and is described upward in words slightly larger than the truth. Somebody says prompts are inspected. A committee hears everything is inspected. Nine months later a screenshot of a patient list is sitting in a chat transcript and the control was working perfectly the whole time.

Write the gap down next to the control, in the same document, in the same font. That is the entire discipline, and almost nobody does it.