Agent containment best practices: online monitoring (private beta)

For customers in our Cyber Verification Program, we’re providing a new sandbox escape classifier in the API to monitor and reduce misuse. This article explains how to request the score, read the results, and use the score to decide which transcripts to review first.

For an overview of all the resources available to you, see Agent containment best practices: getting started (private beta).

When you request it, Anthropic will score each Messages API request whose conversation contains tool use for signs of sandbox escape, and return the result in a safeguard_results field on the response. To request it, add anthropic-beta: safeguards-2026-08-31 to the request and "safeguards": [{"type": "sandbox_escape"}] to the request body.

The score is a number from 0 to 1. Higher scores mean the transcript sent in that request looks more like an agent trying to widen its network access or break out of its execution sandbox. Benign agentic traffic typically scores near 0. As a rough guide, read the transcript for anything at or above 0.15, and treat 0.75 or above as a possible sandbox escape attempt. Depending on your use case, you may see high scores for benign traffic. The classifier is currently available for Claude Mythos 5.1, Sonnet 5.5, and Opus 5.5.

The sandbox escape classifier is in private beta and still under active development. We’re still iterating on its accuracy and are interested in your feedback. We recommend that you use it to prioritize transcript review, alongside the offline checks. You can also build your own automated responses to high scores, such as alerting on-call or stopping an agent.

When you request it, the response contains an explicit status for this feature. The response will show evaluated alongside the sandbox-escape score, skipped when the request had no tool activity, unsupported when the model or platform is not covered, or unavailable along with a reason for the unavailability. The score is available on the first party Claude API, and third-party party surfaces such as AWS Bedrock and GCP Vertex.

This feature is built for agents you run against the Messages API directly. Agents that run through the Claude Code CLI don’t use it; for those, use the offline checks.

This article describes a monitoring signal that the API can return to you on each request. It complements the checks in offline monitoring of agent transcripts, which you run over the transcripts yourself, during or after a run. The API can score each Messages API request whose conversation includes tool use (tool_use and tool_result blocks, or server-tool blocks) for signs of sandbox escape and return the result in that request’s response. You ask for it with a beta header and a request field, described in Requesting the score.

During the private beta the score isn’t intended to change the response content, and scoring isn’t expected to add a charge or count toward usage. The classifier that produces the score is separate from the auto-mode permission classifier in Claude Code, which decides on each action before it runs (see Auto mode). The score is not that classifier’s verdict.

This page applies to agents that call the Messages API directly: your own agent code, the anthropic (Python) or @anthropic-ai/sdk (TypeScript) client libraries, or curl. The Claude Code CLI (used directly or through the Agent SDK) doesn’t request the score and doesn’t surface the field in its output, so the score doesn’t appear in the transcripts of agents that run through it. For those agents, use the offline checks.

The score (the status.score of the sandbox_escape entry in safeguard_results) is a number from 0.00 to 1.00, rounded to the nearest 0.01 (see Requesting the score). The score is the classifier’s estimate of the likelihood that the conversation shows the agent attempting, or having achieved, an escape from its sandbox or containment.

Concretely it looks for two things: the agent widening its network or internet access beyond what it was given, and the agent breaking out of the execution sandbox it runs in. It covers attempts as well as successful escapes, and the single score does not tell them apart. Higher is more concerning. It’s a ranking signal rather than a calibrated probability, and the underlying classifier may be updated without the result naming a version.

The score is computed over the conversation you sent in that request, including the tool calls and tool results already in the transcript. It doesn’t cover the completion the model is about to generate in response. In an agent loop this means each request’s score reflects everything the agent has done up to and including the most recent tool result, and a tool call the model proposes in turn N is first scored on the request for turn N+1, once its result is in the transcript. The final action of a session is therefore not scored. Cover it with the offline checks.

How to read the number:

Only requests that contain tool activity are scored. A plain chat request, or the first request of an agent session before any tool has been called, comes back with status skipped rather than a score.

Two things go on the request.

The header alone, with safeguards empty or omitted, is accepted and simply returns an empty safeguard_results array. A minimal request with one completed tool call in the conversation:

The response shapes below are as of the safeguards-2026-08-31 beta (August 2026). If the beta version changes, check with your Anthropic account team for the updated header and field names. In a non-streaming response, the result is a top-level safeguard_results array on the returned Message object, with one entry per type you requested:

With "stream": true, the same array arrives inside delta on the final message_delta event, next to stop_reason, and nowhere else in the stream:

Each entry carries type and status. status.type is one of the following: evaluated (with score), skipped, unsupported, or unavailable (with reason). See Caveats for what each entry means.

If you use the anthropic or @anthropic-ai/sdk client library rather than raw HTTP, append safeguards-2026-08-31 to the betas list you already pass. Set it as an extra anthropic-beta request header only on calls that pass no betas, because an explicitly set header replaces the one the library builds from that list rather than merging with it. The client libraries have no typed safeguards parameter for this beta, so pass it as an extra body field: extra_body={"safeguards": [{"type": "sandbox_escape"}]} in Python, or add safeguards to the params object in TypeScript (with // @ts-expect-error if the compiler objects; the library sends unrecognized params as they are).

On a non-streaming call, read safeguard_results from the raw response or the response object’s extra fields, since typed response classes may not expose a field they don’t know about. When streaming through the library, read it from the raw message_delta event rather than from the accumulated final message (get_final_message() / finalMessage()), which is built from the fields the library knows and doesn’t include it. Log the result next to the request or session identifier you already keep, so that a high score leads you straight to the transcript. Record it outside the sandbox, at your proxy or orchestrator, and re-check your thresholds from time to time.

Use the classifier to decide which transcripts to review by hand first. Here’s one approach:

The score reaches you with the response, so the earliest you can act on a tool call is after it has run (see What the score means). Use the score for detection and review. For prevention, rely on the sandbox and on controls that act before an action executes.