Last Updated: 6 August 2026
Anthropic has given Claude Enterprise organisations a new way to control what employees send to the AI model. The feature, called Inference hooks, lets a company connect Claude to its own security server, which can inspect a governed request and decide whether Claude is allowed to process it at all.
This is a meaningful change from how enterprise AI oversight has typically worked. Security and compliance teams have grown used to reviewing what happened after an employee used a tool like Claude, checking logs and transcripts once the conversation is already over. Inference hooks changes the moment of intervention. A company can now stop specific content from reaching the model in the first place, rather than only discovering a problem afterward.
The distinction is important because it changes what organisations can actually prevent. A security team that only sees a policy violation after the fact can document it and adjust training, but the sensitive information has already reached the model. With Inference hooks, that same request can be paused, checked and denied before Claude begins generating anything at all.
This new beta feature lets Claude Enterprise organisations enforce their own policies on governed requests before Claude begins processing them. Organisations connect Claude to an AI security server, which they can build themselves or obtain through a security vendor. That server evaluates each governed request against the company's own rules and returns a simple allow or deny decision.
Claude waits for that verdict before moving forward. If the server denies the request, it never reaches the model, and the event is recorded in the organisation's Activity Feed. The system runs on Anthropic's own server-side infrastructure, so nothing needs to be installed on individual employees' computers for it to work.
It is worth being precise about scope here. Coverage applies to governed requests rather than literally every prompt a user sends. Anthropic allows organisations to roll the feature out gradually, exclude certain roles and run it in an observation-only mode, so a broader claim that "every prompt" gets inspected would overstate what is actually happening.
The company deciding what counts as sensitive is the organisation itself, not Anthropic. They built the mechanism that pauses the request and enforces whatever verdict comes back, but the actual policy, whether that means blocking payment card numbers or confidential source code, belongs to the company's own security system.
When an employee submits a request through a governed Claude Enterprise surface, Claude holds it before inference begins and sends relevant conversation information to the organisation's configured security endpoint. That request is signed, so the receiving server can confirm it genuinely came from Anthropic.
The security server reviews the content and sends back a short verdict of either allow or deny. An allow verdict lets Claude proceed as normal. A deny verdict stops the request and can include an explanation for the user along with a reference identifier the organisation can use for later investigation. Administrators can also attach a standing message, up to 500 characters, telling employees who to contact or how to request an exception.
The same checkpoint extends beyond the initial prompt. When Claude uses tools through MCP connectors, skills or plugins, the results those tools return can also be checked before being fed back into the model for another step of reasoning. What the system cannot do is edit anything. It can only allow or deny a request in full; it has no way to strip out a sensitive line and let the rest through.
It is also worth noting that a broken connection is treated differently from an actual denial. If the security endpoint returns an error, sends back a malformed response, or simply cannot be reached, that counts as a failure of the check itself, not an automatic block. What happens next depends on how the organisation has configured its failure handling, a topic covered later in this article.
The organisation's security server can see a large part of the conversation, though not everything Claude uses internally. It receives the current message along with earlier turns in the conversation. It can also receive tool calls and their results. If there are attachments, it gets the text extracted from them, along with basic details like the file's name, type and size.
Alongside the conversation content, the request can carry operational metadata: a user identifier, the user's email address where available, which Claude application the request came from, a session identifier and which model was selected. None of this reveals Claude's internal workings. System prompts, tool definitions, Anthropic's internal context and Claude's hidden reasoning are excluded, and so are raw file or image bytes. Binary outputs such as images are represented with placeholder markers rather than sent as actual data.
There is a practical size limit worth knowing. Transcripts are not truncated, but the total request is capped at 10 megabytes, so a long conversation with large attachments could produce a sizeable inspection payload. Because the endpoint might be run by the company itself or by a third-party security vendor, organisations need to think carefully about how that data is stored and protected once it leaves Anthropic's systems, since Anthropic's role ends at delivering the signed request to a publicly reachable address.
The request doesn't stay inside the company's network. It leaves the employee's device, passes through Anthropic's infrastructure, and reaches a publicly accessible HTTPS endpoint.
This new tool works before anything happens. It gives a company's security team the chance to stop a risky request before it's even processed, not just find out about it afterward. There's already a different tool for that second option, one that lets companies look back at old chats, files and activity once the fact is done. That's useful for investigating a problem, but it doesn't stop the problem from happening in the first place.
The two tools also work in opposite directions. With this new checkpoint, the system reaches out to the company's own server to ask for a decision. With the older tool, it's the company that reaches out to pull records when it needs them. That older tool can also pull more complete information, like full files. The new one works faster but with less detail, using just the text of the conversation, since its job is making a quick decision, not building a full archive.
Before now, this kind of real-time check only existed for one specific product, and it only worked locally, without covering everything else a company might use. Now the checkpoint has moved to run centrally, covering everything at once, so companies don't need to set up something separate for each tool they use. A few security companies say this adds real protection on top of what they already offered, though that's their own description, not something independently confirmed.
The two tools are meant to work together, not replace each other. One tells a company what already happened. The other decides whether something is allowed to happen at all. There are also hints this same technology could end up being used for other things later, like keeping records or running custom rules, so it may end up doing more than just blocking risky requests.
One single setup can cover every conversation across the web version, the desktop app and the command-line tool used within a company. That same setup also applies to anything happening through connected tools, skills or plugins during a conversation, so the coverage isn't limited to just typed messages.
Companies can build their own checking server, or connect one from an outside security company. A few well-known names are already compatible. And it doesn't have to launch all at once. A company can start by just watching what happens without blocking anything, then slowly turn on real blocking over time.
Calling this "one security rule" is a bit of a simplification. It's really one central setup, but it can still apply many different, more detailed rules underneath. The main benefit is not having to build a separate check for every single tool a company uses.
One more thing worth knowing: just because a vendor is mentioned as compatible doesn't mean every customer can use it yet. Some of these integrations are still being rolled out and aren't fully available to everyone.
Every check adds extra time to a request, since it has to travel to the security server and back before anything continues. By default, this can take up to five seconds, though companies can adjust that limit. If the connection fails on the first try, one more attempt is made before giving up completely.
A slow or broken check doesn't automatically stop anything. If the server takes too long, sends back an error, or can't be reached, that's treated as a failure, not a rejection. The company decides what happens next. One option blocks the request until the check works again, which is safer but can interrupt access. The other option lets the request through unchecked, keeping things running but skipping the check entirely.
If failures keep happening, the system eventually stops trying to reach that server altogether and just applies whichever backup rule the company chose, until someone fixes the problem. It's recommended that companies keep their checks fast and test them properly beforehand, though no official numbers exist yet for how much delay to expect in real use. There's one more limit worth knowing. Requests can get fairly large, especially in long conversations. If a company's own server has a smaller limit than that, it might reject the request outright, and that would also count as a failure, handled the same way as any other.
This beta version still has real gaps. Raw images and files are never sent for checking, so something like a screenshot with sensitive text inside it would pass through unnoticed. Text pulled from documents, audio and links can be checked when available, but that still doesn't cover every file or image someone might send.
The system can also only say yes or no. It cannot fix or clean up a risky prompt, only allow or block it completely. And even though the focus is on stopping problems early, it currently only checks what a person sends in, not what the AI sends back. Checking the AI's own responses is planned for later, but there's no date for when that will happen.
Coverage also depends heavily on where and how someone is using the tool. Some platforms and setups aren't covered yet, and a few routine background actions skip the check by default. Even in supported cases, some requests can still slip through unchecked, depending on how a company has configured things. None of this makes the feature useless, but it isn't complete protection either.
This feature is available now, in beta, only for companies on the Claude Enterprise plan. To turn it on, someone needs admin-level access, which Owners and Admins already have by default, and which can also be handed to custom roles if a company wants more flexibility. It's not available yet for regular consumer accounts, people using the API directly, cloud-hosted versions through other providers, or voice mode.
A few practical questions are still up in the air. There's no separate price tag just for this feature. It comes bundled into the regular Enterprise plan, which runs $20 per seat a month plus usage costs. What's not clear is whether every company on that plan gets it automatically, or whether some will need to meet extra conditions first.
There's also no official date for when this moves past beta, or for when it will start checking what the AI writes back, not just what people type in. And since no real numbers have been shared yet on speed or accuracy, anyone curious about how well it actually performs will have to rely on their own testing for now. It's also worth remembering that outside security vendors may have their own separate setup requirements, so having access to this feature doesn't automatically mean a specific vendor connection is ready to go.
There's a bigger question worth sitting with here. Security worries are often what keeps companies from using AI tools more freely, and having a way to catch problems before they happen could go a long way toward easing that hesitation. It's a fair guess, but nothing more than that for now, so it's worth treating as a possibility rather than a settled fact.
It's a security layer companies can add to Claude Enterprise. A company sets up its own server, and before certain messages reach Claude, that server gets a look first and decides whether to let them through. Anthropic rolled it out in beta on August 5, 2026, and for now it's only for business accounts, not personal Claude use.
Before Claude responds, the request gets checked by whatever server the company has connected. That server sends back a simple yes or no. A yes means business as usual. A no stops things immediately, and the person typically sees a message telling them what happened and why.
It sees a fair amount, honestly. The current message, earlier parts of the conversation, and anything related to tools being used. If there are attachments, it gets the text pulled out of them. What it doesn't get is anything happening internally, like Claude's own reasoning or hidden instructions, and it never sees raw images or actual files.
Nothing gets blocked automatically just because the check is slow. It's treated as a glitch, not a rejection, and the company decides ahead of time how to handle that. Some play it safe and pause things until the check works again. Others would rather keep things moving and just let the request through unchecked.
Not quite, no. Images aren't checked directly, so something like a screenshot with sensitive info in it could slip right through. It also only looks at what someone types, not what Claude actually writes back, that part's still coming later. And a few ways of using Claude, like voice mode, aren't covered yet either.
