Skip to content

Getting started

What is Olivares AI?

An open, self-hostable platform that discovers the AI agents on your own infrastructure, maps what each can read and write, and lets you govern and audit that access.

Olivares AI is an open, self-hostable platform that answers a question most teams cannot answer today: which AI agents are running on my infrastructure, and what can each of them actually reach?

It runs where your agents run, discovers them passively, and builds a read/write access map — for every agent, the resources it can touch and whether it can read them or read and write them. From there you can govern that access and prove, after the fact, exactly what happened.

The read/write access map

The map is the core of the product (module III). Each AI agent becomes a node; each resource it can reach — a database, an object store, an MCP server, an API — becomes a node too; and each edge is typed R (read) or RW (read/write).

That read-versus-write distinction is the point. An agent that can only read a production store is a very different blast radius from one that can write it. The map makes that difference explicit instead of leaving it buried in scattered IAM policies.

Permitted vs Observed

What sets the map apart is the diff between two layers:

  • Permitted — what an agent is allowed to touch, from grants and policy.
  • Observed — what it has actually been seen touching, from telemetry.

Comparing them surfaces two findings that matter:

  • Unexpected access — observed but never expected. The thing you want to catch.
  • Unused grants — permitted but never exercised. Your least-privilege cleanup list.

Honest about what it can prove

The map never fabricates certainty. Fidelity is tiered and shown as such:

  • Coverage of read-vs-write is clean on sources with native audit (PostgreSQL via pgAudit, object storage via CloudTrail, warehouses and lakes), lossy on some document/vector stores, and opaque where it simply cannot be reconstructed passively (Redis, SQLite, D1) — there the edge is marked unknown rather than guessed.
  • Attribution is firm when a source carries per-agent identity and collapses to approximate when a shared service account hides who did what.

You always see how much the product actually knows: the tiers are shown in the UI rather than hidden, so a clean/firm edge and an unknown/approximate one are never presented as the same thing.

Self-hosted and open-core

Olivares AI is open-core: the complete product is free and open source under AGPL-3.0 — not a stripped-down community edition. It deploys as a single static binary with the web console embedded.

The control plane runs inside your own infrastructure and can run air-gapped — your governance and observation data never leaves your perimeter. One honest caveat: hosted models like Claude are not self-hostable, so any model inference still reaches the provider’s API (directly or via Bedrock/Vertex/Foundry). “Air-gapped” means your estate data stays home, not that the model runs offline. Only genuinely self-hostable models (for example via vLLM/Ollama) run fully offline.

Where it is today

The platform is pre-1.0. It ships a catalog of 23 capability modules, of which around twenty are wired today; the rest are design-stage or post-v1. The product is read-first and detective by default — it observes and governs, and where it can act, it does so deny-closed. Nothing here claims to do something the code does not.

Ready to see it? Start with the Quickstart.