# Action screening and model safeguards are different layers

How Opus 5.5's action screening, sandbox and model safeguards form separate layers with different evidence and recovery obligations.

Author: Retrivium editorial team
Language: en
Analysis published: 2026-11-03
Event date: 2026-09-22
Original announcement: https://www.anthropic.com/claude-opus-5-5
Canonical URL: https://retrivium.ai/retrospectives/opus55-action-screening-vs-model-policy/

## The launch described more than model behavior

[Opus 5's release record dates to July 24, 2026](https://platform.claude.com/docs/en/models/opus-5/overview). The [September 1 Fable and Mythos release](https://www.anthropic.com/claude-fable-and-mythos-5-1) preceded [Opus 5.5's September 22 announcement](https://www.anthropic.com/claude-opus-5-5), which described action screening and a sandbox alongside model safeguards. These belong to different layers. A model can propose an operation, an external check can assess it, and an execution boundary can limit its effects. Combining the layers into one claim that a model is safe obscures which mechanism produced a particular outcome.

## A good proposal and an enforced boundary differ

An illustrative coding assistant may correctly decide that a task does not require writing outside its assigned directory. That is desirable behavior. A system boundary that prevents such a write even after an incorrect proposal provides a different kind of protection. Neither observation proves the other. A review should therefore record both what was proposed and what could actually execute. Otherwise, a blocked operation can be misreported as flawless model judgment, or a harmless proposal can be treated as proof that no external boundary is needed.

## Screening needs interpretable outcomes

A proposed action might be allowed, rejected or returned for clarification. These outcomes should remain distinguishable from an execution failure such as an unavailable application. If an agent repeatedly retries a rejected action without changing its understanding, the screening layer may prevent the immediate consequence while the workflow still fails to progress appropriately. That is a useful diagnostic distinction. It does not justify disabling the control; it identifies a coordination problem between the model's plan, the check and the application that handles the result.

## A harmless fixture can inspect the layers

A practical illustrative test uses a temporary workspace containing an allowed document and a clearly out-of-scope target. The task requires only reading the allowed document. Review the proposed operations, screening decisions and resulting files without attempting destructive behavior. If the agent requests an unnecessary write, the record explains whether it was rejected and whether the agent recovered sensibly. This is a proposed controlled fixture, not an observed Opus result. It keeps the acceptance question concrete while avoiding unsupported claims of universal resistance or perfect enforcement.

## Responsibility stays distributed

The release is significant because agent reliability depends on a system of mechanisms rather than a model label alone. Better model behavior can reduce problematic proposals; screening and execution limits can address consequences when proposals are wrong. Their interaction still needs evaluation in the actual harness. The retrospective conclusion is to attribute each observed protection to the layer that supplied it and preserve the evidence of recovery. That produces a more useful account than treating every successful restriction as interchangeable proof of one broad safety claim.

## Related reading

- [Tool proposal and execution](/journal/openrouter-tool-calling/)
- [Attributing decisions to layers](/journal/provider-request-id-trace-context/)