Misalignment monitoring

Misalignment monitoring checks whether an agent is properly interpreting the user’s instructions in consequential contexts, such as transferring sensitive data, accessing sensitive data, or making destructive changes. It reviews model reasoning and actions asynchronously and can stop a conversation when it identifies a potential issue.

A flag indicates that the agent’s actions need review. It does not establish that the user violated a policy or that the agent acted contrary to instructions. Monitoring can miss issues or flag legitimate activity, so continue to use application safeguards, including human approval for consequential actions.

For more context, see the misalignment monitoring overview in the Help Center.

Request coverage

For models covered by this system, monitoring and automatic stopping depend on the request’s API and how it preserves conversation context:

See preserving reasoning across calls, WebSocket mode, and compaction for conversation context guidance. Configuring an alert webhook does not enable automatic stopping.

Handle a stopped request

When misalignment monitoring blocks a request before streaming begins, the API returns HTTP 403, with error type invalid_request_error and code misalignment_policy_violation. Match the error code rather than the message text. Streaming integrations must also handle errors while consuming the stream, even after receiving output.

If your application receives this error:

1. Stop dispatching further actions for the affected conversation. Do not automatically retry the blocked workflow.
2. Preserve the relevant request and response IDs, tool calls, and application records according to your data handling policies.
3. Show the available error information to the user or operator responsible for the task. Have them compare the agent’s actions with the intended work and review any changes already made.

The API does not provide a general way to resume a conversation stopped by misalignment monitoring.

Because monitoring is asynchronous, an action may already have completed before monitoring identifies a concern. A stopped request does not undo earlier actions.

Receive project safety alerts

Subscribe to safety.alert.created to route monitoring alerts for an API project to a system your team operates. Receiving alerts does not replace handling errors on API requests.

Follow Creating webhook endpoints for each project whose alerts you want to receive. Use the Webhooks guide for signature verification, acknowledgments, retries, and duplicate deliveries.

The webhook contains an alert ID, rather than the alert details:

123456789{
  "object": "event",
  "id": "evt_123",
  "type": "safety.alert.created",
  "created_at": 1787659200,
  "data": {
    "id": "alert_0123456789abcdef0123456789abcdef"
  }
}

After verifying and acknowledging the webhook, retrieve the alert in your background processing. Set SAFETY_ALERT_ID to data.id, not the event’s id. Use an API key authorized for the same project with the api.safety.alerts.read permission:

curl "https://api.openai.com/v1/safety/alerts/${SAFETY_ALERT_ID}" \
  -H "Authorization: Bearer ${OPENAI_API_KEY}"

Use the returned request_id and response_id to find the affected work in your application records. Treat the alert category as a concern to investigate. When request_paused is true, registering a safety block succeeded; this does not confirm that execution stopped or that earlier actions were reversed. Check your application’s task state and tool records.

The alert’s reason can be null, including for Zero Data Retention (ZDR) requests. A non-null reason is a category description, not a transcript or full investigation report. Keep the records you need under your organization’s data policies. See Your data for API data controls.

If retrieval returns 404 with code safety_alert_not_found, check the alert ID and project credentials. Missing, inaccessible, or incomplete records can return this error. Alert delivery and retrieval do not provide a complete audit history.