Ehrlichkeit und Grenzen

Eine Plattform, die die KI-Agenten auf Ihrer Infrastruktur steuert, ist ein Sicherheitsprodukt. Wenn sie übertreibt, was sie abdeckt, vermittelt sie ein falsches Sicherheitsgefühl — was schlimmer ist als kein Tool überhaupt. Daher ist diese Seite der explizite Vertrag: Was heute läuft, was in der Designphase ist, und was absichtlich außerhalb des Geltungsbereichs liegt. Der Rest der Dokumentation hält sich daran. Wo das Produkt etwas noch nicht abdeckt, sagt die Seite das, anstatt es zu implizieren.

Olivares AI ist pre-1.0 und Open-Core. Behandeln Sie die Modul-Level-Tiefe als Work in Progress, sofern eine Seite nicht anders angibt.

Was heute läuft

• Ein einzelnes Binary startet mit einem bevölkerten Zugriffsgraphen. Das Control-Plane-Binary kompiliert zu einem statischen Artefakt mit eingebetteter Web-UI. Das Starten gegen die synthetische Demo-Umgebung und das Durchlaufen von Entdecken → R/RW-Graph → Erlaubt-vs-Beobachtet-Drift → Inventar wird Ende-zu-Ende von der Testsuite geprüft. Der Schnellstart reproduziert diesen Pfad.
• Der erste Start ist credential-frei. Eine frische Installation hat keine Standard-Credentials. Beim ersten Start, ohne vorhandene Benutzer, prägt die Engine einen einmaligen, einmal verwendbaren Setup-Token und gibt ihn auf stdout aus (nie in die Logs); Sie tauschen ihn ein, um den ersten Administrator zu erstellen.
• Die REST-API und das Audit-Ledger sind real. Die öffentliche Oberfläche wird durch den eigenen OpenAPI 3.1-Vertrag des Produkts beschrieben. Das Audit-Ledger ist nur-anhängend und hash-verkettet, mit signierten Checkpoints, und kann in SIEM-Formate für Offline-Reverifikation exportiert werden.
• Das Release-Signing ist gebaut und offline verifizierbar — die Nachweise erscheinen mit dem ersten öffentlichen Release. Jeder getaggte Release trägt cosign-Signaturen, SLSA-Provenienz und SBOMs (SPDX und CycloneDX). All dies kann ohne Netzwerkzugang verifiziert werden. Schlüsselbasiertes (nicht-OIDC) Signieren wird für air-gapped Build-Pipelines unterstützt, und ein Air-Gap-Bundle wird für Installationen ohne Egress ausgeliefert.

Was in der Designphase oder pre-1.0 ist

Der Katalog umfasst 29 Module; alle sind in einer Standardinstallation heute verdrahtet. Siehe die Modul-Referenz für den Status pro Modul.

Die R/RW-Karten-Genauigkeit ist gestuft, beabsichtigt

Die Genauigkeit hängt davon ab, was die Quelle beweisen kann, und die Zugriffskarte zeigt das ehrlich, anstatt Sicherheit vorzutäuschen. Siehe Genauigkeit für das vollständige Modell.

• Abdeckung ist clean bei Speichern mit nativem Audit (SQL, Objektspeicher, Data Warehouses/Lakes), lossy bei Dokument- und Vektorspeichern, wo Kanten existieren, aber grob sind, und opaque, wo es überhaupt kein passives Lese-/Schreibsignal gibt (zum Beispiel Redis, SQLite, D1). Wo Lesen versus Schreiben nicht bestimmt werden kann, wird die Kante als unknown markiert.
• Zuordnung ist firm, wenn eine Quelle eine Pro-Agent-Identität trägt, und kollabiert zu approximate, wenn ein gemeinsames Dienstkonto dies verbirgt. Alles Unaufgelöste bleibt approximate — nie stillschweigend zu einem fabrizierten Agenten befördert.

Quellen: Host-Observer verdrahtet; einige Konnektoren laden on demand

Die Kompositionswurzel registriert die Host-Level-R/RW-Observer im Standard-Serve-Pfad, konfigurierbar über die Quellkonfiguration. Mehrere Quellkonnektoren sind gebaut, aber noch nicht in den Standard-Serve verdrahtet — zum Beispiel die Wissensdokument-Quellen, die on demand durch Ingest-Anfragen geladen werden, anstatt als stehende Observer zu laufen. Der Leitfaden Eine Quelle verbinden und die Modul-Referenz markieren, welche welche sind.

Der Standard ist ein Binary; der verteilte Bus ist opt-in

Die Standardinstallation läuft als einzelnes Binary mit einem In-Process Event Bus — blockierender Gegendruck, kein lokaler Verlust. Eine verteilte NATS-Bridge ist gebaut und für Scale-Out-HA verdrahtet, opt-in über die Bus-Konfiguration; ein falsch konfigurierter Bus lässt den Start fehlschlagen, anstatt stillschweigend zu partitionieren. Cross-Node-Zustellung über die Bridge ist ehrlich als at-most-once dokumentiert (der In-Process-Capture ist die Dauerhaftigkeitsgrenze); Verluste werden in Metriken gezählt, nie stillschweigend.

Gesteuerte Ausführung hat drei ehrliche Zustände

Die Plattform beobachtet und steuert breit; sie führt nicht breit aus. Lesen Sie Erlaubt vs Beobachtet für den Grund, warum diese Linie wichtig ist. Ausführung fällt in drei Zustände:

• Live im Standard-Binary, keine Bereitstellung: FinOps-Budget-Durchsetzung (ein durchsetzendes Budget bei seiner Obergrenze verweigert die Ausgabe — in-process, immer verdrahtet), Benachrichtigungsdispatch sobald ein Ziel konfiguriert ist, Sicherheitsdetektiv-Befunde, und der In-Process-synthetische Sandbox-Runner.
• On-demand — Backend gebaut und verdrahtet, aber standardmäßig-ablehnend oder degradiert, bis ein Operator es bereitstellt: Deploy apply/retire (ein 503 bis ein Executor bereitgestellt wird), Orchestrierung fire und Voice-Dispatch (standardmäßig-ablehnend bis ein Dispatcher konfiguriert ist), die isolierte Sandbox/Red-Team-Runtime (synthetisch bis bereitgestellt), und Modell-Ausführung (ein 503 bis ein Inferenz-Credential konfiguriert ist).
• Naht — eine deklarierte, standardmäßig-ablehnende Schnittstelle ohne Backend.

Air-Gap gilt für die Steuerungsebene, nicht für Claude-Inferenz

Das ist die wichtigste Einschränkung. Die Steuerungsebene — Governance und Beobachtung — läuft vollständig selbst gehostet und kann air-gapped werden: Einzelknoten, signierter Offline-Release, Air-Gap-Bundle.

Claude selbst ist nicht selbst-hostbar. Anthropic veröffentlicht keine Gewichte, sodass jede Claude-Inferenz Anthropics API erreicht, direkt oder über Bedrock / Vertex / Foundry. In Olivares AI sind diese Inferenz-Nähte fail-closed: Ohne Inferenz-Credential bleibt der LLM-Judge übersprungen und Embeddings fallen auf einen Zero-Egress-lokalen Embedder zurück. “Air-gapped” bedeutet hier, dass Ihre Governance- und Beobachtungsebene und ihre Daten innerhalb Ihres Perimeters bleiben — es bedeutet nicht, dass Claude offline läuft. Nur Modelle, die Sie wirklich selbst hosten (zum Beispiel über vLLM oder Ollama unter dem Modell-Management-Modul), können air-gapped laufen; vermittelte Frontier-Modelle können das nicht. Siehe Claude Code verbinden und Sicherheit.

Nicht alle Modul-Routen sind im öffentlichen API-Vertrag

Einige Modul-Endpunkte (zum Beispiel der Zugriffskarten-Graph und Drift) sind erreichbar, aber sind bewusst nicht Teil des bereitgestellten OpenAPI-Dokuments; ihre Feld-Level-Verträge befinden sich in den typisierten Interfaces des Produkts. Die CLI- und Konfigurations-Referenzen decken die operative Oberfläche ab; der OpenAPI-Vertrag ist die REST-Kernoberfläche, nicht das gesamte Produkt.

Nicht zertifiziert

Olivares AI ist darauf ausgelegt, SOC 2, ISO 27001 und den EU AI Act zu erfüllen — es ist nicht zertifiziert gegen eine davon. Siehe Compliance für die Bedeutung von “darauf ausgelegt” und welche Nachweise die Plattform produziert.

Was das Produkt bewusst nicht tut

• Keine offensiven Funktionen. Dies ist kein Command-and-Control-Framework und scannt keine Credentials anderer. Die Zugriffskarte ist Aufklärung für Verteidiger, um ihre eigene Umgebung zu steuern — das Anzeigen ist eine privilegierte, mandantenbezogene, vollständig auditierte Aktion. Die Verteidigungslinie ist beabsichtigt.
• Kein nativer Splunk-S2S-Forwarder. Die Weiterleitung an Splunk ist eine dokumentierte Haltung (richten Sie einen Universal Forwarder auf eine Datei, die die Steuerungsebene anhängt, oder pushen Sie über Splunk HEC), kein nativer Splunk-zu-Splunk-Emitter.
• Keine ausgehenden Webhooks im REST-Vertrag. Das OpenAPI-Dokument definiert keine webhooks. Signierte ausgehende Zustellung existiert als internes Benachrichtigungsziel, und der eingehende SCIM Security-Event-Token-Endpunkt ist ein Empfänger — keiner von beiden ist ein OpenAPI-Webhook.
• Kein Fine-Tuning vor v1. Modell-Fine-Tuning (das Modell-Management-Modul) ist post-v1. Sein Fehlen ist eine Entscheidung, keine Lücke.

Ein Hinweis zum Audit-Export

Der CLI-Ledger-Export zielt auf cef, syslog und otlp. Der Eventing-Push-Pfad zu einem SIEM rendert einen breiteren Dialekt-Satz (einschließlich OCSF und LEEF), wenn ein Sink konfiguriert ist. Der Pull-Export hat die richtige Form für WORM-Archivierung und Offline-Reverifikation.

Wenn Sie einen Befehl finden, der sich nicht wie dokumentiert verhält, ist das ein Fehler in der Dokumentation oder dem Produkt — bitte melden Sie ihn. Diese Seite ist der Vertrauensanker; alles andere verweist auf sie.