A platform that governs the AI agents on your infrastructure 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: what runs today, what is design-stage, and what is out of scope on purpose. The rest of the docs hold to it. Where the product does not yet cover something, the page says so rather than implying it does.
Olivares AI is pre-1.0 and open-core. Treat module-level depth as work in progress unless a page states otherwise.
What runs today
- A single binary boots to a populated access graph. The control-plane binary compiles to one static artifact with the web UI embedded. Booting it against the synthetic demo estate and walking discover → R/RW graph → permitted-vs-observed drift → inventory is exercised end-to-end by the test suite. The quickstart reproduces that path.
- First run is credential-free. A fresh install has no default credentials. On first boot, with no users yet, the engine mints a one-time, single-use setup token and prints it to stdout (never to the logs); you exchange it to create the first administrator.
- The REST API and the audit ledger are real. The public surface is described by the product’s own OpenAPI 3.1 contract. The audit ledger is append-only and hash-chained, with signed checkpoints, and can be exported to SIEM formats for offline re-verification.
- Releases are signed and verifiable offline. Each release carries cosign signatures, SLSA provenance, and SBOMs (SPDX and CycloneDX). All of this can be verified without network access. Key-based (non-OIDC) signing is supported for air-gapped build pipelines, and an air-gap bundle ships for installs with no egress.
What is design-stage or pre-1.0
The catalog is 23 modules; roughly 20 are wired in a stock install today. Nothing here claims all 23 are fully live. See the modules reference for per-module status.
R/RW map fidelity is tiered, by design
Fidelity depends on what the source can prove, and the access map shows that honestly rather than faking certainty. See fidelity for the full model.
- Coverage is
cleanon stores with native audit (SQL, object storage, warehouses/lakes),lossyon document and vector stores where edges exist but are coarse, andopaquewhere there is no passive read/write signal at all (for example Redis, SQLite, D1). Where read versus write cannot be determined, the edge is markedunknown. - Attribution is
firmwhen a source carries per-agent identity, and collapses toapproximatewhen a shared service account hides it. Anything unresolved staysapproximate— never silently promoted to a fabricated agent.
Sources: host observers wired; some connectors load on demand
The composition root registers the host-level R/RW observers in the stock serve path, configurable through source config. Several source connectors are built but not yet wired into stock serve — for example the knowledge document sources, which are loaded on demand by ingest requests rather than running as standing observers. The connect-a-source guide and the modules reference mark which is which.
The default is one binary; the distributed bus is opt-in
The default install runs as a single binary with an in-process event bus — blocking backpressure, no local loss. A distributed NATS bridge is built and wired for scale-out HA, opt-in via bus config; a misconfigured bus fails the boot rather than silently partitioning. Cross-node delivery over the bridge is documented honestly as at-most-once (the in-process capture is the durability boundary); drops are counted in metrics, never silent.
Governed actuation has three honest states
The platform observes and governs broadly; it does not broadly actuate. Read permitted vs observed for why that line matters. Actuation falls into three states:
- Live in the default binary, no provisioning: FinOps budget enforcement (an enforcing budget at its cap denies the spend — in-process, always wired), notification dispatch once a destination is configured, security detective findings, and the in-process synthetic sandbox runner.
- On-demand — backend built and wired, but deny-closed or degraded until an operator provisions it: deploy
apply/retire(a503until an executor is provisioned), orchestration fire and voice dispatch (deny-closed until a dispatcher is configured), the isolated sandbox/red-team runtime (synthetic until provisioned), and model execution (a503until an inference credential is configured). - Seam — a declared, deny-closed interface with no backend yet.
Air-gap applies to the control plane, not to Claude inference
This is the most important carve-out. The control plane — governance and observation — runs fully self-hosted and can be air-gapped: 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. In Olivares AI those inference seams are fail-closed: with no inference credential the LLM judge stays skipped and embeddings fall back to a zero-egress local embedder. “Air-gapped” here means your governance and observation plane and its data stay inside your perimeter — it does not mean Claude runs offline. Only models you genuinely self-host (for example via vLLM or Ollama under the model-management module) can run air-gapped; brokered frontier models cannot. See connect Claude Code and security.
Not all module routes are in the public API contract
Some module endpoints (for example the access-map graph and drift) are reachable but are deliberately not part of the served OpenAPI document; their field-level contracts live in the product’s typed interfaces. The CLI and configuration references cover the operational surface; the OpenAPI contract is the core REST surface, not the whole product.
Not certified
Olivares AI is designed toward SOC 2, ISO 27001, and the EU AI Act — it is not certified against any of them. See compliance for what “designed toward” means and what evidence the platform produces.
What the product deliberately does not do
- No offensive features. This is not a command-and-control framework and it does not scan other people’s credentials. The access map is reconnaissance for defenders to govern their own estate — viewing it is a privileged, tenant-scoped, fully audited action. The defensive line is intentional.
- 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.
- No outbound webhooks in the REST contract. The OpenAPI document defines no
webhooks. Signed outbound delivery exists as an internal notification destination, and the inbound SCIM Security-Event-Token endpoint is a receiver — neither is an OpenAPI webhook. - No fine-tuning before v1. Model fine-tuning (the model-management module) is post-v1. Its absence is a decision, not a gap.
A note on audit export
The CLI ledger export targets cef, syslog, and otlp. The eventing push path to a SIEM renders a wider dialect set (including OCSF and LEEF) when a sink is configured. The pull export is the right shape for WORM archival and offline re-verification.
If you find a command that does not behave as documented, that is a bug in the docs or the product — please report it. This page is the trust anchor; everything else defers to it.