Honesty & limits

Business

Audit export (GET /v1/audit/export, olivares audit export), directory archives and external archive verification require Business. Community keeps the signed ledger, olivares audit verify and olivares dr backup; export routes and commands return HTTP 501 or exit 9. Audit forwarding and DDIL air-gap transfer also require Business.

A control plane for AI is a security product. If it overstates what it covers, it gives a false sense of safety — which is worse than no tool at all. So this page is the explicit contract about what runs today, what is planned, and what is out of scope on purpose. The rest of the documentation holds to it: commands in tutorials and how-to guides are meant to be run as written, and where the product does not yet cover something, the page says so rather than implying it does.

NATS event delivery: The Core NATS bridge and NATS JetStream require Business Identity & Scale. Community uses in-process delivery.

What runs today

• The single binary builds, boots and reaches a populated access graph. The olivares binary compiles to one static artifact with the web UI embedded. Booting it with the demo estate (serve --seed-demo) and walking discover → R/RW graph → Permitted-vs-Observed drift → inventory is exercised end-to-end by the test suite. The tutorial reproduces exactly that path.
• First-run setup is credential-free. A fresh install has no default credentials; the engine prints a one-time, single-use setup token on first boot.
• Official Codex, Grok and OpenCode CLIs can run as provider sessions. The engine registers these drivers at boot. At launch, it uses the newest verified managed install, then the CLI on the engine’s PATH. OLIVARES_SESSION_RUNTIME_CODEX_BIN, OLIVARES_SESSION_RUNTIME_GROK_BIN and OLIVARES_SESSION_RUNTIME_OPENCODE_BIN override this resolution. If no executable resolves, launch is refused. Launches go through a provider profile. CHANGELOG.md [26.9.0] does not claim compatibility with an authenticated official Grok account.
• The REST API and audit ledger are real. The API reference is rendered from the product’s own OpenAPI 3.1 contract. The audit ledger is append-only and hash-chained with Ed25519-signed checkpoints, and can be exported in several SIEM formats.
• Releases are signed and verifiable. Signatures, SLSA provenance, SBOM and OpenVEX can all be verified. Verification is not yet fully network-free: keyless checks need Sigstore trusted-root material and the SLSA step has no offline mode. The product ships an air-gap bundle. The next release is 0.4, not yet published.

Open core — what is open vs commercial

The product is open core: the default (AGPL) binary is the complete product for one person or one team, and a small, additive commercial line (Business and Enterprise; the enterprise/ directory, built only with -tags enterprise, never in the public binary) holds the reserved features. Two boundaries matter for day-to-day use, and the open build answers for them honestly rather than faking them:

• SSO is open for a single IdP. Single-IdP login — OIDC (Authorization Code
  • PKCE) and SAML 2.0 (signed responses, anti-replay) — runs in the default binary with no -tags enterprise. Running more than one active IdP (per-tenant / by-domain), SSO-enforcement (require-SSO / block password login) and the inbound SCIM server are Business (Identity & Scale); activating a second active IdP returns multi_idp_requires_enterprise — an explicit product limit, never a fake 501.
• There is no user cap — accounts are unlimited in every edition. Community, Business and Enterprise self-hosted all admit an unlimited number of user accounts, whatever the license state: valid, expired, or none at all. The cap of three active accounts that shipped before 2026-07-27 was removed outright (the seat seam is still in the code, as a compatibility no-op that refuses nothing), and a license lapse never caps, disables or deletes an account. The commercial model is a term-based entitlement to the modules, never a per-seat charge.
• The rest of one person’s or one team’s platform is open. Inventory, the R/RW access map, the built-in roles and deny rules, the sealed audit ledger and the MCP checks run in the open binary. FinOps budgets and spend analysis, compliance frameworks and reports, SIEM push, active-passive HA leader routing and the edge collector are Business. The open build refuses them and names Business: an API route answers 501, a CLI command exits with code 9, and a server started with an HA leader-routing switch set refuses to start. The edition is the build you run, not a license check in the open binary. The additive enterprise/ modules are new code that was never in the open product, not features removed from it; which capability is in which edition is written once, in docs/editions.md in the repository. License validation in the open binary is attestation-only — it never enables, disables or blocks anything, except that installing an update bundle that does not state the community edition needs a live license (see Open core & licensing).

What is design-stage or pre-1.0

Olivares AI is pre-1.0. The product design documents are explicit that much of the platform is at the design stage in parts even where the engine already runs. Treat module-level depth as work in progress unless a page states otherwise.

• Coverage of the R/RW map is tiered, by design. Fidelity depends on what the source can prove. It is clean on stores with native audit (SQL via pgAudit, object storage via CloudTrail, warehouses/lakes), lossy on some stores (document/vector), and impossible to reconstruct passively on others (e.g. Redis, SQLite, D1) — where read vs write cannot be determined, the edge is marked unknown. Attribution is firm when a source carries per-agent identity and collapses to approximate when a shared service account hides it. The product shows these honestly; it does not fabricate certainty.
• The canonical R/RW sources are wired in the stock serve. The composition root registers the host-level observers — pgaudit, s3cloudtrail, ebpf, runtime and the mcp introspection source — alongside the warehouse/lake observers (snowflake/databricks/bigquery/mssql/mongo/redshift/gcs/ azure-blob/iceberg/openlineage/delta-sharing), all configurable through OLIVARES_SOURCES_CONFIG (the quickstart wires a real pgaudit source against the stock binary and the smoke test asserts it). The knowledge document sources (gdrive/confluence/notion/s3content) are deliberately not runtime sources — they are loaded on demand by knowledge ingest requests. The connectors reference marks each kind.
• The default is a single binary; the distributed event bus exists and is honest about its semantics. The default runs as one binary with an in-process event bus. The remote collector→core data path is built and shipped: edge collectors run source connectors locally and push observations to a central core over verified-client-cert mutual TLS, with no inbound listener (the collector mode, a Business feature). The distributed event bus shipped with the scale-out work: a hybrid that keeps the in-process fan-out for local delivery (blocking backpressure, no local loss) and bridges events across nodes over NATS, enabled by OLIVARES_BUS_CONFIG (a misconfigured bus config fails the boot rather than silently partitioning the bus). Cross-node delivery is documented honestly as at-most-once — bridge disconnects and drops are counted in dedicated metrics, never silent (monitoring).
• Governed actuation has three honest states: live, on-demand, and seam. The product observes and governs broadly today. A small set of actuations is live in the default binary with no provisioning: FinOps budget enforcement (an enforcing budget at its cap denies the spend), the notification dispatch transport (it routes once a destination is configured), the security detective findings/guardrails, and the in-process synthetic sandbox runner (isolated by construction). Several more are wired on-demand — the backend is built and wired, but stays deny-closed or degraded until an operator provisions it via env config: module VII (deploy) apply/retire (Business only: 501 in Community, otherwise a 503 until an executor is provisioned), module IV orchestration fire and module XVI voice dispatch (both deny-closed until a dispatcher is configured), the OS-isolated sandbox/red-team runtime (synthetic / DEGRADED until provisioned), model-backed semantic retrieval (lexical and public-only by default), and model execution in module X (503 until an inference credential is provisioned). What stays a declared, deny-closed seam with no backend at all is the dormant voice telemetry probe (the distributed event bus left this list when the NATS bridge shipped — see above). The modules catalog marks each module’s Govern/Observe and Actuate status; nothing claims to act where it does not. (This corrects an earlier reading that listed voice, the sandbox/red-team runtime and semantic retrieval as “live” — they are on-demand: verified against a stock serve --seed-demo boot, 2026-06-08.)
• Air-gap applies to the control plane, not to Claude inference. The control plane runs fully self-hosted and can be air-gapped (SQLite single-node, signed offline release, air-gap bundle). Claude itself is not self-hostable — Anthropic does not publish weights — so any Claude inference reaches Anthropic’s API, directly or via Bedrock/Vertex/Foundry. “Air-gapped” here means the governance and observation plane and its data stay inside your perimeter; it does not mean Claude runs offline. Models you genuinely self-host (e.g. via vLLM/Ollama under module XXIII) can run air-gapped; brokered frontier models cannot.
• Module routes are a separate, beta contract. The module endpoints (for example the access-map graph and drift) are not part of the 137-path stable core contract; they are published as a separate beta document — the module-route reference (served at /openapi.beta.json). Beta means the shapes may change with notice, and field-level detail still lives in the product’s typed interfaces. The core API reference documents the stable surface; it is not the whole product surface.

What the product deliberately does not do

• No offensive features. Olivares AI is not a command-and-control framework and does not scan other people’s credentials. The access map is a powerful reconnaissance tool for defenders to govern their own estate — viewing it is a privileged, tenant-scoped, fully-audited action. This defensive line is intentional and kept explicit (see the threat model).
• No native Splunk S2S forwarder. Forwarding to Splunk is a documented posture — point a Universal Forwarder at a file the control plane appends, or push over Splunk HEC — not a native Splunk-to-Splunk emitter. The Splunk how-to is explicit about which stream is which.
• No outbound webhooks in the REST contract. The OpenAPI document defines no webhooks. Outbound signed delivery exists as an internal notification destination connector, and the SCIM Security-Event-Token endpoint is an inbound receiver — neither is an OpenAPI webhook. See the API reference.
• Model fine-tuning (module XXIII) is post-v1. Its absence is a decision, not a gap.

Where the docs note a gap upstream

A few things this documentation surfaces are gaps in the product, reported to the teams that own the relevant contract rather than papered over here:

• The committed OpenAPI file the site renders is now regenerated from — and CI-checked byte-for-byte against — the engine’s own generator, so it no longer lags it (the earlier endpoint gap was reconciled). The earlier under-documentation of the /v1/audit/export format list was also fixed upstream: the summary and the bad-request message are both built from the engine’s own format registry (audit.FormatList()), so they cannot drift again — this section keeps the record because earlier editions of these docs reported the gap, and because the same rot had also hidden leef and ocsf from the CLI’s help and completion until 2026-07-25.
• The audit-ledger push path shipped with the SIEM/ITSM interop work: an audit.recorded eventing subscription turns on a per-tenant ledger pump that forwards sealed records at-least-once to a configured sink (Splunk HEC, Sentinel, Datadog, New Relic, or an HMAC-signed webhook). The pull export remains the right shape for WORM archival and offline re-verification. See push to your SIEM and the Splunk how-to. What still does not exist is a native Splunk S2S-protocol emitter (below).

If you find a command that does not behave as documented, that is a bug in the docs or the product — please report it.