Das Cockpit für die KI-Agenten, die auf Ihrer Infrastruktur laufen

Sie betreiben bereits die Dashboards für alles andere im Estate: Hosts, Queues, Datenspeicher, den Request-Pfad. Dann tauchen ein Dutzend KI-Agenten auf — Copilots, MCP- Server, geplante Jobs, eine Claude-Code-Instanz, die jemand mit der Produktion verdrahtet hat — und Sie haben keinen einzigen Ort, der die erste Frage des Betreibers beantwortet: Was läuft, und was kann jedes einzelne Ding tatsächlich erreichen?

Das ist dasselbe Muster wie nicht verwaltete Schatten-Infrastruktur, nur dass die Workloads Credentials halten und eigenständig handeln. Von den Organisationen, die einen KI-bezogenen Breach erlitten, fehlten rund 97 % angemessene KI-Zugriffskontrollen (IBM Cost of a Data Breach 2025, Ponemon). Die Branche hat inzwischen einen Begriff für die Ursache — Agent Sprawl — und Gartner erwartet, dass bis Ende 2027 mehr als 40 % der agentischen KI-Projekte abgebrochen werden (Gartner), oft weil niemand sie sicher betreiben konnte, sobald sie sich vervielfachten.

Was ein Betreiber erhält

Olivares AI ist eine offene, selbstgehostete Plattform, die dort läuft, wo Ihre Agenten laufen. Sie entdeckt sie, baut eine Read/Write-Access Map von dem auf, was jeder berührt, und gibt Ihnen die Kontrollen, um diesen Zugriff zu governen und zu auditieren. Für einen SRE oder Sysadmin zählen fünf Eigenschaften mehr als die Feature-Liste.

Passiv — nicht im Request-Pfad

Discovery wird aus Telemetrie und quellennativem Audit out of band aufgebaut. Die Health- und Reliability-Sicht ist ein Konsument des Event-Bus, kein Prober, der Sockets in Ihre Infrastruktur öffnet — Liveness wird aus beobachteter Aktivität abgeleitet, und ein Agent, der aufhört zu emittieren, ist selbst ein Signal. Da Olivares kein Proxy oder Sidecar vor Ihren Agenten ist, kann ein Ausfall von Olivares sie nicht lahmlegen. Die einzigen Flächen, die jemals inline sitzen, sind die optionalen Actuation-Gates, die Sie einzubinden wählen, und diese schlagen closed fehl.

Eine selbstgehostete statische Binary

Die Auslieferung erfolgt als einzelne statische Binary mit eingebetteter Web-Konsole — keine Agent-Flotte zum Ausrollen, kein Control-Plane-Kubernetes-Operator zum Babysitten. Der Store ist Pure-Go-SQLite (Postgres für Multi-Tenant), es gibt also keine C-Toolchain, gegen die Sie kämpfen müssen. Sie installieren eine einzige Datei, betreiben sie als dedizierten Service-User, und Sie haben das Cockpit. Siehe Installation & Self-Hosting.

Die Control Plane läuft innerhalb Ihres Perimeters und kann air-gapped betrieben werden — Ihre Governance- und Beobachtungsdaten verlassen ihn nie. Eine Einschränkung, die Betreiber im Hinterkopf behalten sollten: Dies ist keine Offline-KI. Gehostete Modelle wie Claude erreichen weiterhin die API des Anbieters; air-gapped bedeutet, dass Ihre Estate-Daten zu Hause bleiben, nicht dass das Modell lokal läuft. Nur tatsächlich selbstgehostete Modelle (vLLM, Ollama) laufen vollständig offline. Mehr unter Security und Architektur.

OTel-native Ingest

Der Ingest-Pfad fixiert die OpenTelemetry GenAI Semantic Conventions neben OCSF, den SIEM-Formaten und dem W3C Trace Context — sodass die Telemetrie, die Sie bereits emittieren, genau die Telemetrie ist, die er liest. Eine ehrliche Grenze: Olivares korreliert Ihr Ledger gegovernter Events anhand der W3C-trace_id; es speichert keine vollständigen OTel-Spans. Dauern und Status in der Trace-Ansicht sind Ledger-Event-Fenster, keine rekonstruierten Span-Daten. Die vollständigen Spans bleiben in Ihrem eigenen OTLP-Collector, wo sie hingehören. Olivares sagt Ihnen, wer was berührt hat und ob es erlaubt war — es ist kein Ersatz für Ihr Tracing- Backend. (Siehe die Vergleichsseite dafür, wo es neben LiteLLM/Langfuse einzuordnen ist.)

Probes und Health, wie bei jedem Dienst, den Sie betreiben

Die Binary stellt die Endpunkte bereit, die Ihr Orchestrator bereits erwartet:

GET /livez     liveness  — is the process up
GET /readyz    readiness — is it serving (and not a cold standby)
GET /healthz   setup-exempt liveness for scrapers
GET /metrics   Prometheus exposition

/readyz gibt 503 zurück, wenn der unterliegende Store nicht erreichbar ist, statt zu hängen, sodass ein Load Balancer den Knoten drainiert, statt ihn ins Leere laufen zu lassen. Darüber hinaus verfolgt Modul XXII die Health, SLA und Uptime der Agenten und MCP-Server selbst — was gesund ist, was degradiert ist und was wovon abhängt — und emittiert Down-/Degraded-/ Recovered-/SLA-Breach-Findings an Ihre bestehende Schiene (Slack, PagerDuty, SIEM). Es produziert das Signal; es versucht nicht, Ihr Notifier zu sein.

Read-first, mit einem echten estate-weiten Stopp

Olivares ist standardmäßig detektivisch und deny-closed. Es beobachtet und governt breit; es aktuiert nicht breit. Aber wenn ein Agent um 3 Uhr morgens entgleist, braucht ein Betreiber einen Hebel, der ohne Zeremonie funktioniert — daher ist der Kill-Switch real und dafür gebaut, eingesetzt zu werden:

• Das Auslösen ist günstig. Admin-Tier, ein verpflichtender Grund, ein Klick. Es gibt keinen Genehmigungs-Gate und kein Step-up beim Auslösen — ein Notstopp, der auf ein Quorum wartet, ist kein Stopp. Der estate-weite Scope verweigert jede gegovernte Actuation-Fläche für den Tenant; der Agenten-Scope stoppt einen Agenten über jede Fläche hinweg, auf der er benannt werden kann.
• Das Reaktivieren ist es nicht. Das Aufheben eines Stopps erfordert Dual-Control (zwei verschiedene Personen) und wird von einem verpflichtenden Post-Review gefolgt, das eine dritte, unbeteiligte Person unterzeichnen muss. “Das Estate bleibt gestoppt” ist der sichere Zustand.
• Es schlägt closed fehl. Jedes Actuation-Gate konsultiert den Live-Stopp-Zustand pro Aufruf und verweigert bei einem Lesefehler — ein unlesbarer Stopp bedeutet niemals “go”.

Seien Sie ehrlich zu sich selbst beim Scope: Der Stopp ist nur so weit wie die Gates, die Sie eingebunden haben. Er kann keine Fläche einfrieren, in die Olivares keine Naht hat. Das ist der bewusste Kompromiss eines Read-first-Systems — und es ist der Grund, warum Discovery und die Map zuerst kommen.

Was es ist — und was es nicht ist

• Es ist ein passives, selbstgehostetes Cockpit: Agenten entdecken, ihren Read/Write-Zugriff kartieren, ihre Health überwachen und einen estate-weiten Stopp einen Klick entfernt halten.
• Es ist kein Inline-Proxy, kein Tracing-Backend und kein System, das Ihre Agenten still umverdrahtet. Actuation ist opt-in, on-demand und deny-closed — Sie binden jede Naht bewusst ein.
• Es ist pre-1.0 und Open-Core. Der Katalog listet 23 Capability-Module; rund zwanzig sind heute verdrahtet, der Rest befindet sich im Design-Stadium oder ist post-v1. Die Modul-Referenz markiert, was live ist.
• Es ist nicht zertifiziert. Olivares ist ausgerichtet auf SOC 2, ISO/IEC 42001 und den EU AI Act — es hält diese Zertifizierungen nicht und wird es nicht behaupten. Siehe Security für die ehrliche Haltung.
• Die Fidelity ist gestaffelt und wird auch so ausgewiesen. Die Read-vs-Write-Abdeckung ist clean bei Stores mit nativem Audit, lossy bei einigen Dokument-/Vektor-Stores und unknown, wo sie sich nicht passiv rekonstruieren lässt (Redis, SQLite, D1); die Zuordnung pro Agent ist nur dann firm, wenn das Signal es trägt, und approximate hinter einem geteilten Account. Nichts wird geraten. Siehe Fidelity.

Wo Sie anfangen

• Aufsetzen: Self-Hosting, dann der Quickstart für ein synthetisches Estate.
• Ihr erstes Signal verdrahten: eine Quelle anbinden.
• Das Modell verstehen: permitted vs observed und die Access Map.
• Betreibernahe Personas: Platform Engineering und Security Leaders.