[release] 6 min · Aug 8, 2026

Anthropic Inference Hooks — Inputs Covered, Outputs Not

Anthropic's pre-inference hooks route every governed Claude prompt to your organization's DLP server for allow/deny checks; output enforcement remains roadmap-only.

#enterprise-security#dlp#claude-enterprise#anthropic#ai-governance

Anthropic launched inference hooks on August 5 — a beta feature for Claude Enterprise that routes every employee prompt through the organization’s own security server for an allow-or-deny verdict before Claude ever sees the input. One org-level configuration covers claude.ai chat, Claude Code (web, desktop, terminal CLI), and Claude Cowork. The feature extends inline DLP — the kind security teams already run on email and web traffic — to AI interactions. The catch buried in the technical docs: response-side enforcement is not available. It is on the roadmap.

TL;DR

  • What: Anthropic ships pre-inference DLP hooks for Claude Enterprise — every governed prompt hits your security server before the model processes it
  • Coverage: Single config governs claude.ai, Claude Code, and Claude Cowork
  • Gap: Response-side enforcement (including real-time MCP/tool response inspection) is roadmap only — model outputs and new tool responses are uninspected in this beta
  • Action: Treat this as a floor for enterprise AI governance, not a ceiling — your output boundary is still open

Inference Hooks — What Happened

The mechanism is straightforward. When a governed user sends a prompt, Anthropic fires an HTTPS POST to the organization’s configured AI security server endpoint. The request body carries the conversation transcript, signed according to the Standard Webhooks specification using a signing secret the organization generates during setup. The security server evaluates the content — checking for PII, regulated data, policy violations, whatever the DLP ruleset demands — and responds with a verdict: allow or deny. Claude waits for that verdict within the timeout the organization configures, which defaults to five seconds.

If the security server is unreachable, errors out, or blows the timeout, the organization chooses the failure posture: block the request (secure-by-default), or let it through uninspected (availability-first). That failure policy decision alone is a meaningful security configuration — get it wrong and you either brick Claude for the entire org during a server hiccup, or you silently bypass your own DLP during an outage.

Anthropic names Netskope, Palo Alto Networks, Proofpoint, and Zscaler as destinations organizations can point the hook at, alongside in-house servers. The protocol is webhook-based with a published schema, so any server that can receive HTTPS POSTs and respond within the timeout window works. This is not a proprietary SDK integration — it is a webhook contract.

# Conceptual flow (simplified)
User prompt → Anthropic POST (signed webhook) → Org DLP server → allow/deny → Claude inference

The single-configuration approach is the real operational win. Before inference hooks, an enterprise security team would need to instrument each Claude surface separately — chat sessions through one proxy, Claude Code through another, Cowork through yet another. Now one endpoint configuration applies across every governed interaction surface. For organizations that have been blocking Claude adoption entirely because they could not inspect inputs, this removes the primary objection.

Why This Matters

Here is where the marketing diverges from the technical reality, and where security teams need to pay close attention.

The launch blog post and the technical documentation tell two different stories about tool response handling. The blog post says tool responses — including those from MCP connectors, skills, and plugins — are checked before being sent back to the model. The technical documentation says the only hook event available today is prompt, which fires once per governed inference request, before inference begins. Response-side enforcement is explicitly described as planned for a later event.

There is a documented conflict between Anthropic’s announcement blog and technical docs on MCP tool response inspection. The blog implies tool responses are checked; the technical docs say only the prompt event exists today and response-side enforcement is planned. Treat real-time tool response inspection as not covered in this beta until Anthropic clarifies.

The practical reading: the security server inspects the conversation transcript as it exists at the moment of the prompt — which includes past tool activity already recorded in that transcript. But it does not intercept new tool responses as they arrive in real time. An MCP connector pulling data from an internal database, a skill fetching customer records, a plugin returning financial data — those responses flow back to the model without hitting the DLP checkpoint.

This matters because the threat model for enterprise AI data leakage is not symmetric. Prompt-side leakage — an employee pasting a confidential contract into the chat — is the obvious risk, and inference hooks handle it well. But output-side leakage is the subtler, often larger exposure: Claude retrieves sensitive data through an authorized tool connection, synthesizes it into a response, and that response sits in a chat window, gets copied into an email, or gets exported. The employee never typed anything sensitive. The model pulled it.

The comparison to peers is instructive. OpenAI’s Compliance API takes a post-hoc approach — exporting conversation logs for after-the-fact review rather than inline enforcement. Google extends existing Workspace DLP rules to Gemini, applying the same policies that already govern Docs and Gmail. Anthropic’s webhook-based pre-inference approach is architecturally the most elegant for input inspection — it is real-time, inline, and leverages existing DLP infrastructure — but it is also the only one of the three that has a publicly documented gap between input enforcement and output enforcement.

If your organization uses MCP connectors that access internal data, inference hooks alone do not prevent sensitive data from appearing in Claude’s responses. You still need network-level controls, connector-level access policies, and output monitoring through separate tooling.

The operational overhead is not trivial either. Your DLP server must respond within five seconds under load — not five seconds on a good day, five seconds at peak when 200 engineers are prompting Claude simultaneously. Latency spikes mean either blocked productivity (fail-closed) or bypassed security (fail-open). This is a server you now have to staff, monitor, scale, and keep highly available. For organizations already running inline DLP proxies for email and web, the infrastructure pattern is familiar. For organizations that have never operated a real-time policy enforcement point, this is a meaningful new operational burden.

The Take

I have been waiting for an AI vendor to give enterprise security teams real inline enforcement, and Anthropic delivered — on the input side. Inference hooks solve the genuine blocker that has kept risk-averse organizations from deploying Claude: the inability to inspect and govern what employees send to the model. That problem is now solved, and solved well. The webhook-based architecture is clean, the Standard Webhooks signing provides verifiability, and the single-config-across-surfaces approach eliminates the per-product integration headache that makes security teams want to strangle product managers.

But if your security team thinks enabling inference hooks means they have closed the AI data leak, they have not. They have moved it one layer downstream. The prompt boundary is yours to own; the output boundary still is not. An employee can ask Claude something benign, trigger an MCP connector that retrieves sensitive internal data, and receive a response containing that data — entirely unexamined by the DLP checkpoint. The employee never typed a secret. The model fetched one.

Treat inference hooks as a floor, not a ceiling. Turn them on — they are unambiguously worth enabling. Then build the rest of the stack: connector-level access controls, network-level egress monitoring, and output audit logging through whatever post-hoc mechanism you can wire up. When Anthropic ships response-side hooks, layer those on too. Until then, the pipeline has a gap, and pretending otherwise is worse than not having DLP at all — because at least without DLP, nobody on your security team is under the illusion that the problem is solved.