On 5 August Anthropic put your security team inside its inference path: inference hooks, in beta for Claude Enterprise, route every employee prompt to a server you run for an allow-or-deny verdict before the model sees it. That is a real answer to a gap every network DLP proxy has had since the first person opened an AI tool on a phone. It is also prompt-side only, Enterprise-surface only, and explicitly not covering the Claude Platform API, Bedrock or Vertex — which is to say it does not cover the agent fleet, and the agent fleet is where the data actually moves.
What shipped
An inference hook is a synchronous callout from the provider to an HTTP endpoint you control. Before a prompt reaches the model, Anthropic sends it to your server; your server returns allow or deny; Claude enforces the decision. The design point is that the enforcement lives with the vendor and the policy lives with you.
| Property | At launch | Why it matters |
|---|---|---|
| Coverage | Claude Enterprise surfaces — chat, Claude Code, Claude Cowork and more | Follows the user, not the network. A phone on a home connection is inspected exactly like a managed laptop. |
| Hook events | One: fires on the prompt, before inference. Response-side enforcement is planned as a later event. | You can stop data going in. You cannot yet stop what comes out. |
| Rollout controls | Shadow mode, a rollout percentage, role-based exclusions | The difference between a security control and a self-inflicted outage. |
| Integrations | Compatible with existing DLP — Netskope, Palo Alto Networks, Proofpoint, Zscaler — or a server you build | The classifier you already tuned keeps its job; only the transport changes. |
| Out of scope | Claude Platform API access; Claude on Amazon Bedrock or Google Cloud | This is the whole argument below. |
The gap this genuinely closes
Network DLP was built on an assumption that stopped being true around 2015 and has been quietly failing ever since: that corporate data leaves through a network you control. A TLS-inspecting proxy sees traffic from a managed device on a managed network. It does not see a personal phone, a contractor's laptop, a home machine at 22:00, or a mobile app that pins certificates. Every one of those is a fully-functional path to a frontier model.
Moving the inspection point to the provider dissolves that problem for the surfaces it covers, because the check follows the account rather than the packet. That is a genuine architectural improvement and it is worth saying plainly, because the reflex in security circles is to treat any vendor-hosted control as a weakening. This one is strictly more coverage than the thing it supplements — for chat, for Claude Code and for Cowork.
It also lands on the surfaces that were hardest to inspect. A coding agent's prompt contains repository contents; a Cowork session's prompt contains whatever files the user pointed it at. Those are exactly the payloads a network proxy struggles with and exactly the ones a policy engine most wants to see.
The gap it leaves is the one with the volume in it
Sort your organisation's model traffic by volume of sensitive data per unit of human attention and the ranking is not close. An employee pasting a customer record into a chat window is one record, seen by one person, at human speed. A retrieval-augmented agent answering support tickets pulls thousands of records an hour, unattended, and every one of them lands in a prompt. That traffic goes through the Claude Platform API, or through Bedrock, or through Vertex. None of it is in scope at launch.
This is not a criticism of a beta's boundaries — Enterprise surfaces are the obvious place to start, and the API is a genuinely harder problem, since the "user" there is your own code and you already own that code path. It is a warning about how the control will be read. A board slide saying "inline DLP now enforced on all Claude usage" is the natural summary and it is wrong in the specific place that matters, and the shape of the error is familiar: the control covers the traffic that is easy to attribute to a person and misses the traffic that has no person attached.
Two further limits are worth holding in view.
Prompt-side only means half the risk surface. Blocking what goes in does nothing about what comes out. An agent that has legitimately retrieved a document can still return it to someone not entitled to see it, and an over-permissioned retrieval tool is a far more common exfiltration path than an employee pasting a secret. Response-side enforcement is planned; until it exists, output-side checks stay yours to build — see data exfiltration & tool misuse.
Prompt inspection is not injection defence. A DLP verdict on the prompt asks "is there sensitive data in this text". Prompt injection asks the opposite question — "does this text contain instructions the model will follow" — and the injected instruction usually arrives in a tool result or a retrieved document, which is not the prompt and is not inspected. Nothing here changes the boundary controls in prompt injection.
The useful framing: inference hooks are a user-facing control that happens to sit at the provider. They are not an agent-facing control. Those are different threat models with different actors, different volumes and different remedies, and a policy written for the first will not hold the second.
An inline control on your critical path is a new dependency
The moment you enable enforcement, your DLP server is in the synchronous path of every prompt your company sends. That is a substantial change in what that server is, and it comes with three questions most teams answer after the first incident rather than before it.
What is the latency budget? Every prompt now waits for your verdict. A classifier that takes 300 ms is invisible in a chat window and painful in a coding agent that makes twenty model calls per task, where it becomes six seconds of pure overhead per run. Inline inspection is a per-call tax and agents multiply per-call taxes.
What happens when the hook server is down? Fail-closed means an outage in your security tooling becomes an outage in everyone's ability to work. Fail-open means an attacker who can degrade your DLP server gets an unfiltered window. There is no clever third answer; there is a decision, and it should be made deliberately, written down, and rehearsed — the reasoning is in graceful degradation & fallback.
What does a blocked user actually see and do? A denial with no explanation produces a support ticket and, worse, a workaround: the same person pasting the same content into a consumer tool on a personal device, where you have no visibility at all. The failure mode of aggressive inline blocking is not leaked data; it is shadow IT. A block that says which policy fired and what the sanctioned path is keeps the user inside the system.
Shadow mode exists precisely so these get answered on real traffic before anyone is blocked. Run it long enough to see a week of normal work, measure the false-positive rate against actual prompts rather than test strings, and only then start enforcing on a percentage. The rollout controls Anthropic shipped are the interesting part of this release for practitioners; a hook without them would be unusable in an organisation of any size.
The pattern is bigger than one vendor's beta
Strip the branding and this is a policy enforcement point moving from the network layer to the application layer, arriving at the one place that can see every request regardless of how it got there. That direction is not going to reverse, and three consequences follow for anyone building agents.
The provider becomes a control plane, and control planes attract obligations. Once a vendor can enforce your policy, auditors, regulators and customers will ask whether you enforced it. "We could not see that traffic" is a weaker answer each time a mechanism exists that could have. Expect the question to arrive first in enterprise procurement questionnaires, which is where third-party model and vendor risk gets converted into contract language.
Portability gets worse before it gets better. A hook contract is vendor-specific: this schema, these events, this failure semantic. Build enforcement against one provider's shape and you have added a migration cost that does not appear in any pricing comparison. The hedge is the usual one — keep the policy logic in your own service and treat each provider's hook as a thin adapter, so that the thing you own is the classifier and not the integration.
Coverage parity becomes the thing to demand. The interesting version of this feature is the one that covers programmatic access, fires on responses as well as prompts, and works when a model is served through a cloud marketplace. Every gap in that list is a place where your policy is enforced for the employee typing at a keyboard and not for the agent running at ten thousand requests an hour on their behalf.
What to do this week
Four moves, in order, whether or not you turn the feature on.
Inventory your model traffic by path, not by tool. How much goes through Enterprise surfaces, how much through the API, how much through Bedrock or Vertex, and which paths carry regulated data. Most teams have never drawn this and are surprised by the ratio. It is also the only way to know what fraction of your exposure this control touches.
Turn on shadow mode and measure, before deciding anything. A week of verdicts on live traffic tells you more about your classifier than any evaluation set. Expect the false-positive rate on real prompts to be higher than on your test corpus, and expect the worst offenders to be engineers pasting stack traces and support staff pasting customer emails.
Build the API-side control yourself, because nobody is shipping it for you. A middleware layer in front of your own agent calls, doing the same classification, is a week of work and covers the traffic with the volume in it. It also survives a provider change, which the hook does not. The placement argument is the same one in policy enforcement & controls.
Write down the fail-open or fail-closed decision, and rehearse it. Then check that a blocked user gets a message naming the policy and the sanctioned alternative. That sentence is the difference between a control that holds and one that quietly relocates your data to a consumer app on someone's phone.
FAQ
What are Claude Enterprise inference hooks?
A beta feature announced on 5 August 2026 that routes every prompt on Claude Enterprise surfaces to a security server the customer runs, which returns an allow-or-deny verdict before the prompt reaches the model. Claude enforces the verdict in real time. It works with existing DLP products including Netskope, Palo Alto Networks, Proofpoint and Zscaler, or with a server built in-house.
Does this cover API traffic and agents?
No. At launch, coverage is Claude Enterprise surfaces — chat, Claude Code, Cowork and more. Claude Platform API access is out of scope, and Claude served through Amazon Bedrock or Google Cloud gets nothing. Since autonomous agents overwhelmingly run through those paths, the highest-volume sensitive traffic in most organisations remains outside the control.
Can it inspect what the model says back?
Not yet. The only hook event at launch fires on the prompt before inference. Response-side enforcement is planned as a later event, so output-side controls — including anything guarding against an over-permissioned retrieval tool returning documents a user should not see — remain the customer's to build.
Does it stop prompt injection?
No, and it is not designed to. DLP inspection asks whether sensitive data is present in the prompt; injection is about instructions the model will follow, and those typically arrive in tool results or retrieved documents rather than in the user's prompt. Injection defence still rests on boundary controls: scoped credentials, egress policy, and human approval for irreversible actions.
What breaks if the hook server goes down?
That depends on the fail-open or fail-closed choice, and it is a decision worth making explicitly before enabling enforcement. Fail-closed turns a security-tooling outage into a company-wide work stoppage; fail-open gives anyone who can degrade the hook server an unfiltered window. Shadow mode and a rollout percentage exist so the choice can be tested before it is load-bearing.
Should we use shadow mode first?
Yes. Shadow mode computes verdicts on live traffic without blocking anything, which is the only way to measure a false-positive rate against real prompts rather than test strings. Aggressive inline blocking without that measurement does not usually leak less data — it pushes users to consumer tools on personal devices, where there is no visibility at all.
Further reading
On this wiki:
- Policy Enforcement & Controls — where an enforcement point belongs in an agent stack.
- Data Exfiltration & Tool Misuse — the output-side risk a prompt-only hook does not touch.
- Data Governance for Agents — what an inventory by path is for.
- Graceful Degradation & Fallback — the fail-open decision, made deliberately.
- Prompt Injection — the different threat this control is often mistaken for.
- Third-Party Model & Vendor Risk — how a vendor control becomes a contractual obligation.