Authentication — OIDC/PKCE

The platform uses OpenID Connect with PKCE as its sole authentication mechanism. No passwords are stored in the database. The login page auto-renders one SSO button per registered IdP config. Supported providers: Keycloak (bundled), Okta, Azure AD, Auth0, Ping Identity, Google Workspace.

bash

1curl -X POST https://sovereign.yourcompany.com/api/v1/idp/configs \
2  -H "Authorization: Bearer $ADMIN_TOKEN" \
3  -H "Content-Type: application/json" \
4  -d '{
5    "org_id": "acme-corp",
6    "display_name": "Sign in with Okta",
7    "oidc_issuer": "https://acme.okta.com/oauth2/default",
8    "workspace_ids": ["ws-acme-prod"]
9  }'

Role-Based Access Control

Roles are embedded in JWT claims. Multiple roles per user are supported.

Role	Capabilities
`admin`	All operations — user management, key rotation, IdP config
`ops`	Deploy models, approve HITL requests, manage clusters, IP allowlist
`legal`	Approve/reject GitOps manifests and HITL requests, view compliance reports
`dev`	Create/read models, run agents, write code, view audit log

SCIM 2.0 Provisioning

Automated user lifecycle management from your IdP's SCIM connector (Okta, Azure AD, etc.). SCIM DELETE is a soft-delete — users are set to status=revoked to preserve audit log integrity.

Endpoint	Description
`GET /api/scim/v2/Users`	List users (filterable by displayName, userName)
`POST /api/scim/v2/Users`	Provision a new user
`PATCH /api/scim/v2/Users/{id}`	Partial update (Operations list)
`DELETE /api/scim/v2/Users/{id}`	Soft-delete (status → revoked)
`GET /api/scim/v2/Groups`	List workspaces as SCIM groups

IP Allowlist

Per-workspace CIDR-based access control. Requests from disallowed IPs receive HTTP 403. Configure via the API or the Settings → Security page.

bash

Enable IP allowlist + add CIDR

1# Enable policy
2curl -X PUT https://sovereign.yourcompany.com/api/v1/workspaces/WS_ID/ip-policy \
3  -H "Authorization: Bearer $TOKEN" \
4  -d '{ "enabled": true }'
5
6# Add office CIDR
7curl -X POST https://sovereign.yourcompany.com/api/v1/workspaces/WS_ID/ip-allowlist \
8  -H "Authorization: Bearer $TOKEN" \
9  -H "Content-Type: application/json" \
10  -d '{ "cidr": "203.0.113.0/24", "description": "Corporate office" }'

Encryption & Key Management

Sensitive fields (LLM provider API keys, SCIM tokens, webhook secrets) are Fernet-encrypted at rest using a 32-byte key resolved from your chosen provider: env var (dev), Azure Key Vault (AKS), AWS Secrets Manager (EKS), or HashiCorp Vault (on-prem). Key rotation invalidates the cache and re-encrypts on next read.

bash

Rotate encryption key

1# Invalidate the in-memory key cache (forces re-fetch from KMS/Vault)
2curl -X POST https://sovereign.yourcompany.com/api/v1/admin/rotate-keys \
3  -H "Authorization: Bearer $ADMIN_TOKEN"
4
5# Verify key provider + cache age
6curl https://sovereign.yourcompany.com/api/v1/admin/key-status \
7  -H "Authorization: Bearer $ADMIN_TOKEN"

Immutable Audit Chain

Every write operation produces an audit entry with a SHA-256 hash chained to the previous entry. The chain can be verified at any time. A broken chain indicates tampering. Export the full log as CSV for external SIEM or legal review.

bash

Verify chain integrity

1# Verify from a specific entry back to genesis
2curl -X POST https://sovereign.yourcompany.com/api/v1/audit/verify/ENTRY_ID \
3  -H "Authorization: Bearer $TOKEN"
4# → { "chain_valid": true, "entries_verified": 2847 }
5
6# Export full audit log as CSV
7curl "https://sovereign.yourcompany.com/api/v1/audit/export/csv?workspace_id=WS_ID" \
8  -H "Authorization: Bearer $TOKEN" > audit-export.csv

Third-Party Penetration Testing

No third-party penetration test has been completed yet — and we would rather say so than publish an invented one. A grey-box engagement is scoped, covering the REST API and workspace isolation (IDOR), the LLM Gateway (direct/stored/indirect prompt injection and routing-rule bypass), authentication and JWT validation, SCIM provisioning, the admin surface, and audit-chain tamper detection. The assessment letter from a recognised firm will be published here once the test is complete. Enterprise security reviewers can request the engagement scope and our security questionnaire in the meantime.