Organization settings

Organization settings are the org-wide configuration of your Watcher deployment, managed on the Analyzer's Organization page. They are server-side and apply to everyone in the organization. Client behavior, such as blocking review thresholds and enforcement mode, resolves on each developer's machine instead, in the Watcher client's settings; admins can distribute and lock those centrally too, via managed client settings below.

The Organization page is visible only to users allowed to read organization settings, and only users with the admin role can edit them; other members do not see the page. How a user gets the admin role depends on your deployment's authentication mode: in proxy mode it comes from the role header your reverse proxy injects, in WorkOS-backed SSO mode from the role assigned to the member.

Settings

• Display name. The organization name shown across the dashboard and in notifications.
• Flag threshold. Sessions scored at or above this number are flagged for review. The default is 7. A session is flagged when any numeric score in one of its grades reaches the threshold; blocking-review decisions whose score reaches it are alerted on as well.
• Slack notifications. An on/off toggle plus an incoming-webhook URL for the channel that receives flag alerts. When a session is flagged, Watcher sends at most one notification for it, carrying the grader's summary, the flagged scores, and a link back to your Analyzer, not the session transcript. Flagged blocking-review decisions are alerted individually as they happen, and each of those alerts also includes the permission request that was under review: the tool name, its arguments, and the working directory. The webhook URL is write-only: after saving, the page shows only that a webhook is configured and the URL's last four characters. The URL must use https:// and must not include a username or a port. Notifications are sent only when the toggle is on and a webhook is configured.

Data retention

The Data Retention tab controls how long Watcher stores session content. By default, automatic retention is disabled and session content is retained indefinitely.

Turn on Scrub inactive sessions to automatically remove content from sessions after their latest recorded activity is between 7 and 365 days old. Turning the policy off retains future session content indefinitely. It does not restore content that has already been scrubbed.

Scrub one session removes the stored messages and tool-call content for a specific session after confirmation. The session record, historical activity, message count, and trajectory grades remain available. See Retention and deletion for the complete data lifecycle.

The same controls are available through the HTTP API. Set or disable automatic retention with PATCH /api/v1/organization/settings:

{
  "session_content_retention_days": 30
}

Set session_content_retention_days to null to disable the policy. Scrub one session with DELETE /api/v1/sessions/{session_id}/content.

Managed client settings

The Managed Settings page lets admins author the organization's Watcher client configuration once and distribute it to every developer machine. The document is a YAML overlay on the client's built-in defaults and can carry any client review setting: which graders run at each stage of blocking and trailing review, tool thresholds, command rules, and the enforcement mode.

Every save is kept as a new version. How a save reaches machines is the page's "Distribute via Watcher" toggle, inside its "Advanced settings" section:

• Toggle on (the default for new organizations): each running client pulls the saved document every few minutes and installs it as the machine's admin settings baseline. Saving is what rolls a change out, so review the document before you save it.
• Toggle off: Watcher distributes nothing. Ship the saved YAML to ~/.apollo_monitor/settings.yaml on each machine with your MDM tooling instead; the document works identically however it is delivered.

Organizations that predate this default keep the setting they already have, so one that has been distributing through an MDM stays that way. Turning the toggle on hands the whole fleet the document currently saved, so read it first. Until an organization saves its first document the toggle changes nothing: with nothing to pull, clients keep the settings file they already have.

Individual values can be marked locked, which prevents the developer's local settings from overriding them; unlocked values remain local defaults the developer can change. Reading the document requires permission to read organization settings, and saving it requires write permission.

The document also covers profiles: an entry in its profiles map carries that profile's configuration, so per-profile overrides (say, stricter thresholds under a focus profile) roll out through the same single document. active_profile picks the machine default and can be locked to pin every machine to one profile, as this example does with the profile it defines. Add content_permission: locked to an entry to lock everything that profile sets in one line. For the three built-in profiles the page offers, Default, Human in the Loop, and Auto, its "Active profile" control above "Advanced settings" sets active_profile directly, without editing YAML.

version: 1
active_profile:
  value: focus
  permission: locked
profiles:
  focus:
    name: Focus
    tool_thresholds:
      Bash:
        flag_threshold: 2
        deny_threshold: 5

Red-team drill

The page also offers a downloadable red-team drill: a prompt written for an AI assistant running on a developer's machine, carrying the document above, how it is distributed, and the settings reference. Send it to a developer who has the client installed. Their assistant checks the install, then works out the smallest change to that one machine that gets an ordinary command held for review: turning enforcement on if it is not already, and lowering a tool's flag threshold if the organization's own is too high to hold anything ordinary. It then asks which threats the team cares about, probes each one against the organization's real thresholds, and restores the machine.

What the drill can change on a machine is bounded by the document. A setting the document locks cannot be overridden from the machine at all, and the drill is written to report that rather than route around it: it names the locked key and asks an administrator to unlock it here, which leaves every machine's behavior as it is and only restores their latitude to override. If nothing can be unlocked in time, the drill runs its threat probes without the demonstration.

In observe mode nothing is ever blocked, so a team running one cannot see what blocking review does without turning enforcement on somewhere. The drill does that on one machine instead of the fleet. Its configuration changes are local and are reverted at the end; the session itself, probes included, is ingested and visible in the Analyzer like any other. Containment is instruction, not sandboxing: the prompt tells the assistant to keep every probe inside a scratch directory and to use dummy credentials, and an assistant that departs from it is not prevented by Watcher.

Members

The Members tab lists the organization's users. In WorkOS-backed SSO mode, admins manage members and their roles here. In proxy mode the roster is read-only: membership and roles are managed by your identity provider and reverse proxy, and users appear after their first sign-in.

API keys

In WorkOS-backed SSO mode, the API Keys tab is where you create and revoke the organization's API keys for the HTTP API and the Python SDK. In proxy mode there is no API Keys tab; API access is governed by your reverse proxy.