Secure Caracal
Security in Caracal centers on pre-execution authority: STS issues scoped mandates, Gateway enforces protected-resource access, Coordinator tracks agent/delegation state, Audit preserves evidence, and Operations keeps storage, streams, secrets, and releases recoverable.
Security Model
Section titled “Security Model”flowchart LR Operator[Operator] --> API[API and Console] Workload[Workload] --> STS[STS] Request[Protected request] --> Gateway[Gateway] Agent[Agent SDK] --> Coordinator[Coordinator] API --> Audit[Audit evidence] STS --> Audit Gateway --> Audit Coordinator --> Audit Audit --> Postgres[(Append-only audit)]
Security Review Path
Section titled “Security Review Path”| Need | Page |
|---|---|
| Understand assets, boundaries, threats, and mitigations | Review the Threat Model |
| Harden a production deployment | Harden Security Posture |
| Verify a release before installing | Verify a Release |
| Demonstrate assurance to a reviewer or auditor | Generate an Evidence Pack |
| Report a vulnerability privately | Report a Vulnerability |
| Operate a security incident | Respond to Incidents |
| Evaluate the project for enterprise adoption | Enterprise Security Readiness |
Core Invariants
Section titled “Core Invariants”- STS must fail closed on policy, key, session, revocation, replay, step-up, and signing errors.
- Gateway must never trust caller-supplied destinations and must deny before upstream dispatch when authority or routing is unsafe.
- Redis stream messages require HMAC signing in published modes where configured.
- Audit evidence must remain append-only, tamper-evident, and recoverable through replay/DLQ paths.
- Secrets must come from secret files or platform secret managers in production.
- The open-source product must not depend on enterprise-only code or controls.
Next Step
Section titled “Next Step”Read Review the Threat Model before hardening a deployment.