The problem: you cannot govern what you cannot see
The agents are already there. A coding assistant with a database credential, an internal RAG service that quietly gained write access to an object store, a scheduled job that calls an MCP server nobody registered. They were provisioned by teams moving fast, and the security org inherits the blast radius without ever having seen the map. Analysts have a name for this shape — agent sprawl — and the governance gap underneath it is measurable.
Of the organizations that suffered an AI-related breach, roughly 97% lacked proper AI access controls (IBM Cost of a Data Breach 2025, Ponemon). That is not a tooling-maturity story; it is the absence of a control surface. At the same time Gartner expects more than 40% of agentic-AI projects to be cancelled by end of 2027, and projects “guardian agents” to be 10–15% of the agentic-AI market by 2030 (Gartner, press) — the market is pricing in the fact that ungoverned agents do not survive contact with a real security review.
The pattern is wider than security teams. In a preliminary, not-yet-peer-reviewed study, roughly 95% of GenAI pilots showed no measurable P&L impact, and externally-bought tools succeeded about twice as often as internal builds (MIT “GenAI Divide”, NANDA project, via Fortune, Aug 2025 — preliminary). Whatever the cause, an estate full of agents nobody can account for is exactly the condition under which both the breach risk and the wasted-pilot risk compound.
This maps cleanly onto the AI TRiSM framing — trust, risk and security management for AI — where governance and runtime inspection sit as distinct layers. Olivares AI is built to be the layer that discovers, observes and governs agent access, and it is honest about where that stops.
What Olivares AI gives a security leader
A typed read/write access map as the control surface
The access map models every agent as a node and every resource it can reach — databases, object stores, MCP servers, APIs, queues — as a node, with each edge typed R (read) or RW (read-write). That R-versus-RW typing is the point: least-privilege drift and incident blast radius are both functions of write access, not mere connectivity, and a flat “has access” list hides exactly that. This is reconnaissance for defenders — the same map an attacker would want, built for the people defending the estate.
Reading the full graph is deliberately a privileged, tenant-scoped, and fully-audited action, because a complete map of what every agent can touch is itself a recon roadmap. The map stores the relationship — origin, resource, R/RW, source, confidence, timestamps — and never the payloads, SQL bodies, secrets or PII that flowed across the edge. What is not stored cannot leak.
Permitted vs observed: the diff that becomes a finding
Every edge carries two independent facts: whether the access is permitted (a grant or policy allows it) and whether it has been observed (telemetry and native audit show it happening). The diff between those two layers is the control signal:
- Unexpected access — observed but not permitted. An agent touched something no grant covers. This is the security-relevant headline.
- Unused grants — permitted but never observed. Your concrete least-privilege cleanup list, not a vague “review your IAM” reminder.
The diff is deliberately conservative. Where the platform cannot yet firmly link an
acting credential to the agent its grant was written for, the edge is marked
reconciliation_pending — honest uncertainty, never a fabricated violation. See
permitted vs observed for the full
reconciliation contract.
Fidelity that refuses to bluff
A security tool that overstates what it knows is worse than none. Every edge carries
two honest axes. Coverage of the R/RW classification is tiered
clean | lossy | opaque — clean where native audit makes it unambiguous (Postgres
via pgAudit, object storage via CloudTrail, the warehouses, plus a kernel-level eBPF
backstop), down to opaque stores (Redis, SQLite, D1) where the mode is marked
unknown rather than guessed. Attribution is firm where a per-agent identity
signal resolves the access to one agent, and approximate where a shared service
account hides which agent acted. A clean/firm edge and a barely-seen one are never
rendered as equally certain — read the fidelity model.
Deny-closed governance, dual control, and a kill switch
Governance is read-first and deny-closed. The authorization core is deny-by-default and tenant-scoped, closing confused-deputy and IDOR classes by construction. Any attribute-based policy you wire on top can only further-restrict — the composition is an intersection, so a policy can never widen a grant.
Where the product gates an action, the loop is: a surface presents (drift, a finding)
→ an authorized operator decides → the decision is recorded. The approval engine
enforces separation of duty (a requester cannot decide their own request) and a
duplicate-decider guard, keyed on stable human identity — a system token has no
identity and cannot decide. A critical action carries a mandatory two-person
floor drawn from NIST SP 800-53 AC-3(2), enforced both at create and re-derived at
decide, so even an operator policy that lowers the tier cannot make a critical action
single-handed. An audited break-glass valve exists for the 03:00 incident — loud
by construction, hardware-stepped-up, time-boxed, and forced into post-review.
The kill switch is the estate-wide deny gate. Engaging is deliberately cheap (admin-tier, a reason, no quorum) because a stop that waits for consensus is not a stop; every governed actuation gate consults the stop row live and fails closed on a read error. Re-enabling is never unilateral — it is gated on a fresh dual-control approval and has no break-glass path, because “the estate stays stopped” is the safe state.
Tamper-evident evidence
Every mutating action is appended to an append-only, hash-chained audit ledger in the same transaction as the change, with the real actor; sensitive reads self-audit in a committed write. Rewriting history is detectable, and the ledger never contains PII. The compliance module maps that runtime evidence onto control frameworks so an assessment is fed from observed reality rather than a questionnaire.
What this is — and what it isn’t
- Self-hosted and sovereign. The control plane runs on your own infrastructure and can be air-gapped. Olivares AI is an open, self-hostable platform (AGPL-3.0). See the security model and architecture.
- Detective by default; deny-closed where it acts. It observes and governs broadly; it does not broadly actuate. Where it can take an action, that surface is live, on-demand, or a declared seam — and the modules catalog marks which. An absence of enforcement is usually by design.
- Pre-1.0, with a published catalog of 23 modules (roughly 20 wired today). Not everything is live; we say which is which rather than implying full coverage.
- Air-gap applies to the Olivares control plane, not to your models. A hosted model such as Claude is never air-gapped; only self-hosted models (vLLM, Ollama) run offline. Olivares governs access in either case.
- Not certified. Olivares AI is designed toward SOC 2, ISO/IEC 42001 and the EU AI Act; it holds no certification and we do not claim one.
Higher-ed and research estates have a parallel version of this problem — wide AI use across faculty and staff while formal AI governance and acceptable-use coverage lags behind (EDUCAUSE research, 2025). If that is your context, see higher education; platform teams running the infrastructure should start at platform engineering.
Where to go next
- Access map — the typed R/RW graph and the permitted-vs-observed overlay on a real capture.
- Kill switch — the estate-wide deny gate in product terms.
- Compliance — tamper-evident evidence mapped to control frameworks.
- Governance concepts — read-first, deny-closed, dual control.
- Compare — how Olivares sits alongside gateways, observability and control towers.
- Get started — see the map on a demo estate.