Inference hooks route every governed prompt in a Claude Enterprise organization through an AI security server the organization or its vendor operates, before inference runs; a denied request never reaches the model [1]. The hook runs on Anthropic’s servers, after the request leaves the client, with nothing installed on user devices [1]. Anthropic’s own comparison places it opposite the Compliance API: hooks act inline, before inference; the Compliance API acts after the fact [1]. The feature is in beta for Claude Enterprise [1].
On first save, failure handling defaults to Allow the request — fail open [2]. Blocking when the server cannot deliver a verdict is a choice an administrator makes. Our observation is that whether the gate is closed is a configuration fact, and the documentation describes several paths by which governed requests pass uninspected even when it is.
Three States and a Default
The configuration page defines three enforcement states [2]. Off: the AI security server is never contacted. Shadow: the server receives prompts and returns verdicts, and nothing is blocked — every request proceeds even when the server denies it or cannot be reached. Enforcing: a deny blocks the request.
Failure handling governs what happens when the server is unreachable or a verdict times out: block the request (fail closed) or allow it to proceed without inspection (fail open) [2]. The defaults on first save are fail open with a 5,000 ms timeout, and a slower verdict counts as an unreachable server [2]. Allowing the feature for an organization always forces enforcement off, so inspection never starts by itself [2].
Who can set the gate is narrow. Configuring Inference hooks requires the organization:manage permission, which only the Owner and Primary Owner roles hold; the Admin role does not [2].
The Enforcement Envelope
Failure handling decides the outcome for requests that are inspected. Which requests are inspected is decided elsewhere:
- Rollout. A percentage from 0 to 100 sets how many requests are inspected. Each request rolls once for its conversation turn, so one conversation can be partially inspected. Requests outside the sample proceed without inspection, even when failure handling is set to block [2].
- Exclusions. Members of selected custom roles are never sent to the server. Exclusion applies to interactive sessions; traffic authenticated by machine credentials is always inspected [2].
- Scope. Governed requests are the inference requests behind the user’s conversation. Ancillary requests such as title generation are not sent, voice mode is not covered, and the feature is unavailable on Amazon Bedrock and Google Cloud and for Claude Platform organizations [1].
- Content. The server never receives raw file or image bytes, system prompts, tool definitions, or Anthropic-internal context, so image-only content is not inspected. Verdicts are allow or deny; redaction is not supported [1].
Stated precisely, inspection coverage is the product of rollout, exclusions, and scope. Fail closed governs only the requests inside that product.
Two kinds of uninspected traffic follow, and they are different control facts. Requests outside the product are uninspected by design; their extent is read from the settings in force. Requests inside it that pass because the server could not deliver a verdict are uninspected by degradation; the feed records them under failure handling, and a tripped breaker is recorded as one activity per trip [2].
When the Breaker Trips
Sustained failures attributable to the AI security server trip a circuit breaker. Enforcement stops, the server is no longer contacted, and the failure handling choice applies to every inspected request; under block, users are blocked until the breaker resets [2]. Administrators are notified, and each trip is recorded in the Activity Feed — one activity per trip, not one per affected request, and only where the Compliance API is enabled [2].
While the breaker is tripped, no per-request Inference hooks activities are recorded; the trip activity is the feed’s record of that window [2]. The breaker can reset itself: starting ten minutes after a trip, Anthropic sends background test requests about once a minute and resumes enforcement on a valid verdict — but only while the hook settings are unchanged since the trip [2].
Our observation is that under fail open, a tripped window is a span of uninspected traffic recorded as a single event. Its duration has to be reconstructed from the trip activity and the reset.
A Healthy Panel
The settings page shows endpoint status, failures per minute, block rate, the last breaker trip, and recent errors [2]. Anthropic describes the panel as best-effort: if the counters cannot be read, it shows zero failures and no errors rather than an error of its own, and a healthy-looking panel is not by itself proof that the server is healthy [2]. Failures per minute also counts network and DNS errors that never trip the breaker [2]. The panel is an operational view. The Activity Feed is the record.
What the Gate Records
The feed records hook configuration changes, denials, breaker trips, and requests that proceeded without inspection under failure handling; denial records carry identifiers that join each denial to the matching record in the enterprise’s own system [2]. The hook system keeps no copy of prompt content, and a message a hook blocks on claude.ai stays in the conversation under that product’s own retention [1]. A denied prompt is a gate event and a record event at once.
The integrations Anthropic lists for the Compliance API span data loss prevention, SASE, SIEM, identity, eDiscovery, and AI security posture management [3]. Our observation is that a control built on that channel takes its timing from the channel, and the channel acts after the fact. Inline enforcement runs through the hook.
What the Gate Asks of the Enterprise
The documentation defines the gate and its envelope. Our observation is that four practices follow.
Choose failure handling deliberately. The default is fail open. A decision to keep it belongs in the control record with its rationale.
Attest the envelope, not the switch. Enforcement state, failure handling, rollout percentage, and the exclusion list together define the designed envelope — what was meant to be inspected. Snapshot them on a cadence and on every recorded change.
Alert on the trip activity. Treat the feed’s breaker-trip record as the signal and the settings panel as advisory.
Reconcile degradation from the feed. Requests that proceeded without inspection under failure handling, and each breaker trip, are degradation inside the envelope, not coverage design. Review them separately from what the rollout and exclusion settings leave out by design.
Inline enforcement is native to Claude Enterprise, in beta, and its first-save default is fail open. Our observation: rollout, exclusions, failure handling, and breaker state together define what the gate inspected, and each has to be attested before a denial log can stand as evidence of control.
