Claude inference hooks: an allow/deny checkpoint before every prompt and tool call

On August 5 Anthropic put inference hooks into beta for Claude Enterprise. The mechanism is blunt and easy to describe: before Claude generates anything, the conversation transcript is sent as a signed request to a DLP or security server that your organization runs, that server returns allow or deny within about 5 seconds, and Claude waits for the verdict. The same check runs on every tool-call response, whether the tool came from MCP, a skill or a plugin, and it covers chat, Claude Code and Cowork. It is one org-level configuration, and it is the first inline enforcement point Anthropic has offered outside the client-side hooks in Claude Code.

What the hook can and cannot do

• Allow or deny the whole prompt. That is the entire vocabulary. The server cannot redact a field, rewrite a paragraph, or strip a secret and let the rest through.
• Request side only, for now. Response-side enforcement, checking what Claude is about to return, is planned but not available in the beta.
• A published webhook schema. Anthropic documents the payload, so you can point it at Netskope, Palo Alto, Proofpoint or Zscaler, or write your own receiver.
• Rollout controls. Shadow mode logs verdicts without enforcing them, role-based exclusions keep specific groups out of the path, and percentage rollout enables it for a slice of users first.

Why an agent loop makes this expensive

For a chat prompt, a 5-second budget on the critical path is a tolerable tax. For an agent it compounds. A Claude Code session that makes 40 tool calls now has 40 additional checkpoints, each with a network round trip to your DLP server and a verdict that has to come back before the next step. If your server takes the full budget, that is more than three minutes of added wall time per session. The setup I described in Claude Code with MCP assumed tool calls were cheap; inference hooks make each one a policy decision.

An inline allow/deny hook turns every tool call into a compliance event, which is exactly what regulated teams asked for and exactly what makes the DLP server the slowest component in your stack.

A reference DLP architecture

• Receiver: a stateless HTTPS service that validates the signature, parses the published schema, and returns a verdict. Target well under a second; the 5-second budget is a ceiling, not a goal.
• Classifiers: run the cheap ones first (regex for secrets, customer identifiers, ticket patterns), then a policy lookup by user role and workspace, and only then anything model-based. Any classifier can say deny on its own; only all of them together say allow.
• Shadow first. Run in shadow mode for two weeks and measure the deny rate by role and by surface (chat vs Claude Code vs Cowork). A high deny rate on Claude Code usually means a rule is matching code, not data.
• Tool-call awareness. Tool responses are the riskiest payload: a database MCP server returning rows is where PII actually appears. Log which tool produced each denied payload so you can fix the tool, not just block the user.
• Timeouts and fail mode. Decide explicitly whether a slow verdict fails open or closed per surface. Fail closed for external-facing agents, fail open with an audit record for internal chat, is a defensible default.
• Metrics: p50 and p99 verdict latency, deny rate, timeout rate, and added session time per agent run. These are the numbers your engineers will ask for on day one.

The honest limitation

The hook cannot redact, and that is the gap that will bite. Real DLP policy is rarely 'block the whole message'; it is 'strip the account number and let the question through'. Until response-side enforcement and some form of transformation exist, an over-eager server just makes Claude unusable for the people whose work touches sensitive data, which pushes them to tools with no hook at all. Pair it with the security scanning of third-party skills and plugins that Anthropic added for Enterprise on August 6, and with the patterns in guardrails and output validation, and treat the hook as a tripwire, not a filter.