Secrets and Identity
How OpenBao stores credentials centrally and Keycloak handles authentication, so agents never see raw secrets.
Secrets and Identity
AEGIS treats secrets and identity as platform concerns, not agent concerns. Two systems handle the heavy lifting: OpenBao stores every credential the platform needs — API keys, database passwords, signing keys, OAuth tokens — and Keycloak is the single OIDC authority that issues and validates identity tokens for every human, service, and SDK client.
Agents never see raw credentials. When an execution starts, the orchestrator resolves whatever secrets that agent or tool needs, fetches them from OpenBao under a short-lived lease, and injects them into the runtime — environment variables, mounted files, or per-request headers depending on what the tool expects. The credential leaves OpenBao, lives only as long as the execution needs it, and is wiped when the container is torn down. The agent code that uses the credential never knows where it came from and never has the ability to exfiltrate the storage path. Authentication for human operators and SDK clients flows through Keycloak using standard OIDC — Bearer JWTs on REST and gRPC, Authorization Code with PKCE for browser logins, Client Credentials for machine-to-machine.
Key ideas
- OpenBao — central, audited store for static secrets, dynamic credentials, and encryption-as-a-service.
- Keycloak — single OIDC issuer for all human and service-account authentication.
- Just-in-time injection — credentials are resolved at execution start and destroyed at execution end.
- Dynamic secrets — short-lived database and cloud credentials are minted per execution with automatic revocation.
- Multi-tenant isolation — each tenant gets its own Keycloak realm paired with its own OpenBao namespace.
Learn more
- Identity and Secrets — the architecture connecting OpenBao and Keycloak.
- Secrets — configuring OpenBao for your deployment.
- IAM — running Keycloak as the platform identity authority.