Bringen Sie Ihre KI-Agenten in die Plattform, die Sie bereits betreiben

Das Problem: Agenten treffen schneller ein, als Ihre Plattform sie modellieren kann

Sie betreiben eine interne Developer-Plattform. Sie haben einen Service-Katalog, einen IdP, Infrastructure as Code, GitOps-Reconciliation und ein Portal, das Entwickler tatsächlich öffnen. Diese Maschinerie existiert genau deshalb, damit nichts Wichtiges unmodelliert läuft — kein Service ohne Owner, kein Zugriff ohne Richtlinie, keine Änderung ohne Diff.

KI-Agenten brechen diesen Vertrag. Eine Claude-Code-Session, ein MCP-Server, ein geplanter autonomer Agent — jeder kann über dieselben Datenbanken, Objektspeicher und APIs lesen und schreiben, die auch Ihre Services berühren, aber sie tauchen außerhalb des Katalogs auf. Sie werden von Entwicklern hochgezogen, nicht von Ihnen provisioniert. Sie authentifizieren sich mehr als nur gelegentlich als gemeinsam genutzte Service-Accounts. Und die Hyperscaler haben das verschlimmert, indem sie Agentenidentität zu einem GA-Primitiv in drei wechselseitig inkompatiblen Registries gemacht haben.

Das Marktsignal ist unmissverständlich. Gartner erwartet, dass mehr als 40 % der agentischen KI-Projekte bis Ende 2027 eingestellt werden (Gartner, Presse), und die IBM-Studie Cost of a Data Breach 2025 (Ponemon) ergab, dass von den Organisationen, die einen KI-bezogenen Breach erlitten, rund 97 % keine angemessenen KI-Zugriffskontrollen hatten. Ein vorläufiges MIT-Ergebnis aus dem NANDA-Projekt — the GenAI Divide, via Fortune, August 2025, noch nicht peer-reviewed — berichtet, dass etwa 95 % der GenAI-Pilotprojekte keine messbare P&L-Wirkung zeigten und dass extern eingekaufte Tools etwa doppelt so oft erfolgreich waren wie interne Eigenentwicklungen. Bezogen auf die Aufgabe eines Plattformteams weist das in dieselbe Richtung: Ungoverntes, unmodelliertes Agenten-Wildwuchs ist der Ort, an dem der Wert abfließt und das Risiko eindringt.

Wie Olivares AI in die Plattform passt, die Sie bereits betreiben

Olivares AI ist eine offene, selbstgehostete Plattform, die die KI-Agenten auf Ihrer Infrastruktur erkennt, abbildet, was jeder von ihnen lesen und schreiben kann, und diesen Zugriff governt und auditiert. Das Designziel für Plattformteams ist nicht eine weitere Konsole — es ist, Agenten zu vollwertigen Bürgern der Plattform zu machen, die Sie bereits betreiben.

Agenten als vollwertige Katalogobjekte

Die Plattform erkennt Agenten, MCP-Server, Sessions und nicht-menschliche Identitäten und erstellt eine Zugriffskarte: einen Graphen jeder Agent → Datenbank / Store / API-Edge, jeweils als Lesezugriff (R) oder Lese-Schreib-Zugriff (RW) markiert. Dieser Graph ist der Katalogeintrag, den ein Agent von Anfang an hätte haben sollen — was er ist, was er berührt und ob das, was er berührt, dem entspricht, was er berühren darf.

Diese letzte Unterscheidung ist der Kern des Produkts. Edges werden als permitted vs observed klassifiziert, sodass Least-Privilege-Drift sichtbar wird statt angenommen zu werden. Siehe die Zugriffskarte und die Konzeptseite zu permitted vs observed.

Der Ehrlichkeitsvorbehalt ist hier wichtig, und wir halten ihn offen: Die R/RW-Genauigkeit ist gestuft. Die Abdeckung ist clean bei Quellen mit nativem Audit, lossy dort, wo Edges grob sind, und opaque dort, wo es überhaupt kein passives Lese-/Schreib-Signal gibt; die Zuordnung ist firm, wenn eine Quelle eine Identität pro Agent trägt, und approximate, wenn ein gemeinsam genutzter Account sie verbirgt. Die Karte zeigt die Stufe an, statt Sicherheit vorzutäuschen — siehe Fidelity.

Manage-as-Code: ein Terraform-/OpenTofu-Provider

Für ein Plattformteam ist Config-as-Code eine Selbstverständlichkeit. Olivares AI liefert terraform-provider-olivares aus, der Ihre eigene, selbstgehostete Control Plane deklarativ gegen ihre stabile API verwaltet. Der Provider stellt Resources und Data Sources für Agenten, Richtlinien, Deployments, Agentenidentitäts-Bindings, Budgets, Capability-Konfiguration und Notification-Routes bereit, mit import, Plan/Apply und Drift-Handling — sodass die Agenten, die Sie governen, auf dieselbe Weise reconciled werden, wie ArgoCD oder Flux bereits den Rest Ihres Bestands reconciled.

Ein Lizenzdetail, das wir präzise benennen, weil es sich vom Connector-SDK unterscheidet: Der Provider ist AGPL-3.0-only, nicht 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
}

Das obige HCL ist illustrativ für die Form, kein Copy-paste-Vertrag — generieren Sie gegen das eigene veröffentlichte Schema des Providers. Das Produkt ist pre-1.0: Behandeln Sie die Resource-Abdeckung so, als würde sie der API-Oberfläche folgen, und prüfen Sie die Modulreferenz für das, was heute verdrahtet ist.

Passend zu Ihrem IdP — Föderation, kein Ersatz

Olivares AI ist kein Identity Provider und versucht auch nicht, einer zu sein. Es föderiert Agentenidentität read-only: Es liest Verzeichnisse aus Microsoft Entra Agent ID, AWS AgentCore Identity und Google Agent Identity und gleicht sie gegen ein SPIFFE/WIF-Verzeichnis ab, sodass jede Edge in der Zugriffskarte eine feste oder annähernde Zuordnung trägt. Dedizierte Agenten- und Workload-Identitäten lösen zu einer festen Zuordnung auf; Blueprint-Principals, Credential-Provider und Service-Account-Agenten bleiben annähernd, statt zu einer fabrizierten Identität hochgestuft zu werden. Es stellt keine Credentials aus und schreibt nichts in diese Registries zurück — die Föderation ist strikt read-only.

Es bringt außerdem eine für die Plattformsicherheit nützliche Drift-Klasse zum Vorschein: langlebige statische Credentials, die auf Agentenidentitäten erkannt werden, im Einklang mit der Five-Eyes-Leitlinie 2026 hin zu kurzlebigen Credentials. SVID-basierte OAuth-Client-Authentifizierung (die Arbeit an draft-ietf-oauth-spiffe-client-auth) ist als design-toward implementiert — es gibt keinen Konformitätsanspruch, bis ein Authorization Server den passenden Flow veröffentlicht. Siehe Identität & Föderation.

Ein Portal-Ansatz: Backstage, read-first

Wenn Ihre Entwickler in Backstage leben, sollte auch das Agenten-Inventar dort leben. Das Designziel ist ein natives, read-first-Plugin — Inventar, Live-Sessions und die R/RW-Zugriffskarte, gerendert innerhalb des Portals und authentifiziert gegen die Control Plane — kein iframe und kein zweites Dashboard. Read-first ist bewusst gewählt: Es entspricht der Haltung des Produkts (siehe unten) und hält die Portal-Integration risikoarm.

CLI-first, mit einer stabilen API darunter

Die gesamte Plattform ist ein einziges Go-Binary, controlplane, das zu einem befüllten Zugriffsgraphen bootet; die Web-Konsole ist im selben Origin wie die API eingebettet. Alles, was Sie in der UI tun können, lässt sich über die CLI oder die OpenAPI-3.1-Oberfläche steuern, auf der der Terraform-Provider, ein Backstage-Plugin und Ihre eigene Automatisierung allesamt aufbauen. Beginnen Sie mit der Konfigurationsreferenz, dem CLI-Workflow und der MCP-Governance-Oberfläche.

Was es ist — und was es nicht ist

Dies ist ein sicherheitsgeprägtes Produkt, daher ziehen wir eine harte Linie bei dem, was es beansprucht.

• Read-first und deny-closed. Es beobachtet und governt breit; es aktuiert nicht breit. Die meiste Aktuierung ist live-on-demand oder eine deklarierte, deny-closed-Schnittstelle — ein Deploy-apply gibt 503 zurück, bis Sie einen Executor provisionieren, kein stiller No-op. Siehe permitted vs observed und die Seite Ehrlichkeit & Grenzen.
• Pre-1.0, Open-Core. Der Katalog umfasst 23 Module; rund 20 sind verdrahtet in einer Standardinstallation. Nichts hier impliziert, dass alle 23 vollständig live sind — die Modulreferenz markiert den Status pro Modul.
• Air-Gap meint hier die Control Plane, nicht Claude. Die Governance- und Beobachtungsebene läuft vollständig selbstgehostet und kann air-gapped betrieben werden. Claude-Inferenz ist niemals selbstgehostet — Anthropic veröffentlicht keine Weights, sodass jeder Claude-Aufruf eine API erreicht. Nur Modelle, die Sie wirklich selbst hosten (vLLM, Ollama), laufen offline. Siehe Security.
• Nicht zertifiziert. Es ist ausgerichtet auf EU AI Act, NIST AI RMF, ISO/IEC 42001, SOC 2 und andere, wobei die Audit-Nachweise aus einem Append-Only-Ledger mit Hash-Verkettung stammen. Es ist nicht SOC 2 / ISO / EU-AI-Act-zertifiziert. Siehe Compliance.
• Es ergänzt Ihre Control Tower; es beansprucht nicht, sie zu ersetzen. Identitätsföderation und Posture-Export sind per Design read-only.

Wenn Sie zuerst das architektonische Bild möchten, lesen Sie die Architektur; wenn Sie wissen möchten, wo wir relativ zu Gateways, Observability und Agent Control Towern stehen, siehe den Vergleich. Und wenn Sie die Lizenz und die Open-Core-Grenze abwägen, ist Open Source die ehrliche Version.

Verwandte Personas: Security-Verantwortliche, SRE & Sysadmin und Hochschulbildung.