Anthropic has shipped a feature where the roles are reversed. Normally you call Anthropic's API. Here, Anthropic calls you.
The feature is called inference hooks. It sends the conversation to a server you operate and waits for your answer before the model sees anything at all. If your server says no, the prompt never arrives.
It is in beta and runs on Claude Enterprise only. Read on anyway, even if you don't have Enterprise. The setting this article ends on also sits in the scanner you already run.
Anthropic calls you, not the other way round
The flow works like this, as Anthropic describes it in the documentation.
Someone submits a prompt on a governed surface. Anthropic sends an HTTPS request to the endpoint your organisation configured. The request carries the conversation transcript, and it is signed per the Standard Webhooks specification once you have generated your signing secret. Your server evaluates the content and answers allow or deny. On allow, the model runs. On deny, the request is rejected, and the denial is recorded in your organisation's Activity Feed.
Tool results are checked the same way. Anthropic's own example is a Cowork request where Claude calls an O365 tool along the way. Both the prompt and the tool's result trigger their own round with your server. The feature reaches wider than a filter on the prompt box.
Your server sees the transcript text, tool calls and their results, and text extracted from attachments. It never receives raw file or image bytes, system prompts, or Anthropic's internal context. Anthropic writes that it does not store prompt or response content as part of the feature, only metadata about hook activity: verdicts, timestamps and request identifiers.
A single hook governs claude.ai, Cowork and Claude Code across the organisation, on web, desktop, mobile and the command line. Amazon Bedrock and Google Cloud are not covered. Neither is voice mode.
The direction of the call is the whole point. In the Compliance API piece I wrote about the opposite movement, where you call Anthropic and pull transcripts afterwards. Anthropic sets the two side by side in its own documentation. The Compliance API acts after the fact. Claude inference hooks acts inline, before the fact, and of the Claude controls I have written about here, it is the one that can refuse inline, before the request reaches the model.
What happens in the sixth second
Your server is on a clock. Anthropic's default is five seconds, and the timeout is configurable by the organisation.
Five seconds is generous for a lookup against a blocklist. It is tight for a scanner that has to classify a long conversation. And it feels long to somebody sitting there waiting for an answer.
Then comes the question the rest of this article rests on. What happens when your server does not answer in time?
Anthropic lets you choose between two outcomes. Either the request is blocked, or it proceeds without inspection. There is no third option, and the choice is an organisation-level setting.
Look at what the two choices mean in practice. Block, and your inspection server becomes a single point of failure for everyone using Claude in the building. Let the traffic through, and the control is advisory on exactly the days something is going wrong.
Anthropic calls this failure handling, and it decides whether you have a wall or a suggestion. It gets set once, during rollout, by whoever had the config screen open. Afterwards, few people ever open it again.
What should the timeout be?
Anthropic publishes the default and leaves the number to you. The useful answer depends on what your server actually does with the transcript.
A lookup against a list of patterns finishes in milliseconds, and five seconds is plenty. A language model that has to read a long conversation and judge it can comfortably run past the timeout on a busy day. Measure how long your own server takes on the slowest ten percent of requests, and set the timeout from that. Without the measurement, any choice is a guess.
Shadow mode is right on day one
Anthropic has built three ways to roll this out. Shadow mode observes real traffic without blocking anything. A rollout percentage inspects a chosen share of requests. Exclusions exempt members of chosen roles entirely.
All three are sensible practice. Nobody is locked out on day one, and you find out how many false positives your rules produce before they land on a colleague.
Put the date you leave shadow mode in the same ticket as the one that turns it on. Shadow mode logs everything and blocks nothing, so a quarter can pass with a tidy dashboard and no enforcement at all. From the outside it looks like an organisation with a grip on things. From the inside there is no control.
The date is cheap to write and hard to route around. Without it there is no day on which anyone has to make a decision, and a temporary state with no end date becomes a permanent one.
Your colleague reads a sentence you did not write
When a request is denied, the user sees a message. Anthropic assembles it from two parts. First the reason your server supplied in the deny_reason field. Then a standing message your administrators configure, for example who to contact, or how to request an exception.
If the administrators have not configured one, a built-in default takes over. It tells the user to contact their administrator, and nothing else.
That field ships empty. Somebody has to write the text, and filling it in is not a step in the rollout.
Think about when the message gets read. A colleague is mid-task, has just pasted something into Claude, and gets a refusal. If all it says is 'contact your administrator', they have three options. They can drop the task, ask a colleague, or find a way round. Two of the three are bad for you, and the last one is the fastest.
Whoever writes that sentence decides whether the control reads as governance or as a wall with no door. A good refusal says three things: what triggered it, what the person can do instead, and who can grant an exception.
It is the cheapest text in the whole project, and the only text an ordinary user ever meets.
A photograph of a contract goes straight through
Anthropic lists the limitations itself, on its own documentation page, under a heading called Current limitations. They are neither hidden nor a discovery. Two of them follow directly from how the feature is built.
The first: attachments are represented by metadata and extracted text. Raw file and image bytes are never sent to your server. Content that exists only as an image, for example a screenshot of a document, is therefore not inspected.
The second: verdicts are allow or deny. Rewriting or redacting a prompt is not supported.
The first limitation has a consequence you can act on this week. If your rule is that contracts must not be pasted into Claude, the rule applies to text. A screenshot of the same contract goes through without being read.
So the decision is what your rule for attachments should be, and whether any rule can be enforced at all by a filter that only sees text. A ban that covers one of two equally easy routes is a rule people learn to walk around without noticing they are doing it.
The second limitation is a design choice with a real argument behind it. A control that rewrites a user's prompt silently changes what they asked.
The cost is that your policy is binary. There is no middle path where one line is removed and the rest goes through. Every rule you write has to be able to carry a no to the whole request.
Run the timeout drill on something you already own
Claude Enterprise is not a precondition for using the rest of this article. The most consequential setting in Claude inference hooks also sits in systems you already run.
The DLP scanner on your mail. The fraud check in your payment flow. The virus scanner on file uploads. The SSO check that has to answer before anyone gets in. Every one of them sits in front of a person who is waiting, and every one has a timeout and a behaviour when that timeout expires.
Take one of them and answer three questions.
- What is the timeout? A number in seconds, found in the configuration rather than in somebody's memory.
- What happens when it expires? Is the request blocked, or does it go through uninspected?
- What should it be? The first two answers are a description. The third is a decision, and it has an owner.
Most companies can answer the first question. Fewer can answer the second. Almost nobody has written down the third, because the setting was chosen during a rollout and the rollout ended.
That kind of thing drifts quietly. The setting itself does not change, but the traffic, the rules and the staffing around it do. If you want somebody looking at that on an ongoing basis rather than once, a retainer is how I work.
And then the fourth question, which is the one I would ask first.
Who found out last time it happened? There is a day when your scanner was down or slow, and the traffic either stopped or went through uninspected. If nobody in the room can remember that day, it rarely means the control has never failed. It usually means nobody was looking.
FAQ
Frequently asked questions
A feature where Anthropic sends the conversation transcript to a server your organisation operates and waits for an allow or deny before the model runs. A deny means the request never reaches the model. The feature is in beta and requires Claude Enterprise.
Anthropic's default is five seconds, and the timeout is configurable by the organisation. If the server does not answer in time, your own failure handling setting decides whether the request is blocked or proceeds without inspection.
The same as an expired timeout. You choose in advance between blocking the request and letting it proceed without inspection. It is an organisation-level setting, and there is no third option.
No. Anthropic states that verdicts are allow or deny, and that rewriting and redaction are not supported. Your policy is therefore binary: either the whole request goes through, or the whole request is refused.
No. Anthropic states that attachments are represented by metadata and extracted text, and that raw file and image bytes are never sent. Content that exists only as an image is therefore not inspected.
Anthropic writes that it does not store prompt or response content as part of the feature, only metadata about hook activity: verdicts, timestamps and request identifiers. The transcript itself is sent to your own server.
A single hook governs claude.ai, Cowork and Claude Code across the organisation, on web, desktop, mobile and the command line. Amazon Bedrock and Google Cloud are not covered, voice mode is not covered, and Claude Platform organisations are out of scope.
Direction and timing. With the Compliance API you call Anthropic and pull activity and transcripts afterwards. With inference hooks Anthropic calls you, inline, before the model runs, and your answer can stop the request.
Sources
Anthropic: Inference hooks (documentation) →
Anthropic: Inference hooks for Claude Enterprise (5 August 2026) →
