Inference Hooks

What are Inference Hooks, and how do they differ from typical content filtering?

Inference Hooks are a mechanism that intercepts a request before it reaches the model and routes it to an organization's own security server for inspection. The server returns an "allow" or "deny" verdict, and Claude enforces it in real time — if denied, the content never gets processed by the model; tool call results go through the same check before being returned to the model.

The key difference from typical content filtering is timing and control. Ordinary filtering mechanisms are usually built into the system with rules defined by the platform; Inference Hooks instead hand the verdict to a security server the organization sets up itself, letting the organization apply its own existing security policies, and the interception happens before the model even begins generating content, not as a scan of output that's already been produced.

Why are Inference Hooks needed, and what problem do they solve?

Enterprise security and compliance teams typically require every channel through which employees could leak sensitive data to pass through an inspection point their own team controls — this is a basic requirement of existing DLP (data loss prevention) frameworks. But before Inference Hooks launched, Claude's native real-time enforcement only covered Claude Code's client-side hooks; enforcing real-time gating on other surfaces (regular chat, Cowork, and so on) meant an enterprise had to build a separate integration for each product, at considerable cost.

Inference Hooks uses a single enforcement layer that covers every surface under Claude Enterprise, closing the gap where surfaces other than Claude Code lacked native real-time interception. An enterprise only needs to connect its own security server once to extend an existing DLP system (such as Netskope, Palo Alto Networks, Proofpoint, Zscaler, or an in-house-built security server) to cover every Claude surface, instead of integrating separately for each product.

How do Inference Hooks actually work, and how is data inspected?

Once an organization turns on Inference Hooks, every inference request routes through a signed WebSocket connection to the organization's own security server. Before the model begins generating content, Claude sends the prompt and its surrounding context to this server, which returns an allow-or-deny verdict; Claude only proceeds once it has received that verdict. The same check applies to tool calls: after Claude calls a tool (including tools reached through MCP connectors, skills, and plugins), the result the tool returns goes through the same server-side check before being confirmed clean and passed back to the model.

Organizations can roll this out at lower risk using shadow mode (observe without actually blocking), role-based exclusions for specific users, or percentage-based gradual rollouts, and can customize details like failure-policy tolerance and timeout settings to match their own risk appetite. The whole mechanism is built on an open, published webhook protocol with a documented schema, so security vendors can also build their own integrations against it.

What do Inference Hooks actually mean for me, and when should I consider enabling them?

This mechanism is currently a beta feature limited to Claude Enterprise customers; individual developers or general Pro/Team users won't encounter it directly. If you're on an enterprise security or compliance team and your organization already runs a DLP system (such as Netskope or Palo Alto Networks), the value of Inference Hooks is being able to extend that existing system to cover every Claude surface without rebuilding an integration for each product — worth including on your security control checklist when adopting Claude Enterprise.

If you're a general user, this mechanism won't show up in front of you directly, but understanding that it exists helps clarify something: for enterprises adopting AI tools, "requests get checked against the organization's own security policy before reaching the model" is becoming a concrete, deployable option rather than just a theoretical requirement. If you're internally evaluating whether to hand a category of sensitive work to Claude, whether a real-time interception mechanism like this exists becomes an important reference point for judging whether the risk is manageable.