Allow/deny checkpoint before the model runs

The security decision should happen before the model starts. A request denied by the security server did not reach Claude's model. The checkpoint sits between the user's request and inference, and when it says no, the user sees why. The pattern turns a security control into a product surface.

Put the checkpoint before inference

A governed prompt should not be judged after the model has already seen it. The decision point belongs before inference, where the request can be stopped before it becomes a model call. Anthropic offered Inference hooks in beta to Claude Enterprise organizations. Claude Enterprise organizations could send every governed prompt to an organization-operated AI security server before inference.

The feature relied on an open webhook protocol and a published schema, letting organizations connect existing data-loss-prevention servers from Netskope, Palo Alto Networks, Proofpoint, or Zscaler. The feature was unavailable on Amazon Bedrock and Google Cloud.

• Scope the governed traffic. Decide which prompts, tool results, users, and data classes must pass the checkpoint, then write a policy that names chat, agent actions, tool output, and any content that leaves the product.
• Point the product at a security webhook, so the request is sent to an organization-operated server before inference. The endpoint should receive the prompt payload and return a decision without changing the user's wording.
• Use an allow/deny schema over an open protocol, with a request and response contract that your security team can inspect in code review. The response should carry a machine-readable decision and a short human-readable explanation.
• Set a short timeout so the product fails in a safe, predictable way when the security server is slow or unavailable. The fallback should be a bounded wait, a safe decision, and an alert when the checkpoint degrades.
• Roll out from shadow to enforcing, starting with a phase that logs would-be denials and then switching gradually with a clear fallback.
• Show a user-visible deny reason in a payload that can be logged, tested, and shown to the user without exposing internal policy details.
• Keep an audit log that supports the user-facing reason.

Make denial explain itself

A deny screen should tell the user what happened, what was blocked, and what they can do next. The message should be calm, specific, and short. It should not scare the user, and it should not pretend the model still ran. The UI can say the stop plainly. The reason should be written for the person, not the auditor. This prompt contains a credential is better than policy violation. The reason can be generic enough to avoid leaking policy, but specific enough to guide the next action. If the user can retry, say what to change. If they cannot, say who to contact.

Tool results need the same treatment. The system inspected tool responses before returning them to Claude, covering tool calls made through MCP, skills, and plugins. The user may not see the tool response directly, but the product should still log the decision and, where appropriate, show a notice that a tool result was withheld.

Roll out from shadow to enforcement

Do not flip the checkpoint to enforcing immediately. Start in shadow mode: log what the security server would have denied, but let the request continue. Shadow mode gives the team a list of false positives without blocking users. Then enforce gradually, with a clear fallback if the checkpoint misbehaves.

Bandwidth's Andrew Grimmett, Vice President of Information Security, said the feature gave his team a real-time inspection point before Claude processed content. Before enforcement, the team should be able to answer the core questions: What did the checkpoint see? What did it decide? Why? The audit log should store the prompt or a safe reference to it, the decision, the reason, the timestamp, and the policy version. The log makes the reason defensible.