Skip to content

Security & Compliance

Overwatch is designed with security as a foundational requirement. This page covers the platform’s security architecture, authentication mechanisms, data isolation model, and compliance features.

User sessions are authenticated using JSON Web Tokens (JWT):

  • Access tokens expire after 1 hour
  • Refresh tokens are valid for 7 days
  • Tokens are delivered via httpOnly cookies (preferred) or Authorization: Bearer headers
  • Token revocation is tracked in Redis for immediate invalidation on logout

Long-lived API keys are available for service-to-service integrations:

  • Created and managed through Settings > API Keys or the /api-keys endpoint
  • Each key can be scoped to specific permissions (e.g., incidents:read, webhooks:write)
  • Keys are hashed before storage and cannot be retrieved after creation
  • Revoke keys immediately from the Settings page if compromised
  • Passwords are hashed using bcrypt with automatic salting
  • Minimum password requirements are enforced at registration and password change
  • Password reset tokens expire after 1 hour and are single-use

Overwatch implements progressive account lockout to prevent brute-force attacks:

SettingDefaultDescription
Max failed attempts5Attempts before account is locked
Initial lockout duration15 minutesFirst lockout period
Progressive lockoutEnabledDuration increases on repeated lockouts
Maximum lockout duration24 hoursUpper limit for progressive lockout
IP trackingEnabledTracks failed attempts per IP address
IP lockout threshold10Locks IP after this many failures across accounts

Administrators can manually unlock accounts from Settings > Users.

Every database query is automatically scoped to the requesting user’s organization through middleware:

  • All API responses only include data belonging to the user’s organization
  • Cross-organization access is blocked at the middleware layer
  • Organization ID is derived from the authenticated JWT token, not from user input
  • No API endpoint allows querying across organization boundaries

Each organization has its own namespace in the Weaviate vector database:

  • Semantic search results are scoped to the organization’s namespace
  • Incident embeddings, resolution vectors, and cached queries are isolated
  • No data leaks between organizations during search or AI operations

Session data, rate limits, and cached values are keyed by organization:

  • Account lockout tracking is per-organization
  • Semantic cache entries are organization-scoped
  • Rate limit counters are per-user and per-organization

Rate limits protect the API from abuse:

ScopeLimit
Interactive users1,000 requests/hour
API keys5,000 requests/hour
Webhook endpoints10,000 requests/hour
AI search queries500/hour

Rate limit headers (X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset) are included in every response. Exceeding limits returns 429 Too Many Requests.

Inbound webhooks support signature validation:

  • HMAC-SHA256 signatures verify that webhook payloads originate from the expected monitoring platform
  • Each integration can configure a shared secret for signature verification
  • Signature validation is optional but recommended for production deployments
  • Platform-specific headers are supported: X-Datadog-Signature, X-PagerDuty-Signature, X-Grafana-Alerting-Signature, X-NewRelic-Signature, X-SigNoz-Signature, X-ES-Signature
  • CORS is configured to allow only the Overwatch frontend origin
  • X-Request-ID headers are included in responses for request tracing
  • Security headers are set via middleware (content type enforcement, XSS protection)
  • In transit: All communication uses TLS 1.2+ (HTTPS enforced)
  • At rest: Database storage uses AWS RDS encryption with AES-256
  • Secrets: Credentials are stored in AWS Secrets Manager, not in application code or environment variables

Production credentials are rotated automatically:

  • RDS database passwords are rotated on schedule via Lambda
  • Redis authentication tokens are rotated without service interruption
  • Rotation is managed through the credential rotation system
  • Rotation events are logged for audit purposes

When incident data is processed by external LLMs:

  • Personally identifiable information (PII) is scrubbed before sending to AI models
  • IP addresses, hostnames, and account identifiers are anonymized
  • The anonymization service runs as a preprocessing step in the LLM pipeline

All significant actions are recorded in the audit log:

  • User authentication events (login, logout, failed attempts, lockouts)
  • Resource modifications (incidents created/updated, procedures executed)
  • Administrative actions (user role changes, integration configuration)
  • API key creation and revocation

Access audit logs from the Admin section of the dashboard or via the /audit API endpoint. Logs include the acting user, action type, target resource, timestamp, and IP address.

Overwatch uses RBAC with four built-in roles:

RoleKey Permissions
OwnerFull access including billing, organization deletion, user management
AdminUser management, integration configuration, all operational permissions
EngineerCreate/manage incidents, execute procedures, use AI features
ViewerRead-only access to incidents, procedures, and analytics

Permissions follow the resource:action format (e.g., incidents:create, procedures:execute). API keys can be scoped to any subset of these permissions.

For detailed role configuration, see Role-Based Access Control.

  • Enable webhook signatures for all production integrations
  • Use API keys with minimal scopes — grant only the permissions each service needs
  • Review audit logs regularly — check for unexpected access patterns
  • Rotate credentials — use the automated rotation system for database and cache credentials
  • Enable SSO — centralize authentication through your identity provider for better control
  • Set AI budget limits — prevent unexpected LLM costs by configuring monthly spending caps