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.
Authentication
Section titled “Authentication”JWT Bearer Tokens
Section titled “JWT Bearer Tokens”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: Bearerheaders - Token revocation is tracked in Redis for immediate invalidation on logout
API Keys
Section titled “API Keys”Long-lived API keys are available for service-to-service integrations:
- Created and managed through Settings > API Keys or the
/api-keysendpoint - 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
Password Security
Section titled “Password Security”- 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
Account Lockout
Section titled “Account Lockout”Overwatch implements progressive account lockout to prevent brute-force attacks:
| Setting | Default | Description |
|---|---|---|
| Max failed attempts | 5 | Attempts before account is locked |
| Initial lockout duration | 15 minutes | First lockout period |
| Progressive lockout | Enabled | Duration increases on repeated lockouts |
| Maximum lockout duration | 24 hours | Upper limit for progressive lockout |
| IP tracking | Enabled | Tracks failed attempts per IP address |
| IP lockout threshold | 10 | Locks IP after this many failures across accounts |
Administrators can manually unlock accounts from Settings > Users.
Multi-Tenant Data Isolation
Section titled “Multi-Tenant Data Isolation”Organization Scoping
Section titled “Organization Scoping”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
Vector Database Isolation
Section titled “Vector Database Isolation”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
Redis Isolation
Section titled “Redis Isolation”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
API Security
Section titled “API Security”Rate Limiting
Section titled “Rate Limiting”Rate limits protect the API from abuse:
| Scope | Limit |
|---|---|
| Interactive users | 1,000 requests/hour |
| API keys | 5,000 requests/hour |
| Webhook endpoints | 10,000 requests/hour |
| AI search queries | 500/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.
Webhook Security
Section titled “Webhook Security”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 and Headers
Section titled “CORS and Headers”- CORS is configured to allow only the Overwatch frontend origin
X-Request-IDheaders are included in responses for request tracing- Security headers are set via middleware (content type enforcement, XSS protection)
Data Security
Section titled “Data Security”Encryption
Section titled “Encryption”- 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
Credential Rotation
Section titled “Credential Rotation”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
Data Anonymization
Section titled “Data Anonymization”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
Audit Logging
Section titled “Audit Logging”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.
Role-Based Access Control
Section titled “Role-Based Access Control”Overwatch uses RBAC with four built-in roles:
| Role | Key Permissions |
|---|---|
| Owner | Full access including billing, organization deletion, user management |
| Admin | User management, integration configuration, all operational permissions |
| Engineer | Create/manage incidents, execute procedures, use AI features |
| Viewer | Read-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.
Security Best Practices
Section titled “Security Best Practices”- 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