Skip to content
Docs

Configuration & Admin

AgentWatch is administered from a web console, with a small set of environment variables set at deploy time. The console covers everything an organization administrator needs; a platform-level super administrator additionally sees across organizations.

What is configured at deploy time?

Section titled “What is configured at deploy time?”

Environment variables covering the database connection, service ports, session and encryption secrets, credentials for any local analysis model, the detection-model size, and backup secrets. Everything else — providers, models, policies, budgets, routes, identity, and users — is runtime configuration managed in the console and stored in the database, so promoting between environments does not require a config-file diff.

What do administrators manage in the console?

Section titled “What do administrators manage in the console?”
  • Providers and keys — add providers, pool multiple keys each, set per-key concurrency and rate limits, test keys against the live provider, and schedule rotation.
  • Models — expose which models are available to which teams, set per-organization aliases, and retire models without breaking existing consumers.
  • Organizations, teams, and employees — the full hierarchy, with CSV bulk import, per-employee keys and budgets, and pause/resume of access.
  • Budgets and rate limits — four-tier budgets with daily and monthly caps, alert thresholds, and admin overrides with expiry.
  • DLP and guardrail policies — detection categories, custom recognizers, confidence thresholds, severity overrides, and per-policy actions.
  • Gateway routes — path patterns, upstream targets, transformations, timeouts, per-route authentication and allowlists, with import, export, clone, and reorder.
  • Compliance frameworks — select the frameworks that apply and have the matching controls and retention activate together.
  • Identity — SSO providers, group-to-team mapping, and SCIM provisioning.
  • Roles and permissions — named per-organization roles built from fine-grained permission keys.

How does identity administration work?

Section titled “How does identity administration work?”

A single hub-and-spoke wizard walks an administrator through vendor selection (Microsoft Entra ID, Okta, Google Workspace, Auth0, GitHub, generic OIDC, generic SAML, or Active Directory/LDAP), protocol setup, group-mapping mode, and a connection test before enabling. Drafts can be saved mid-configuration, and auto-create and enabled toggles are set per provider.

Group-to-team mapping is unified across OIDC, SAML, and LDAP, with three modes: off (users get a default role), automatic (directory group names are parsed by a rule and teams are created on the fly with a budget template), or mapped (administrator-defined group-to-team rules with role, budget template, and priority). Mappings apply at first login and update memberships on subsequent logins.

SCIM v2 provisioning is available per organization, with named tokens shown once, usage telemetry, expiry, and revocation — so joiner/mover/leaver flows are driven by the directory rather than by hand.

How granular are permissions?

Section titled “How granular are permissions?”

Roles run from platform super administrator through organization administrator to ordinary user, with named custom roles per organization built from individual permission keys. Scoping dimensions include user, team, organization, model, MCP server, individual tool, gateway route, guardrail policy, enrichment plugin, and schema — each independently grantable. So one team can hold read-only access to a single tool server while another has full invocation rights on a different one. Audit permissions are deliberately split: reading audit records is a separate grant from exporting them.

Section titled “Is there a recommended secure baseline?”

Yes. A hardened baseline preset is documented and can be applied at deploy time: all guardrails enabled, maximum audit retention, IP allowlisting on, mutual TLS required for endpoint agents, and external guardrail engines enabled. It is the recommended starting point for regulated deployments, from which exceptions are made deliberately rather than accumulated by default.

Can the platform be demonstrated before real keys are wired up?

Section titled “Can the platform be demonstrated before real keys are wired up?”

Yes. A demo mode — on by default for new installations and toggleable per user — populates every console surface with realistic generated data: employees, teams, providers, audit records, security events, session history, usage metrics, fleet health, insider-risk standings, and dashboards. Nothing is written to the database, so it is available the moment the image runs, and it can be disabled globally at install time for production.

What is the operational surface?

Section titled “What is the operational surface?”

A health endpoint for orchestrator and load-balancer probes; graceful shutdown that flushes in-flight work before closing; automatic schema application and backfill at boot so upgrades need no manual migration; self-healing that reaps stale jobs and re-probes tripped circuit breakers; and diagnostics endpoints for support investigations. Logs and data live on mounted volumes.

Sources and references

Section titled “Sources and references”