Secrets Management¶

Executive Summary¶

Secrets Management defines how Algosure protects credentials, tokens, API keys, encryption keys, integration secrets, AI provider keys, database credentials, and signing material.

Why This Exists¶

Secrets are high-value attack targets. Algosure must prevent secrets from entering source code, logs, documents, analytics, AIOS prompts, support tickets, or client-accessible storage.

Owner¶

The owner is the Chief Product Officer and Enterprise Architect.

Business Value¶

Strong secrets management reduces breach risk, supports least privilege, enables rotation, and protects customer integrations and platform infrastructure.

Secrets Control Model¶

flowchart TB
    Secret[Secret]
    Store[Approved Secrets Store]
    Access[Least-Privilege Access]
    Runtime[Runtime Injection]
    Rotate[Rotation]
    Audit[Access Audit]

    Secret --> Store
    Store --> Access
    Access --> Runtime
    Store --> Rotate
    Access --> Audit
    Rotate --> Audit

Secret Categories¶

Category	Examples
Identity provider secrets	Keycloak client secrets, federation credentials, signing material.
Database secrets	PostgreSQL credentials, connection secrets, migration credentials.
Integration secrets	Gmail, Outlook, Google Drive, OneDrive, DocuSign, WhatsApp, SARS, CIPC, CSD, CIDB, COIDA, B-BBEE, marketplace, funding, payment provider credentials.
AI secrets	AI provider keys, gateway credentials, model provider tokens.
Encryption keys	Data encryption keys, document encryption keys, backup encryption material.
API keys	Internal service keys, external integration keys, webhook secrets.

Keycloak Secret Rules¶

Secret	Architecture Rule
Client secrets	Confidential Keycloak client secrets are stored only in approved secrets management and never in mobile or browser clients.
Service account credentials	Internal service credentials are least-privilege, environment-scoped, rotated, and audited.
Federation secrets	Enterprise SSO federation credentials are tenant-governed and protected as high-sensitivity secrets.
Signing keys	Token signing material is controlled by Keycloak operations and protected from application-level access.
Refresh tokens	Refresh tokens are treated as sensitive credentials and protected from client-side script access where applicable.
AIOS access	AIOS never receives Keycloak client secrets, refresh tokens, signing keys, or federation secrets.

Secrets Rules¶

Rule	Requirement
No secrets in code	Secrets must not be committed to source control or documentation.
No secrets in client storage	Secrets must not be stored in mobile or web client-accessible storage.
No secrets in logs	Logs and audit records must redact secrets and tokens.
Use approved secrets store	Runtime secrets come from approved secret management capability.
Least privilege	Secret access is scoped by environment, service, tenant where applicable, and purpose.
Rotation is required	Secrets require rotation policy, emergency rotation, and revocation capability.
Separate tenant integration secrets	Tenant-specific external credentials are isolated and governed.
AIOS cannot access raw secrets	AIOS tool calls use governed services and must not receive provider credentials.

Key Lifecycle¶

Lifecycle Stage	Requirement
Creation	Generated with secure randomness or provider-approved process.
Storage	Stored only in approved encrypted secret storage.
Access	Retrieved only by authorized services or operators.
Use	Used in memory only for the approved operation.
Rotation	Rotated according to risk and policy.
Revocation	Revoked immediately after compromise, tenant offboarding, or provider change.
Audit	Access, rotation, and failure events are auditable.

Non-Implementation Boundary¶

This document does not select a vault product, define environment variable names, create secrets, define rotation schedules, or write infrastructure configuration.