What Inference Hooks actually does
The mechanism, as Anthropic itself describes it: a user submits a request on a 'governed' surface - Claude in the browser, Claude Code, Cowork. Before the model starts working, Anthropic sends the conversation transcript in a signed HTTPS POST to the company's configured security server. That server responds within a configurable timeout (five seconds by default) with a simple JSON object: 'allow', or 'deny' with a reason. On deny, the user sees a rejection message with the reason, the model is never called, and the event lands in the company's activity log.
Important for context: the security server runs on the company's own infrastructure or a security vendor's, not Anthropic's - control formally stays with the customer. But the checkpoint itself sits on Anthropic's own servers, after the request leaves the user's device and before the actual model call. That allows uniform enforcement across every surface without installing anything on individual devices - a real, undeniable advantage over classic network-based DLP, which often struggles to inspect encrypted, distributed AI traffic at all.
The gap that lines up exactly with our MCP analysis from last week
Last week we described here why tool poisoning is the one genuinely new attack type in MCP servers: a tool's description is prose the language model reads as an instruction. Classic security scanners check code, not that text - the flaw lives in meaning, not syntax.
The technical documentation for Inference Hooks answers a question none of the press coverage asked: does the new checkpoint even see those tool descriptions? The answer is stated there, plainly and unambiguously: 'system prompts and tool definitions are never included' in what's sent. Per the documentation, the security server sees what the user sees - transcript text, tool calls and their results, text extracted from attachments. The tool's own definition - exactly where a manipulated description would place a hidden instruction - is explicitly excluded.
In practice that means: a compromised MCP tool with a rigged description - exactly the attack pattern security researchers have documented as tool poisoning - stays invisible to Inference Hooks, no matter how carefully the security server is configured. This isn't a criticism of the implementation, it's a deliberate boundary of the approach: Inference Hooks checks what flows through the pipe, not what the model reads from its own tool definitions. Anyone adopting the feature because the MCP headlines of the past few weeks left them uneasy should know exactly this distinction - some coverage framed the launch as a response to 'agent security gaps' in general, a framing that quietly papers over this precision.
A second, subtler gap: only one event, and it fires before the thinking, not after
A second detail in the documentation is just as precise and just as overlooked: 'today the only hook event is prompt ... response-side enforcement is planned as a later event'. That means: the check fires when a new request is submitted - not at the moment a tool delivers a response within the same conversation turn and the model acts on it directly. Earlier tool calls and their results do get sent along as part of the conversation transcript once the next request is checked - but there's currently no real-time gate immediately after a single tool response, before the model reacts to it in that same turn.
For a multi-step agent workflow - call tool A, process the result, call tool B, act - that means: if a compromised tool response pushes the model into an unwanted action within a single turn, the current beta only sees it in hindsight, once the user submits their next request - not at the moment it matters. That's also stated in the documentation, not in the announcement itself. It isn't a gross weakness, but it's a nuance that separates 'this feature protects us from compromised agent chains' from the more accurate claim: 'this feature protects us from problematic user requests, with limited, retrospective visibility into what tools did in between'.
A decision Anthropic deliberately leaves to the customer
A third detail concerns not the feature itself but a fork every adopting company has to set on its own: what happens if the company's own security server is unreachable, returns an error, or exceeds the timeout? Per the documentation, a setting the company configures itself decides the outcome - block (fail-closed) or let requests through uninspected (fail-open). There's no Anthropic default that makes this call for you.
That choice sounds technical, but it's a genuine business decision with real consequences in either direction. Fail-closed means: if the security server goes down - say, during your own infrastructure maintenance window - all Claude usage in the company stops until it's back. Fail-open means: right at the moment your own security check fails, every request flows through uninspected - precisely when something in your own infrastructure is already not working correctly. There's no answer that's right for every company; there's only the need to make it deliberately, before the first real outage makes it for you.
What this means in practice
None of these three points argue against adopting Inference Hooks - quite the opposite: a uniform, device-independent checkpoint across every Claude surface is a real improvement over the previous patchwork of client-side hooks and network DLP. The point is to use the feature for what it actually delivers per its own documentation, and not to inflate the expectation beyond what Anthropic itself states.
- Don't sell it internally as MCP protection: if your organisation is telling itself that Inference Hooks resolves the MCP security questions of the past few weeks, correct that - tool definitions are explicitly excluded per the documentation. The MCP hardening from our previous analysis (classic server-side authentication and validation, treating tool descriptions like code) remains necessary regardless.
- Set fail-open or fail-closed deliberately, don't leave it at the default: this decision belongs in your own security plan, with a clear rationale for why one direction or the other is right for your specific use case.
- Before rolling out, check which channel Claude runs through in your organisation: the feature isn't available via Amazon Bedrock or Google Cloud, nor for pure API access. If you source Claude through one of those channels, Inference Hooks currently isn't usable, regardless of your need for it.
- Actually use the staged rollout (shadow mode, then a growing percentage) instead of switching on hard enforcement immediately - Anthropic's own recommendation, because in practice, hard enforcement from day one blocks operations before the policy is even calibrated.
One last point that reaches beyond this single feature: Inference Hooks is exclusively tied to Anthropic's own infrastructure. For a company that - as described in an earlier analysis here - is deliberately building the ability to switch between AI providers, that's a cost that appears on no price list: a security policy built here doesn't automatically travel with you if you switch or add a provider for capacity or pricing reasons. That's not a reason to skip the feature - but it is a reason to document your own policy logic so it can be rebuilt on another system if needed, rather than letting it quietly live only inside one vendor's configuration dashboard.