Das Problem: Sie können nicht steuern, was Sie nicht sehen
Die Agenten sind längst da. Ein Coding-Assistent mit einem Datenbank-Credential, ein interner RAG-Dienst, der unbemerkt Schreibzugriff auf einen Object Store erlangt hat, ein geplanter Job, der einen MCP-Server aufruft, den niemand registriert hat. Sie wurden von Teams bereitgestellt, die schnell vorankommen wollten, und die Security-Organisation erbt den Blast Radius, ohne die Karte je gesehen zu haben. Analysten haben einen Namen für dieses Muster — Agent Sprawl — und die Governance-Lücke darunter ist messbar.
Von den Organisationen, die einen KI-bezogenen Sicherheitsvorfall erlitten, fehlten rund 97 % angemessene KI-Zugriffskontrollen (IBM Cost of a Data Breach 2025, Ponemon). Das ist keine Frage des Tooling-Reifegrads; es ist das Fehlen einer Steuerungsebene. Gleichzeitig erwartet Gartner, dass mehr als 40 % der Agentic-AI-Projekte bis Ende 2027 eingestellt werden, und prognostiziert, dass „Guardian Agents“ bis 2030 10–15 % des Agentic-AI-Markts ausmachen (Gartner, Presse) — der Markt preist bereits ein, dass ungesteuerte Agenten den Kontakt mit einem echten Security-Review nicht überstehen.
Das Muster reicht über Security-Teams hinaus. In einer vorläufigen, noch nicht peer-reviewten Studie zeigten rund 95 % der GenAI-Piloten keine messbare GuV-Wirkung, und extern eingekaufte Werkzeuge waren etwa doppelt so häufig erfolgreich wie interne Eigenentwicklungen (MIT „GenAI Divide“, NANDA-Projekt, via Fortune, Aug. 2025 — vorläufig). Was auch immer die Ursache ist: Eine Infrastruktur voller Agenten, für die niemand Rechenschaft ablegen kann, ist genau die Bedingung, unter der sich sowohl das Breach-Risiko als auch das Risiko vergeudeter Piloten potenziert.
Das lässt sich sauber auf das AI-TRiSM-Framework abbilden — Trust, Risk and Security Management für KI —, in dem Governance und Runtime-Inspektion als eigenständige Schichten verortet sind. Olivares AI ist darauf ausgelegt, die Schicht zu sein, die Agentenzugriffe aufspürt, beobachtet und steuert — und es ist ehrlich darüber, wo das endet.
Was Olivares AI einem Security-Verantwortlichen bietet
Eine typisierte Lese-/Schreib-Zugriffskarte als Steuerungsebene
Die Zugriffskarte modelliert jeden Agenten als Knoten und jede Ressource, die er erreichen kann — Datenbanken, Object Stores, MCP-Server, APIs, Queues — als Knoten, wobei jede Kante mit R (Lesen) oder RW (Lesen-Schreiben) typisiert ist. Genau diese R-gegen-RW-Typisierung ist der Kern: Least-Privilege-Drift und der Blast Radius eines Vorfalls sind beide eine Funktion des Schreib-Zugriffs, nicht bloßer Konnektivität, und eine flache „hat Zugriff“-Liste verbirgt genau das. Das ist Reconnaissance für Verteidiger — dieselbe Karte, die ein Angreifer haben wollte, gebaut für die Menschen, die die Infrastruktur verteidigen.
Den vollständigen Graphen zu lesen, ist bewusst eine privilegierte, tenant-gebundene und vollständig auditierte Aktion, denn eine komplette Karte dessen, was jeder Agent berühren kann, ist selbst eine Recon-Roadmap. Die Karte speichert die Beziehung — Ursprung, Ressource, R/RW, Quelle, Confidence, Zeitstempel — und niemals die Payloads, SQL-Bodies, Secrets oder PII, die über die Kante geflossen sind. Was nicht gespeichert wird, kann nicht abfließen.
Erlaubt vs. beobachtet: Der Abgleich, der zum Befund wird
Jede Kante trägt zwei voneinander unabhängige Fakten: ob der Zugriff erlaubt ist (eine Berechtigung oder Policy lässt ihn zu) und ob er beobachtet wurde (Telemetrie und native Audit-Daten zeigen, dass er stattfindet). Der Abgleich zwischen diesen beiden Schichten ist das Steuerungssignal:
- Unerwarteter Zugriff — beobachtet, aber nicht erlaubt. Ein Agent hat etwas berührt, das keine Berechtigung abdeckt. Das ist die sicherheitsrelevante Schlagzeile.
- Ungenutzte Berechtigungen — erlaubt, aber nie beobachtet. Ihre konkrete Least-Privilege-Aufräumliste, nicht eine vage „Prüfen Sie Ihr IAM“-Erinnerung.
Der Abgleich ist bewusst konservativ. Wo die Plattform ein handelndes Credential noch nicht
zuverlässig mit dem Agenten verknüpfen kann, für den die Berechtigung geschrieben wurde, wird die
Kante als reconciliation_pending markiert — ehrliche Unsicherheit, niemals eine erfundene
Verletzung. Siehe erlaubt vs. beobachtet für den
vollständigen Reconciliation-Vertrag.
Genauigkeit, die nicht mogelt
Ein Security-Werkzeug, das übertreibt, was es weiß, ist schlimmer als keines. Jede Kante trägt
zwei ehrliche Achsen. Die Abdeckung der R/RW-Klassifizierung ist gestuft
clean | lossy | opaque — clean dort, wo native Audit-Daten sie eindeutig machen (Postgres
über pgAudit, Object Storage über CloudTrail, die Warehouses, plus ein eBPF-Backstop auf
Kernel-Ebene), bis hinunter zu opaque-Stores (Redis, SQLite, D1), bei denen der Modus als
unknown markiert wird, statt geraten zu werden. Die Attribution ist firm, wo ein
Identitätssignal pro Agent den Zugriff einem einzelnen Agenten zuordnet, und approximate, wo
ein gemeinsam genutzter Service-Account verbirgt, welcher Agent gehandelt hat. Eine
clean/firm-Kante und eine kaum gesehene werden niemals als gleich sicher dargestellt — lesen
Sie das Fidelity-Modell.
Deny-closed Governance, Zwei-Personen-Kontrolle und ein Kill-Switch
Governance ist read-first und deny-closed. Der Autorisierungskern ist deny-by-default und tenant-gebunden und schließt Confused-Deputy- und IDOR-Klassen konstruktionsbedingt aus. Jede attributbasierte Policy, die Sie darüberlegen, kann nur weiter einschränken — die Komposition ist eine Schnittmenge, sodass eine Policy eine Berechtigung niemals ausweiten kann.
Wo das Produkt eine Aktion gated, lautet die Schleife: Eine Oberfläche präsentiert (Drift, einen
Befund) → ein autorisierter Operator entscheidet → die Entscheidung wird festgehalten. Die
Freigabe-Engine erzwingt Funktionstrennung (ein Antragsteller kann seinen eigenen Antrag nicht
entscheiden) und einen Schutz gegen doppelte Entscheider, verankert an einer stabilen
menschlichen Identität — ein System-Token hat keine Identität und kann nicht entscheiden. Eine
critical-Aktion trägt eine verpflichtende Zwei-Personen-Untergrenze abgeleitet aus NIST
SP 800-53 AC-3(2), erzwungen sowohl beim Anlegen als auch neu hergeleitet beim Entscheiden,
sodass selbst eine Operator-Policy, die das Tier herabsetzt, eine kritische Aktion nicht im
Alleingang ermöglichen kann. Ein auditiertes Break-Glass-Ventil existiert für den Vorfall um
03:00 Uhr — konstruktionsbedingt laut, hardwaregestützt hochgestuft, zeitlich begrenzt und in
eine Nachprüfung gezwungen.
Der Kill-Switch ist das infrastrukturweite Deny-Gate. Das Auslösen ist bewusst günstig (Admin-Tier, eine Begründung, kein Quorum), denn ein Stopp, der auf Konsens wartet, ist kein Stopp; jedes gesteuerte Aktuierungs-Gate konsultiert die Stop-Row live und wird bei einem Lesefehler geschlossen. Das Reaktivieren ist niemals einseitig — es ist an eine frische Zwei-Personen-Freigabe gebunden und hat keinen Break-Glass-Pfad, denn „die Infrastruktur bleibt gestoppt“ ist der sichere Zustand.
Manipulationssichere Nachweise
Jede verändernde Aktion wird in derselben Transaktion wie die Änderung an ein append-only, hash-verkettetes Audit-Ledger angehängt, mit dem tatsächlichen Akteur; sensible Lesezugriffe auditieren sich selbst in einem committeten Schreibvorgang. Das Umschreiben von Historie ist erkennbar, und das Ledger enthält niemals PII. Das Compliance-Modul bildet diese Runtime-Nachweise auf Control-Frameworks ab, sodass eine Bewertung aus beobachteter Realität gespeist wird statt aus einem Fragebogen.
Was dies ist — und was nicht
- Selbstgehostet und souverän. Die Control Plane läuft auf Ihrer eigenen Infrastruktur und kann air-gapped werden. Olivares AI ist eine offene, selbsthostbare Plattform (AGPL-3.0). Siehe Sicherheitsmodell und Architektur.
- Standardmäßig detektivisch; deny-closed dort, wo es handelt. Es beobachtet und steuert breit; es aktuiert nicht breit. Wo es eine Aktion ausführen kann, ist diese Oberfläche live, on-demand oder eine deklarierte Naht — und der Modulkatalog kennzeichnet, welche. Das Fehlen von Enforcement ist meist beabsichtigt.
- Pre-1.0, mit einem veröffentlichten Katalog von 23 Modulen (heute rund 20 verdrahtet). Nicht alles ist live; wir sagen, was was ist, statt vollständige Abdeckung zu suggerieren.
- Air-Gap gilt für die Olivares Control Plane, nicht für Ihre Modelle. Ein gehostetes Modell wie Claude ist niemals air-gapped; nur selbstgehostete Modelle (vLLM, Ollama) laufen offline. Olivares steuert den Zugriff in beiden Fällen.
- Nicht zertifiziert. Olivares AI ist ausgerichtet auf SOC 2, ISO/IEC 42001 und den EU AI Act; es besitzt keine Zertifizierung und wir behaupten auch keine.
Hochschul- und Forschungsumgebungen haben eine parallele Variante dieses Problems — breite KI-Nutzung über Lehrende und Mitarbeitende hinweg, während formale KI-Governance und die Abdeckung durch Nutzungsrichtlinien hinterherhinkt (EDUCAUSE-Forschung, 2025). Wenn das Ihr Kontext ist, siehe Hochschulbildung; Plattform-Teams, die die Infrastruktur betreiben, sollten bei Platform Engineering beginnen.
Wie es weitergeht
- Zugriffskarte — der typisierte R/RW-Graph und das Erlaubt-vs.-Beobachtet-Overlay an einem echten Capture.
- Kill-Switch — das infrastrukturweite Deny-Gate in Produktbegriffen.
- Compliance — manipulationssichere Nachweise, abgebildet auf Control-Frameworks.
- Governance-Konzepte — read-first, deny-closed, Zwei-Personen-Kontrolle.
- Vergleich — wie sich Olivares neben Gateways, Observability und Control Towers einfügt.
- Loslegen — die Karte an einer Demo-Infrastruktur sehen.