Sentinel Watch Backend

Sentinel Watch is implemented inside Verify as an organization-scoped recurring monitoring engine. Verify owns schedules, baselines, policies, history, and notifications; Apify runs the two initial evaluators.

Release surface

The feature is mounted only when both INTELLIGENCE_ENABLED=true and SENTINEL_WATCH_ENABLED=true.

Initial evaluator values:

• api_exposure calls the qualified api-exposure-diff Actor and passes the last successful normalized snapshot as its baseline.
• agent_readiness calls the qualified ai-agent-readiness Actor. That Actor must use VERIFY_CLIENT_ID and VERIFY_CLIENT_SECRET to obtain a short-lived verify:readiness token and call Verify's existing POST /v1/audits/readiness endpoint.

No readiness scoring is duplicated in Watch. The Actor's configured build ID must match the build that actually executes, and every Actor call is bounded by a timeout and maxTotalChargeUsd.

API

Watch routes use existing opaque Verify Intelligence API keys. Read operations require watch:read or watch:write; mutations require watch:write.

POST   /v1/watch
GET    /v1/watch
GET    /v1/watch/{watch_id}
PATCH  /v1/watch/{watch_id}
DELETE /v1/watch/{watch_id}
POST   /v1/watch/{watch_id}/run
GET    /v1/watch/{watch_id}/runs
GET    /v1/watch/{watch_id}/snapshots
GET    /v1/watch/{watch_id}/signals

Policies are managed below /v1/watch/policies. Collection endpoints accept an opaque cursor and a limit from 1 through 100.

Example creation request:

{
  "target": {"type": "domain", "value": "example.com"},
  "evaluator": "api_exposure",
  "cadence": "daily",
  "policyId": "optional-policy-id"
}

Only bare public domain names are accepted. Verify performs DNS/public-network validation during creation and immediately before each run. Targets, evaluators, and customer Apify credentials cannot be changed or supplied through the API.

Baselines and delivery

Only success snapshots become baselines. partial snapshots remain visible for diagnosis but never replace the last successful baseline or produce customer-facing signals. Initial success establishes the baseline without reporting every discovered item as a change.

The default policy notifies for medium-or-higher signals by email. Explicit policies can add deterministic allow/deny lists, per-signal delta thresholds, and webhook delivery where the plan permits it. Webhooks reuse Intelligence endpoint registrations subscribed to sentinel.watch.signal and include:

X-Sentinel-Event: sentinel.watch.signal
X-Sentinel-Delivery: <delivery id>
X-Sentinel-Signature-256: sha256=<HMAC-SHA256 of exact body>

Production activation

1. Deploy Verify with migration 0042_sentinel_watch while leaving SENTINEL_WATCH_ENABLED=false.
2. Deploy api-exposure-diff and ai-agent-readiness through the api-ify release workflow.
3. Configure the readiness Actor's VERIFY_BASE_URL, TOKEN_SERVICE_BASE_URL, VERIFY_CLIENT_ID, and VERIFY_CLIENT_SECRET; do not configure a new static VERIFY_API_KEY.
4. Qualify both Actors against controlled public domains and record their immutable build IDs.
5. Set the operator Apify token, Actor IDs/tags, approved build IDs, and spend ceiling in /etc/sentinel-signal/prod.env.
6. Enable Watch and restart verify-web, verify-scheduler, and the isolated verify-watch-worker.
7. Confirm the Watch routes, one baseline run for each evaluator, queue drain, signed webhook receipt, and the mcp_verify_watch_* metrics before enabling customer organizations.

Never print or commit production Apify, Verify client, Vault, API-key, or webhook secrets.