Compliance and Operations Readiness
This page is a compliance and operations readiness review of the Caracal Community Edition (open-source, Apache 2.0, self-hosted), written for enterprise security, compliance, audit, procurement, and operations teams evaluating adoption.
It is written conservatively and is intended to be verifiable. Read it with the following ground rules.
Reading Rules and Non-Claims
Section titled “Reading Rules and Non-Claims”- Caracal is not certified. This project does not hold, claim, or imply certification or attestation under any framework named on this page. No framework is represented as fully satisfied or guaranteed by Caracal.
- Best-effort alignment. Maintainers implement controls in a best-practice-oriented way and try to keep them aligned with common compliance needs. That alignment is best effort, not a guarantee, and not every requirement of any framework is implemented or verified.
- Caracal is a control, not a compliance program. Caracal is infrastructure that can support specific technical controls inside your compliance program. Adopting Caracal does not make an organization compliant with any framework. The control environment, the audit, and the attestation remain the adopter’s responsibility.
- Evidence over assertion. Every “covered” or “partially covered” statement below cites a path in this repository or docs so you can confirm it against the exact commit you deploy. Where a control depends on settings outside the source tree (organization policy, cloud configuration, operator action), it is marked accordingly and not asserted as implemented.
- Status vocabulary.
- Covered — Caracal implements a relevant control in code, schema, CI, or the release pipeline, verifiable at the cited path.
- Partially covered — Caracal implements part of the control or bounds the risk, but full coverage depends on operator configuration or application behavior.
- Not covered — Caracal does not address this item, and it is the adopter’s or another system’s responsibility within a domain Caracal could otherwise contribute to.
- Not applicable — The item does not map to Caracal’s function — for example model behavior, model output, an organizational process, or data-subject content. Where Caracal supplies inputs to such an item, that is noted in the row.
- Framework labels. OWASP Agentic AI categories, NIST AI RMF functions, EU AI Act articles, SOC 2 Trust Services Criteria, and the agentic authority controls (AARM R1–R9) are referenced as evaluation lenses. Control titles evolve across framework versions; reconcile the exact wording of each item against your authoritative copy of the framework. The AARM R1–R9 mappings use a working interpretation of agentic-authority control intents and must be reconciled with your authoritative control definitions before use in an audit.
A. Executive Summary for Compliance and Operations Teams
Section titled “A. Executive Summary for Compliance and Operations Teams”Caracal is a pre-execution authority layer for agents and automated workloads. Its Security Token Service (STS) is the sole issuer of scoped, signed mandates; the Gateway enforces protected-resource access before execution; the Coordinator tracks agent and delegation state; and the Audit service preserves tamper-evident decision evidence. Postgres is the system of record with per-zone row-level security; Redis Streams move revocation and operational events.
For a compliance and operations reader, the honest summary is:
- What Caracal is good at, and can evidence today: least-privilege machine authority (short-lived signed mandates instead of long-lived credentials), centralized revocation, zone-based isolation and blast-radius containment, and tamper-evident, HMAC-chained audit. These map cleanly to logical-access, traceability, and accountability controls.
- What Caracal supports but does not own: human/administrator identity and SSO (intentionally external to the runtime trust boundary — see the SSO position), risk management process, data-subject rights, and the overall control environment. Caracal supplies technical evidence into these; it does not satisfy them.
- What Caracal does not address: model-level agent behavior (prompt injection, hallucination, memory poisoning, goal manipulation). Caracal constrains what an agent is authorized to do and records what it did; it does not judge whether the agent should have wanted to.
- Certification posture: none claimed. No FIPS validation is claimed (details). SOC 2 is an attestation of an operating organization, which the open-source project is not; Caracal provides controls that can support an adopter’s SOC 2, not a SOC 2 report.
Adoption recommendation in one line: suitable as a least-privilege authority, revocation, and audit-evidence control for agentic systems, on the explicit understanding that the adopter owns the surrounding compliance program and the items marked partially covered below.
B. Control-by-Control Matrix
Section titled “B. Control-by-Control Matrix”B.1 OWASP Agentic AI Top 10 (ASI01–ASI10) and Agent Traceability
Section titled “B.1 OWASP Agentic AI Top 10 (ASI01–ASI10) and Agent Traceability”Mapped to the recognized agentic threat categories. Caracal is an authority and audit control, so it addresses the authority, identity, traceability, and revocation classes well and the model-behavior classes not at all. This is by design.
| # | Agentic risk category | Status | Caracal control |
|---|---|---|---|
| ASI01 | Memory poisoning | Not applicable | Agent memory and state do not map to Caracal’s function. Mitigate in the application. |
| ASI02 | Tool misuse | Partially covered | Mandates are scoped per resource and policy-gated before execution; Gateway enforces resource binding and route safety. Caracal cannot prevent misuse within legitimately granted scope. |
| ASI03 | Privilege compromise / excessive agency | Covered | STS issues least-privilege, short-lived mandates; delegation is re-validated server-side as a subset of parent authority; zones and the application-vs-session ceiling bound escalation; Postgres RLS enforces isolation. |
| ASI04 | Resource overload | Partially covered | API rate limiting and a provider rate-limit stream bound request volume; Caracal does not provide general DoS protection or compute quotas. |
| ASI05 | Cascading hallucination | Not applicable | Model-output correctness does not map to Caracal’s function. |
| ASI06 | Intent breaking / goal manipulation | Partially covered | Caracal bounds the authority an agent can exercise regardless of manipulated intent; it does not detect manipulated reasoning. |
| ASI07 | Misaligned / deceptive behavior | Partially covered | Authority bounds + tamper-evident audit constrain and record impact; behavioral alignment is not assessed. |
| ASI08 | Repudiation / untraceability | Covered | Append-only, per-zone HMAC-chained audit with a tamper-detection sweep; decisions for STS, Gateway, Coordinator, policy, and admin activity are recorded. |
| ASI09 | Identity spoofing / impersonation | Covered | Machine identity: STS is the sole token issuer; mandates are signed; the identity package verifies JWT/JWKS, issuer, audience, zone, scope, and delegation claims and fails closed. Human identity is external by design. |
| ASI10 | Human-in-the-loop manipulation / fatigue | Partially covered | Step-up re-authentication exists as a policy-driven control; Caracal does not manage approval-fatigue UX. |
| — | Agent traceability | Covered | Every decision is attributable to app, session, policy, resource, and result and is preserved as tamper-evident evidence. |
B.2 NIST AI RMF 100-1
Section titled “B.2 NIST AI RMF 100-1”Caracal is a tool used within an organization’s RMF, not an implementation of the RMF. It contributes most to Govern and Manage.
| RMF function | Status | Caracal contribution |
|---|---|---|
| Govern | Partially covered | Enforceable, version-controlled policy (Rego); accountability via attributable audit; documented threat model and incident response. The governance process is the adopter’s. |
| Map | Not applicable | Risk and context mapping is an organizational process, not a Caracal function. Its trust-boundary and resource model are inputs an adopter can map against. |
| Measure | Partially covered | Operational and decision metrics, audit lag/tamper metrics, and exportable decision evidence support measurement; Caracal does not measure model risk. |
| Manage | Partially covered | Centralized revocation, short-lived authority, alerting, and incident runbooks support active risk management of agent authority. |
B.3 EU AI Act (Regulation 2024/1689)
Section titled “B.3 EU AI Act (Regulation 2024/1689)”Caracal is not an AI system and does not place an AI system on the market. It can supply technical evidence toward specific provider/deployer obligations. It does not make any party compliant.
| Obligation area | Status | Caracal contribution |
|---|---|---|
| Art. 9 — Risk management system | Not applicable | A risk-management system is an organizational process, not a Caracal function. Caracal provides enforcement and revocation controls an adopter can reference within it. |
| Art. 12 — Record-keeping / logging | Partially covered | Tamper-evident, append-only audit with export to object storage and SIEM provides durable activity records for the authority layer. Scope is Caracal decisions, not full AI-system lifecycle logging. |
| Art. 14 — Human oversight | Partially covered | Step-up re-authentication and revocation give operators intervention points; oversight design remains the adopter’s. |
| Art. 15 — Accuracy, robustness, cybersecurity | Partially covered | Fail-closed enforcement, signed mandates, RLS isolation, supply-chain controls, and tamper detection support the cybersecurity dimension; accuracy/robustness of the AI model is out of scope. |
B.4 SOC 2 Type II — Trust Services Criteria
Section titled “B.4 SOC 2 Type II — Trust Services Criteria”SOC 2 attests an operating organization’s controls over a period and requires an independent auditor. The open-source project is not an operating service organization, so Caracal cannot hold a SOC 2 report. The mapping below shows which Caracal controls can serve as evidence inside an adopter’s SOC 2.
| TSC | Status | Caracal control that can serve as evidence |
|---|---|---|
| CC6 — Logical & physical access | Covered | Sole-issuer STS, signed least-privilege mandates, per-zone RLS, service DB roles with NOBYPASSRLS, centralized revocation. |
| CC7 — System operations / monitoring | Partially covered | Health/readiness ladders, metrics, alert rules, DLQ and tamper monitoring, incident runbooks. |
| CC8 — Change management | Partially covered | Expand/contract migrations with a CI guard, signed reproducible releases, provenance/SBOM attestations, caracal upgrade. |
| A1 — Availability | Partially covered | HA Helm profile (replicas, PDBs, anti-affinity), Redis durability requirements, backup/retention guidance. Operator owns the SLO. |
| C1 — Confidentiality | Partially covered | Per-purpose key separation, zone KEK, RLS, secret files at 0444, TLS terminated by operator. |
| PI1 — Processing integrity | Partially covered | Fail-closed policy evaluation, HMAC-signed streams, append-only audit with continuity checks. |
| P-series — Privacy | Not applicable | Caracal processes authority metadata, not subject data sets, and does not implement data-subject-rights workflows. |
B.5 Agentic Authority Controls (AARM R1–R9)
Section titled “B.5 Agentic Authority Controls (AARM R1–R9)”Mapped using a working interpretation of agentic-authority control intents. Reconcile each control definition against your authoritative source before audit use.
| Ctrl | Working interpretation | Status | Caracal control |
|---|---|---|---|
| R1 | Authority is issued by a single, auditable authority | Covered | STS is the sole mandate issuer. |
| R2 | Least-privilege, time-bounded authority | Covered | Short-lived scoped mandates; max-TTL bounds. |
| R3 | Delegation is constrained and re-validated | Covered | Delegation edges re-validated server-side as subsets; cross-application delegation requires receiver consent. |
| R4 | Authority is revocable centrally and promptly | Covered | Redis-backed revocation propagated to STS and Gateway consumers; short mandate TTLs bound exposure. |
| R5 | Actions are traceable to an identity | Covered | Attributable audit per app/session/policy/resource/result. |
| R6 | Evidence is tamper-evident | Covered | Per-zone HMAC hash chain + startup and rolling tamper sweep. |
| R7 | Isolation bounds blast radius | Covered | Zones + per-zone KEK + Postgres RLS. |
| R8 | Keys are separated by purpose and rotatable | Partially covered | Per-purpose keys exist and are documented for rotation; rotation is an operator runbook, not automated verification. |
| R9 | Operational recoverability | Partially covered | Backup/retention, incident response, failure drills, and rollback are documented; execution and testing are the operator’s. |
C. Evidence Map to Code, Docs, and Tests
Section titled “C. Evidence Map to Code, Docs, and Tests”Confirm each item against the commit you deploy.
| Control | Evidence path |
|---|---|
| STS sole issuer / signed mandates | services/sts/, Token Exchange Flow |
| Gateway pre-execution enforcement | services/gateway/internal/, Threat Model |
| Identity verification (fail-closed) | packages/identity/ (verify.go, scope.go), Identity Package |
| Token exchange (RFC 8693) | packages/oauth/ (client.go), OAuth Package |
| Zone isolation via RLS | infra/postgres/migrations/0001_baseline.up.sql (ENABLE ROW LEVEL SECURITY, CREATE POLICY zone_isolation, NOBYPASSRLS roles) |
| Append-only, HMAC-chained audit | services/audit/internal/tamper.go, services/audit/internal/rehash.go, Audit Ledger |
| Audit export to object store / SIEM | services/audit/internal/parquet.go, services/audit/internal/server.go, Export Audit Evidence |
| Centralized revocation | services/gateway/internal/revocations.go, packages/revocation/, Sessions and Revocation |
| Redis durability + eviction guard | packages/core/go/redisguard/redisguard.go, infra/redis/redis.conf, Operate Redis Streams |
| Expand/contract migrations + upgrade | infra/postgres/scripts/migrate.sh, infra/postgres/scripts/validateMigrations.sh, apps/runtime/src/commands/stack.ts, Upgrade Caracal |
| Generated secrets (CSPRNG, file-backed) | packages/engine/src/secrets.ts, Configure Service Environment |
| Key inventory and rotation | Rotate Keys and Secrets |
| Policy engine (Rego) | Policy, Author Policy Data |
| Supply-chain controls (CI) | .github/workflows/{codeql,containerScan,supplyChainScan,scorecard,dependencyReview}.yml, Enterprise Security Readiness |
| Release signing / SBOM / provenance | Verify a Release, Enterprise Security Readiness |
| Generated evidence pack | infra/scripts/evidencePack.sh, Generate an Evidence Pack |
| Threat model | governance/THREAT_MODEL.md, Threat Model |
| Incident response | governance/INCIDENT_RESPONSE.md, Incident Response |
| Backup and retention | Backup and Retention |
D. Gaps, Limitations, and Non-Claims
Section titled “D. Gaps, Limitations, and Non-Claims”Each gap is classified as a product, documentation, or operations gap so it can be triaged and, where appropriate, fed back to the project to improve it.
| Item | Classification | Statement |
|---|---|---|
| FIPS-validated cryptography | Product gap (intentional, documented) | Not claimed. Default artifacts are not built against FIPS-validated modules. Operators with a FIPS mandate must supply a validated runtime/host; not verified by the project. See FIPS Readiness. |
| Human/admin SSO (OIDC/SAML, SCIM) | Boundary (Enterprise Edition) | Intentionally outside the runtime trust boundary. OSS admin access uses an internal admin token that must sit behind an authenticating ingress/proxy. Native SSO/SCIM is Enterprise Edition. |
| Key rotation verification | Operations gap | Per-purpose keys and a rotation order are documented, but there is no automated rotation-freshness check. Rotation is an operator runbook. |
| Model reasoning & output threats (ASI01, ASI05; detection aspect of ASI06/07) | Out of scope (by design) | Caracal governs authority and records actions; it does not store agent memory, evaluate model reasoning, or judge output correctness. It still bounds the authority an agent can exercise under ASI06/07. |
| Data-subject-rights / privacy workflows | Out of scope | Caracal processes authority metadata, not subject data sets; privacy obligations are the adopter’s. |
| SOC 2 report | Not applicable to OSS project | The open-source project is not an operating service organization; it cannot hold a SOC 2 report. It provides controls that support an adopter’s SOC 2. |
| HA / availability SLO | Operations gap | HA primitives are shipped (Helm profile); the SLO, capacity, and DR testing are the operator’s. |
| Internal checks | Limitation | CI guards (e.g., the expand-only migration guard) and the tamper sweep are best-effort detections, not guarantees of correctness or compliance. |
E. OSS vs Enterprise Edition Boundary
Section titled “E. OSS vs Enterprise Edition Boundary”The enforcement core — STS sole issuance, Gateway enforcement, zones, RLS, revocation, and tamper-evident audit — is identical in both editions. Enforcement strength is not gated behind Enterprise. The Enterprise Edition adds managed and organizational capabilities, not stronger enforcement.
| Capability | Community Edition | Enterprise Edition |
|---|---|---|
| Pre-execution enforcement, revocation, audit | Included | Included (identical) |
| Zones as isolation primitive | Included (manual) | Managed multi-tenancy over the same primitive |
| Human SSO (SAML/OIDC) + SCIM | Not included (front with your own OIDC proxy) | Included |
| Organizations, teams, org-level RBAC | Not included | Included |
| Hosted management UI / managed data plane | Not included | Included |
| Commercial support / lifecycle | Not included | Included |
The intentional position on identity: STS remains the sole runtime authority and human identity stays external. This is a deliberate architectural boundary, not a missing OSS feature; an enterprise fronts the Console/Admin API with its existing OIDC-aware ingress today. Enterprise SSO/SCIM is managed convenience over that same seam. See Compare Editions.
F. Enterprise Verification Steps
Section titled “F. Enterprise Verification Steps”Run these against your own copy after adoption. They are designed to be repeatable and to produce artifacts you can retain.
- Pin and verify the supply chain. Verify release signatures, provenance, and SBOMs for the exact artifacts you run — see Verify a Release. Record the digests you deploy.
- Generate an evidence pack. Run
infra/scripts/evidencePack.shto capture provenance, schema-enforcement, and runtime-readiness evidence in one artifact — see Generate an Evidence Pack. - Confirm zone isolation. Inspect
infra/postgres/migrations/0001_baseline.up.sqlforENABLE ROW LEVEL SECURITYandzone_isolationpolicies, and confirm service roles areNOBYPASSRLS. Then test cross-zone access denial against a running instance. - Confirm audit tamper-evidence. Review
services/audit/internal/tamper.go; on a running instance, attempt an out-of-band mutation ofaudit_eventsin a test environment and confirm the sweep flags a chain break (CaracalAuditTamperDetected). - Confirm revocation propagation. Revoke a session and confirm the Gateway denies a subsequent call within your bound, using
services/gateway/internal/revocations.goas the reference path. - Confirm fail-closed posture. Run in published mode (
CARACAL_MODE=stable) and confirm metrics are authenticated, HMAC keys are required, and the services refuse to start with incomplete configuration. - Confirm change-window safety. Exercise
caracal upgradeand the expand-only guard (infra/postgres/scripts/validateMigrations.sh) on a staging copy; confirm a contract-phase DDL change is rejected when untagged. - Confirm Redis durability. Verify
maxmemory-policy noevictionand AOF on your Redis; confirm the startup eviction warning fires when set to an unsafe policy — see Operate Redis Streams. - Run an agent-assisted review. Use the compliance playbook prompts to have a coding agent reproduce this mapping against your checked-out copy and flag drift.
F.1 Operational Readiness Review
Section titled “F.1 Operational Readiness Review”| Domain | Stance | Reference |
|---|---|---|
| Secret management | Generated with a CSPRNG, written as *_FILE secrets at mode 0444; derived DB/Redis URLs auto-rewritten. Provision external secrets via your manager; never commit plaintext. | packages/engine/src/secrets.ts, Configure Service Environment |
| Key rotation | Per-purpose keys with a documented inventory, storage boundary, and rotation order. Rotation is an operator runbook; plan windows and dual-key overlap where required. | Rotate Keys and Secrets |
| Redis durability | Correctness-critical store, not a cache. Require noeviction + AOF; bundled image is safe, external/managed Redis is the operator’s responsibility; startup guard warns on unsafe policy. | Operate Redis Streams |
| Migration & upgrade | Expand/contract migrations with a CI guard and caracal upgrade for a no-maintenance-window roll. Always run on staging first. | Upgrade Caracal |
| Observability | Health/readiness ladders, authenticated metrics, alert rules, DLQ/tamper/lag metrics. Wire to your monitoring and SIEM before go-live. | Observe Caracal, Alerts |
| Audit export | Append-only audit_events plus object-store/SIEM export; preserve audit HMAC keys for the retention window. | Export Audit Evidence |
| Rollback & incident response | Severity triggers, first-hour runbook, evidence preservation, containment, and Helm rollback. | Incident Response, Failure Drills |
G. Agent-Assisted Review Playbooks
Section titled “G. Agent-Assisted Review Playbooks”To let your own team reproduce this review against the codebase you adopt, the repository ships copy-pasteable prompts for three coding agents. Each instructs the agent to run the same compliance and operations review against a checked-out Caracal copy and produce a truthful, evidence-cited report with verification steps and an explicit non-claims section.
| Agent | Path |
|---|---|
| Claude Code | playbooks/compliance/claude-code/CLAUDE.md |
| GitHub Copilot | playbooks/compliance/github-copilot/AGENTS.md |
| OpenAI Codex | playbooks/compliance/openai-codex/.codex/AGENTS.md |
The prompts enforce the same conservatism as this page: no certification claims, evidence paths for every assertion, and clear separation of covered, partially covered, not covered, and not applicable.
H. Final Adoption Recommendation
Section titled “H. Final Adoption Recommendation”Adopt Caracal Community Edition as a least-privilege authority, revocation, and audit-evidence control for agentic and automated workloads, with a clear-eyed view of its boundary.
- It is a strong, evidenceable fit for the authority, identity, isolation, revocation, and traceability control classes (ASI03, ASI08, ASI09, agent traceability; SOC 2 CC6; AARM R1–R7).
- It is a supporting control — not a solution — for risk-management process, human oversight, availability SLOs, and key-rotation verification (NIST RMF Govern/Manage; EU AI Act Art. 12/14; SOC 2 CC7/CC8/A1; AARM R8–R9). Own these explicitly.
- It does not address model-behavior threats or privacy-rights workflows, and it makes no certification claim. Do not represent it as compliance, certification, or FIPS validation to a review board.
The deciding question for an architecture and compliance review board is not whether Caracal is certified — it is not, and says so — but whether its enforced, tamper-evident, least-privilege authority model materially reduces the security, implementation, and audit burden of governing agents versus building the same controls in-house. For organizations that need pre-execution authority and durable decision evidence for agents, it does, provided the partially covered items above are owned by the adopter and the not-applicable items are recognized as outside Caracal’s function.