Claude Enterprise inference hooks left beta on October 20, 2026. They let a security service decide whether a governed prompt or proposed tool call can proceed. Before expanding a deployment, prove that the intended traffic is inspected and that a denial stops the intended effect.
The capability first launched in beta on August 5. October's change is its availability status; it does not establish that every current setting or coverage detail was added that day.
Consider a pilot in which an employee asks Cowork to prepare a customer report, then send it through a connector. The first prompt may be acceptable while the proposed recipient is not. A prompt check and a check before sending answer different questions. This guide uses that hypothetical workflow to build an acceptance procedure. General Analysis has not exercised a customer deployment for this article.
Establish which requests you govern#
Anthropic's current overview distinguishes prompt events from optional tool_call events. The latter require Validate tool calls. Coverage is for governed Claude Enterprise sessions, including Code and Cowork; Claude Platform API organizations, Bedrock, and Google Cloud are outside this feature's scope.
Keep the limits in the rollout record: image bytes are absent, some built-in tools are omitted from pre-execution frames, and voice coverage is incomplete. Hosted Security scans, hosted Code Review, and the model calls that generate smart reports also sit outside governed session requests. Those omissions need separate controls.
Start with a named workflow, account, client, and destination. Ask the workflow owner which data may enter it and which actions need independent approval. Our coding-agent security baseline covers the surrounding permissions and isolation decisions. An inference hook should have a specific responsibility within that baseline.
See how your AI systems hold up under real attacks
General Analysis maps AI applications and agents, red teams prompts, retrieval, tools, MCP servers, browser actions, permissions, and business workflows, then turns findings into evidence your team can reproduce and retest.
Confirm enforcement before testing the policy#
Use an Owner or Primary Owner to follow Anthropic's configuration procedure: allow the feature under Organization settings → Data and privacy, save the endpoint, store the signing secret, and test the connection. Then review enforcement, failure mode, rollout, exclusions, and tool validation together.
A successful connection test can sit behind any of these configurations:
| Configuration | Live behavior |
|---|---|
| Enforce verdicts off | Live traffic is not inspected. |
| Shadow mode | Verdicts are observed; denials do not block. |
| Partial rollout or excluded roles | Some requests bypass inspection, even with fail-closed handling. |
| Enforcing, fail open | A valid deny blocks; a missing verdict permits continuation. |
| Enforcing, fail closed | A valid deny or unavailable verdict blocks inspected requests. |
Changes take about a minute to propagate; in-flight requests retain the old setting. Schedule acceptance checks after propagation and record the configuration used for each check. For a workflow that requires inspection, use full rollout, reviewed exclusions, and fail-closed handling once the pilot passes. Decide who can approve any availability exception before an outage occurs.
Distinguish a denial from a broken integration#
The endpoint contract requires HTTP 200 with a valid verdict for both outcomes. Returning HTTP 403 to signal a policy denial instead invokes failure handling. In fail-open mode, that mistake can let the request continue.
The following illustrative body belongs in an HTTP 200 JSON response after the endpoint authenticates the request and evaluates policy. Its reference identifies your evaluation; it contains no customer data.
Code source: Anthropic verdict schema, adapted with an illustrative reason and reference.
{
"action": "deny",
"deny_reason": "This destination is outside the approved report recipients.",
"reference_id": "pilot-report-042"
}
Have the integration owner verify signatures over the original request bytes. Also check body-size limits across the proxy and application: a rejected large transcript is an integration failure. Do not approve production use based on an endpoint that answers every request with allow.
A tool-call verdict covers the entire supplied frame. The tool frame contains the latest assistant message, rather than the full prior conversation, and has its own request identifier. Build the policy around the evidence actually supplied. Tool names alone do not establish destination authority. Keep resource authorization in the connector or downstream system.
Run a small acceptance suite#
Use synthetic records, a test recipient, and a tool that cannot send to real customers. Write expected outcomes before running the checks. Preserve client observations and downstream records separately from the security server's verdict log.
- Send an allowed report request. Confirm the endpoint received it and the user received the expected response. This catches a deny-everything configuration.
- Submit a synthetic value that your policy deliberately rejects. Confirm a valid deny reached Claude and stopped the request. Then submit an ordinary allowed request in a fresh conversation to check recovery.
- Request a send to the test destination your policy forbids. Confirm a tool-call frame arrived and the downstream system recorded no send. A blocked tool result after a send would be too late for this requirement.
- In the isolated pilot, make the endpoint exceed the configured timeout. Verify the chosen failure behavior from the client. Repeat with an invalid verdict response to exercise a different integration failure.
- Repeat the relevant cases for each client and role included in the rollout. Save exceptions with an owner and a reason; do not extrapolate one Cowork result to every Enterprise workflow.
Record the policy version, configuration, test case, observed verdict, client outcome, and downstream effect. Use a mismatch to narrow the investigation: did the frame arrive, did the policy decide correctly, did Claude receive the verdict, and did the action use an inspected path?
Plan for lost inspection and recovery#
Repeated endpoint failures can trip Anthropic's circuit breaker. The operational documentation says failure handling then applies without contacting the endpoint. A trip can appear in the Activity Feed when the Compliance API is enabled, but the tripped window has no per-request hook activities.
Alert on both the trip and missing expected traffic at your endpoint. Preserve when the gap began, the active failure policy, and the affected workflows. Absence of denial records during that window does not establish that requests were allowed by policy.
After repairing the endpoint, have the owner confirm enforcement and rerun one allowed case and one denied case. Retain evidence of restored inspection. Use the Compliance API collection guide for the audit trail, while keeping the endpoint's own decision records and downstream action evidence.
Prepare support for repeated policy blocks too. Claude sends prior conversation content again: a clean follow-up can still carry the rejected material. Anthropic documents editing or removing the denied content, or starting a new conversation or task. Check attachments before treating a repeated denial as a policy defect.
