Security Overview

Sovereign is designed for deployment in security-conscious environments — from commercial SaaS to defense and aerospace. This page summarizes the platform's security posture. See the sub-pages for details on Data Protection and Authorization & Compliance.

Authentication

All API access requires authentication. The platform supports the following modes today:

• Bypass — no end-user authentication enforced. Intended for air-gap, single-operator, or pre-IdP production deployments. Not appropriate for multi-user deployments. Service-to-service calls remain authenticated via service keys.
• Local — built-in admin account with password authentication.
• OIDC — federated authentication via your corporate identity provider (Okta, Azure AD, Google Workspace, Keycloak, and others)

For commercial multi-user deployments, OIDC mode is recommended. See Authentication Setup for configuration details.

Federation for Air-Gapped and High-Side Environments [v1]

Classified and other air-gapped facilities typically cannot reach the Internet-discovery endpoints that OIDC deployments rely on. The platform's federation support targets these environments:

• SAML federation [v1] — assertion-based federation with on-premises identity providers (ADFS, Keycloak, Shibboleth). No Internet egress required; metadata exchange can be performed manually.
• LDAP / Active Directory [v1] — on-premises directory binding, including bridge configurations where AD fronts SAML for downstream federation.
• PIV / CAC smartcard [v1] — X.509 client-certificate authentication for U.S. federal civilian (PIV) and DoD (CAC) environments. Certificate identity is extracted at TLS termination on the reverse proxy and mapped to platform users; OCSP/CRL revocation checking is enforced per session.

These modes will ship with v1. See Authorization & Compliance for advanced authorization features also committed to v1.

Network Isolation

The deployment architecture provides multiple layers of network isolation:

• Auth database — runs on a dedicated database instance with no external port exposure. Only the Auth Service can access it over an isolated network.
• Application database — accessible to application services but isolated from the auth network.
• Service-to-service communication — authenticated via service keys. Internal endpoints are not exposed through the reverse proxy.

Tenant Data Isolation

All data is scoped to tenants at every layer:

• Workflow definitions, executions, configurations, and schedules are tenant-scoped
• The orchestrator validates tenant context before dispatching any steps
• Cross-tenant data access is prevented at the query level
• Connection ownership is verified on every credential operation

Rate Limiting

Authentication endpoints are protected with rate limiting to prevent brute-force attacks:

• Strict limits on credential endpoints (login, token exchange)
• Relaxed limits on metadata endpoints (JWKS, discovery)
• Configurable thresholds per environment

Production Security Checklist

1. Change all default passwords and service keys
2. Enable TLS on all public-facing endpoints
3. Configure OIDC mode for authentication (not Bypass or Local)
4. Use a dedicated key management service for encryption keys
5. Restrict database network access (no exposed ports)
6. Configure TLS for the message queue
7. Enable audit logging (requires audit capability in your license)
8. Implement regular backup procedures
9. Monitor health check endpoints
10. Rotate service keys and encryption keys on a regular schedule

Next Steps

• Data Protection — credential encryption, message queue security, license enforcement
• Authorization & Compliance — RBAC, audit logging, and the defense-grade authorization system coming in beta
• Authentication Setup — configure your authentication mode
• Deployment Guide — production deployment with security hardening