Put your AI agents in the platform you already run

The problem: agents are arriving faster than your platform can model them

You run an internal developer platform. You have a service catalog, an IdP, infrastructure as code, GitOps reconciliation, and a portal that engineers actually open. That machinery exists precisely so that nothing important runs unmodelled — no service without an owner, no access without a policy, no change without a diff.

AI agents break that contract. A Claude Code session, an MCP server, a scheduled autonomous agent — each can read and write across the same databases, object stores and APIs your services touch, but they show up outside the catalog. They get spun up by developers, not provisioned by you. They authenticate as shared service accounts as often as not. And the hyperscalers have made this worse by making agent identity a GA primitive in three mutually incompatible registries.

The market signal is blunt. Gartner expects more than 40% of agentic-AI projects to be cancelled by the end of 2027 (Gartner, press), and the IBM Cost of a Data Breach 2025 study (Ponemon) found that, of organisations that suffered an AI-related breach, roughly 97% lacked proper AI access controls. A preliminary MIT finding from the NANDA project — the GenAI Divide, via Fortune, August 2025, not yet peer-reviewed — reports that around 95% of GenAI pilots showed no measurable P&L impact, and that externally-bought tools succeeded about twice as often as internal builds. Read against a platform team’s job, that points the same direction: ungoverned, unmodelled agent sprawl is where the value leaks out and the risk leaks in.

How Olivares AI fits the platform you already run

Olivares AI is an open, self-hostable platform that discovers the AI agents on your infrastructure, maps what each one can read and write, and governs and audits that access. The design goal for platform teams is not another console — it is to make agents first-class citizens of the platform you already operate.

Agents as first-class catalog entities

The platform discovers agents, MCP servers, sessions and non-human identities, and builds an access map: a graph of every agent → database / store / API edge, each marked read (R) or read-write (RW). That graph is the catalog entry an agent should have had all along — what it is, what it touches, and whether what it touches matches what it is permitted to.

That last distinction is the core of the product. Edges are classified permitted vs observed, so least-privilege drift is visible rather than assumed. See the access map and the concept page on permitted vs observed.

The honesty caveat matters here and we keep it in the open: R/RW fidelity is tiered. Coverage is clean on sources with native audit, lossy where edges are coarse, and opaque where there is no passive read/write signal at all; attribution is firm when a source carries per-agent identity and approximate when a shared account hides it. The map shows the tier rather than faking certainty — see fidelity.

Manage-as-code: a Terraform/OpenTofu provider

For a platform team, config-as-code is table stakes. Olivares AI ships terraform-provider-olivares, which manages your own self-hosted control plane declaratively against its stable API. The provider exposes resources and data sources for agents, policies, deployments, agent-identity bindings, budgets, capability config and notification routes, with import, plan/apply and drift handling — so the agents you govern are reconciled the same way ArgoCD or Flux already reconciles the rest of your estate.

One licence detail to be precise about, because it differs from the connector SDK: the provider is AGPL-3.0-only, not Apache-2.0.

resource "olivares_agent" "billing_assistant" {
  name = "billing-assistant"
  # ...managed alongside the rest of your platform, as code
}

resource "olivares_policy" "billing_least_privilege" {
  # least-privilege intent, versioned in Git, reconciled like everything else
}

The HCL above is illustrative of shape, not a copy-paste contract — generate against the provider’s own published schema. The product is pre-1.0: treat resource coverage as tracking the API surface, and check the modules reference for what is wired today.

Fit with your IdP — federation, not replacement

Olivares AI is not an identity provider and does not try to be one. It federates agent identity read-only: it reads rosters from Microsoft Entra Agent ID, AWS AgentCore Identity and Google Agent Identity, and reconciles them against a SPIFFE/WIF roster so each edge in the access map carries firm-or-approximate attribution. Dedicated agent and workload identities resolve to firm attribution; blueprint principals, credential providers and service-account agents stay approximate rather than being promoted to a fabricated identity. It issues no credentials and writes nothing back to those registries — federation is strictly read-only.

It also surfaces a useful drift class for platform security: long-lived static credentials detected on agent identities, in line with the Five Eyes 2026 guidance toward short-lived credentials. SVID-based OAuth client authentication (the draft-ietf-oauth-spiffe-client-auth work) is implemented as design-toward — there is no conformance claim until an authorization server publishes the matching flow. See identity & federation.

A portal angle: Backstage, read-first

If your developers live in Backstage, the agent inventory should live there too. The design target is a native, read-first plugin — inventory, live sessions and the R/RW access map rendered inside the portal and authenticated against the control plane — not an iframe and not a second dashboard. Read-first is deliberate: it matches the product’s posture (below) and keeps portal integration low-risk.

CLI-first, with a stable API underneath

The whole platform is one Go binary, controlplane, that boots to a populated access graph; the web console is embedded in the same origin as the API. Everything you can do in the UI you can drive from the CLI or the OpenAPI 3.1 surface, which is what the Terraform provider, a Backstage plugin and your own automation all build on. Start with the configuration reference, the CLI workflow, and the MCP governance surface.

What this is — and what it isn’t

This is a security-shaped product, so we hold a hard line on what it claims.

• Read-first and deny-closed. It observes and governs broadly; it does not broadly actuate. Most actuation is live-on-demand or a declared, deny-closed seam — a deploy apply returns 503 until you provision an executor, not a silent no-op. See permitted vs observed and the honesty & limits page.
• Pre-1.0, open-core. The catalog is 23 modules; roughly 20 are wired in a stock install. Nothing here implies all 23 are fully live — the modules reference marks per-module status.
• Air-gap means the control plane, not Claude. The governance-and-observation plane runs fully self-hosted and can be air-gapped. Claude inference is never self-hosted — Anthropic publishes no weights, so any Claude call reaches an API. Only models you genuinely self-host (vLLM, Ollama) run offline. See security.
• Not certified. It is designed toward EU AI Act, NIST AI RMF, ISO/IEC 42001, SOC 2 and others, with audit evidence drawn from an append-only, hash-chained ledger. It is not SOC 2 / ISO / EU-AI-Act certified. See compliance.
• It complements your control towers; it doesn’t claim to replace them. Identity federation and posture export are read-only by design.

If you want the architectural picture first, read the architecture; if you want to know where we sit relative to gateways, observability and agent control towers, see the comparison. And if you are weighing the licence and the open-core boundary, open source is the honest version.

Related personas: security leaders, SRE & sysadmin, and higher education.