Server-managed security monitors for coding agents

Watcher now configures its built-in security monitors on the server. The change brings prompts, models, and conversation context under the release configuration for both Watcher Cloud and self-hosted deployments.

What's new?

• Built-in Triage and Gateway monitors use server-managed prompts and models for blocking review of tool calls.
• The server defines which conversation context each built-in monitor receives. Individual client settings no longer control that context or the built-in prompts.
• The server owns the Triage cutoff that determines which requests receive further review.
• Explicitly configured custom graders retain their own configuration.

Required upgrade steps

These steps apply when moving from 0.29.x or earlier to 0.30.0 or later. Target 0.30.1 or a later release, which corrects the Gateway model and permission-review escalation failures in 0.30.0. The model table below uses the corrected defaults.

Deployment	What you need to do
Watcher Cloud	Check whether your team relies on the client settings listed below. You do not need to configure provider keys, grant model access, or deploy server workloads.
Self-hosted	Check those client settings and verify access to the required models before upgrading the server. Configure the fallback below only if you cannot obtain that access.

All deployments: check custom monitoring settings

The following Watcher client settings no longer change the managed Triage and Gateway monitors:

• context_user_messages
• include_tool_outputs
• include_agent_reasoning
• include_triage_assessment
• triage_max_allow_score

If your team relies on these settings, review the server-managed behavior before updating clients. To preserve a custom prompt or context policy, use an explicit non-shipped grader ID in policy_monitors.policy_triage_grader_id or policy_monitors.policy_gateway_grader_id. An existing custom grader ID continues to use its custom configuration. Built-in grader IDs switch to managed monitoring automatically.

Self-hosted only: verify model access before upgrading

Grant the project behind each provider key access to the exact model. Provider access alone is not enough. These are the recommended models for the managed monitors:

Monitor	Model	Provider key
Triage	openai/gpt-5.6-luna	OPENAI_API_KEY
Gateway	anthropic/claude-opus-4-7	ANTHROPIC_API_KEY
Deep Review	anthropic/claude-sonnet-5	ANTHROPIC_API_KEY
Summaries	google/gemini-2.5-flash	GOOGLE_API_KEY

Before updating, make a test completion with each model your deployment uses, through the same credentials and network path the Watcher API workload will use. Deep Review and summaries require access when trailing review is enabled.

If access to Luna or Opus 4.7 is unavailable, you can retain the previous blocking-review models as an operator-configured fallback. This fallback is not the recommended or currently tested configuration and may reduce monitor performance. Merge this section into server-config.yaml, preserving any other configuration:

monitors:
  gateway:
    model: "anthropic/claude-sonnet-5"
  triage:
    model: "google/gemini-2.5-flash"

Verify provider access to those fallback models before proceeding. During the server upgrade, mount server-config.yaml read-only at /etc/watcher/server-config.yaml in the Watcher API workload. The server reads this file at startup, so restart or roll out the API workload after changing it.

These overrides change only the models. Managed prompts, context policy, and the Triage cutoff still apply. Follow Update the server for the deployment procedure.

After upgrading: verify blocking review

Start a watched coding-agent session and perform an action that requires blocking review. Confirm that its Triage or Gateway grade appears in the Analyzer.

Self-hosted operators must also check server logs for provider authentication, permission, or model-not-found errors, and complete Verify an update before rolling out to any remaining clients under their control.