The Monitor Reaches the Tool Call

Between August 19 and September 3, 2026, Anthropic and OpenAI each published how they monitor frontier models for enterprise customers, and one has since documented the mechanism in its integration guidance.^1,2,3,4,5,6 The coverage that followed settled on custody: monitoring data stays in the customer’s cloud, under the customer’s keys. That is accurate, and it is where both architectures agree rather than where they part. Our observation is that the consequential difference sits one layer down, at the tool call, and it becomes visible only when the disclosures are read against each other.

What both architectures establish

Anthropic’s Enterprise Frontier Safeguards writes activity data used for monitoring into the customer’s own cloud account — Amazon S3, Azure Blob Storage, or Google Cloud Storage — under the customer’s encryption keys, access policies, and audit logging.¹ OpenAI’s Private Safety Processing operates over customer content on infrastructure the customer controls, which is the arrangement for zero-data-retention deployments; a second option, in which content sits in OpenAI-provided storage encrypted under keys the customer holds and of which OpenAI personnel have no copy, is described as under development.² Stated precisely, one topology is the shipped arrangement and the other is a stated direction. Custody is nonetheless the shared floor.

Alert delivery is close to shared as well. Under EFS, automated systems analyze a rolling window of traffic for signals of serious misuse — attempts to develop offensive cyber or biological capabilities, and signs of stolen or leaked credentials — and those flags go directly to the customer, with no human review by Anthropic employees required.¹ Under PSP, the customer receives the alert, and OpenAI additionally receives a narrowly defined signal indicating the type of activity involved, which can be used to determine whether enforcement is necessary; customers investigate alerts and enforcement decisions using information in their own systems, and may choose to share content if they want to appeal or support an investigation.²

That is one real asymmetry: one architecture documents a signal returning to the provider and an enforcement decision attaching to it; the other does not describe one. Stated precisely, this is an asymmetry in what has been disclosed. Neither page establishes what the other provider does or does not retain, and the dispatch does not resolve it.

Both instruments share something else. Each is a detection architecture operating over traffic. Where detection works the way EFS describes it — a rolling window analyzed for patterns and correlated across sessions and accounts — the window is retrospective by construction, and our reading is that the flag names activity the harness has already executed. Neither disclosure specifies detection latency relative to tool execution, so the general timing claim is ours rather than the vendors’. What is not in question is the instrument’s position: it governs the seam above the harness, and it produces a flag rather than a refusal.

The layer that differs

Both providers ship real-time blocking to production customers already. Anthropic states that its generally released models ship with safeguards including classifiers that run over Claude’s inputs and outputs in real time to block prohibited cyber activity, such as malware development or offensive exploit writing.³ That is preventive, in production, and it is not what this dispatch is about. It is scoped to content: what the model is asked to produce, and what it produces.

The control at issue inspects something else — the model’s conduct inside its environment — and intervenes at a different point.

Anthropic deployed a classifier that identifies in real time when a model attempts to aggressively probe or escape a testing environment, or unexpectedly obtains internet access. When the classifier flags such an attempt, it blocks the action before the tool call is run, ends the task, and alerts a human.³ A modified version now runs inside reinforcement learning environments. The company states it verified this classifier would have flagged the incidents reported on July 30, in which Claude models running without cyber safeguards for evaluation purposes gained unauthorized access to real computer systems through a misconfiguration in a third-party environment.³

That control comes with a stated scope. The best-practice package Anthropic asks external partners to adopt applies where partners run cyber-related evaluations using their own harnesses, sandboxes, or agents, and the announcement is explicit that these practices do not apply to customers using safeguarded models like Claude Fable 5.³

OpenAI describes the same class of control in the opposite deployment. For Astra-class models it is deploying misalignment monitoring in production — a system of classifiers that check the model’s reasoning and actions for unauthorized behavior and automatically stop potentially unauthorized activity — and characterizes these safeguards as resembling its monitoring for internal deployments.⁴ The model has since been released, and the accompanying system card states the coverage: misalignment monitoring has been added to all tool-using inference involved in Astra’s external deployment, and the monitor used in production is a full-context monitor that sees inputs, chain of thought, tool-call actions, and tool-call outputs.⁵

Same control class, disclosed at two deployment altitudes and at two levels of precision. Anthropic specifies the insertion point: the classifier blocks the action before the tool call is run.³ That classifier is described in evaluation and training environments, with the accompanying partner practices stated as not applying to customers on safeguarded models. OpenAI specifies the deployment and, in the system card, the coverage: misalignment monitoring has been added to all tool-using inference involved in Astra’s external deployment, and the production monitor is a full-context monitor with access to inputs, chain of thought, tool-call actions, and tool-call outputs.^4,5 Both the system card and the integration documentation state the timing. The system reviews the agent’s chain of thought alongside its actions and the conversation’s inputs and outputs, and monitoring runs asynchronously, alongside the agent’s work; when it detects a potentially high-severity issue it can automatically pause or end the affected conversation.^5,6 The system card puts the consequence in one sentence: the monitor may miss misaligned behavior, and harmful actions can occur before it intervenes.⁵ The documentation adds that a stopped request does not undo earlier actions.⁶

Set side by side, the two are documented at different points in the same sequence. Content-scoped blocking is common ground in production. A conduct-scoped control with a disclosed pre-execution insertion point is documented by one provider, in evaluation and training environments. A conduct-scoped control reaching the customer’s production execution path is documented by the other, and documented as asynchronous. Nowhere in the sources is a conduct-scoped, pre-tool-call block documented as running in a customer’s production environment.

Coverage and intervention capabilities depend on the product interface, and both documents say so.^5,6 Responses API requests carrying persistent chain of thought or a WebSocket connection are monitored, and further execution can be blocked. Requests using neither are still monitored and can generate webhook alerts, but because they are stateless and lack persistent conversation identifiers, the system cannot connect them into a complete trajectory or automatically pause the conversation.⁵ Configuring an alert webhook does not enable automatic stopping.⁶ Chat Completions requests are excluded from this monitoring system, because that interface does not allow the model to reason and use tools at the same time; other safety checks still apply.^5,6

So the provider tier does prevent: it can block further execution, and it can block a request before streaming begins. What it is not is deterministic at the write boundary. It observes the trajectory asynchronously and halts what follows, without a stated guarantee of intervening before any particular consequential tool call. Stated precisely, an enterprise reading these documents learns that the same deployment can be covered-and-stoppable, covered-but-alert-only, or uncovered, depending on which API surface and which context mechanism a given call uses.

What that means where the enterprise stands

OpenAI states the operational consequence directly. If the misalignment monitor pauses a task, users in ChatGPT or Codex may be asked to review the action before continuing; on the API, the task stops. The disclosure notes that the system may occasionally flag legitimate activity, and that extra safety checks can slow, pause, or stop legitimate work, including defensive cybersecurity and tasks in which an agent runs for an extended period.⁴

Read against the client-side precedence stack, this is a new tier. Managed deny is the unoverridable floor the enterprise sets, the blocking hook is the programmable tier beneath it, allow rules follow, and the sandbox sits under all of it. A provider-side control that can stop the task in that path sits above that floor. The enterprise did not author it and does not control its calibration or its false-positive rate. Whether it can be continued past depends on the surface: on the API the task stops, while in ChatGPT or Codex the user may be asked to review the action before continuing.⁴ A review prompt is a continuation path; it is not an override, and it is not available everywhere.

For a regulated deployment, this reaches beyond safety posture into availability. On some product surfaces a user can review an explanation and the agent’s actions and decide whether it is safe to resume, with monitoring remaining active if they do; some conversations, including those stopped through the API, cannot be resumed.⁵ A blocked request returns an HTTP 403 with a misalignment policy violation code, and the API provides no general way to resume a conversation stopped by this monitoring.⁶ An enterprise that has committed a processing window to its own customers, or an operational recovery time to its risk committee, now has a stop condition in the path that its architecture did not write, its runbook does not describe, and its retry logic cannot clear. That is an obligation to reconcile, not a defect to litigate — and reconciling it starts with knowing the tier is there.

The stop is also not a rollback. The guidance is explicit that a stopped request does not undo earlier actions, and that where the alert’s paused field is true, a safety block was registered — which does not confirm that execution stopped or that earlier actions were reversed.⁶ Reconciliation against what the harness actually executed stays with the enterprise, and so does compensating action.

The absence is an architectural fact of the same kind. Where the provider ships detection and routes the flag to the customer’s own cleared reviewers, the enterprise holds disposition, and it also holds everything that comes before disposition. It staffs the queue. It correlates the flag against what its harness actually executed. It owns the interval between the write and the alert. Anthropic charges nothing for EFS; the cloud provider bills for storage, reads, writes, and egress as it would for any resource.¹ The staffed, cleared review function is the cost that appears in no line item.

Where enforcement is available to the enterprise

The controls that bind at the write path are the ones the deployment already owns, and the specification for them is now public. Anthropic’s guidance for evaluation partners reads as a write-boundary checklist: run inside a hardened sandbox with no internet access and the model’s API as the only permitted outside connection, with API keys kept outside the environment and the configuration verified before every run; have the model probe the sandbox and attempt escape under close human supervision before evaluations begin; confirm the task is solvable, since an agent facing an impossible objective will look for other routes; and run continuous monitoring over the model’s thinking, actions, and network activity against a monitor that has been given the scope of the exercise, ending the exercise when scope is violated.³

The alert itself is bounded as evidence, and the vendor says so. The system card states that the monitoring preserves existing data privacy protections including zero-data-retention commitments, and that as a result detailed explanations of a decision to pause or end a conversation are not available in every case.⁵ The integration guidance is more specific: alert delivery and retrieval do not provide a complete audit history, the alert’s reason field can be null — including for zero-data-retention requests — and a non-null reason is a category description rather than a transcript or a full investigation report.⁶ It also tells developers that monitoring can miss issues or flag legitimate activity, and to continue using application safeguards including human approval for consequential actions.⁶ That is the provider stating, in its own integration guidance, that its tier does not discharge the enterprise’s write-boundary obligations.

One line in that package generalizes further than its scope. Boundaries should be phrased as instructions — the example given is “You should not access the internet” — rather than as claims about the environment, such as “You do not have internet access.”³ Anthropic traces this to what happened: Claude was told it had no internet access while the internet was in fact available, which may have contributed to the model questioning whether the systems it encountered were real.³ A claim about the environment is falsifiable by the environment. An instruction is not. That distinction belongs in every system prompt that scopes an agent, and it costs nothing to adopt.