Zum Inhalt springen

Produkt · Access Map

Sehen Sie, was jeder Agent erreichen kann — lesen versus schreiben

Für jeden Agenten, jede Session und jede Identität zeigt die Access Map die berührten Ressourcen, trennt Lese- von Schreibzugriffen und meldet den Moment, in dem der beobachtete Zugriff von dem abweicht, was Sie erlaubt haben. Passiv aus Signalen erschlossen, die Sie bereits haben — kein Proxy im Datenpfad.

Im Produkt

Die Karte, direkt aus der echten Konsole

Ein echter Screenshot der Olivares-Konsole, gefüllt mit Beispieldaten. Ursprünge links, die berührten Ressourcen rechts, eingefärbt nach Lesen, Schreiben/RW, unbekannt und näherungsweise. Das Öffnen der Karte ist eine privilegierte, auditierte Aktion — sie zeigt Beziehungen, niemals SQL, Payloads oder Secrets.

Echter Screenshot
Agenten und Sessions links erreichen Datenbanken, Object Stores, APIs und Integrationen rechts. Die Kantenfarbe codiert Lesen versus Lesen/Schreiben; eine Kante ist als unerwarteter Schreibzugriff markiert — Least-Privilege-Drift.
Echter Screenshot
Wechseln Sie zu „erlaubt vs. beobachtet“, und die Karte vergleicht Ihre Berechtigungen mit dem tatsächlichen Zugriff: was beobachtet, aber nie erlaubt wurde, und was erlaubt, aber nie genutzt wurde.

Das Modell

Lesen, schreiben und das ehrliche Unbekannte

Olivares klassifiziert jeden Zugriff am Connector, aus dem Statement oder Verb selbst — der SQL-Art, der HTTP-Methode, der Semantik des MCP-Tools, dem Öffnungsmodus der Datei. Erfasst wird die Beziehung, niemals das Statement: kein SQL-Text, keine Parameter, keine Payloads, keine Secrets.

Lesen

Ein Agent, der eine Ressource nur liest — ein SELECT, ein GET, ein schreibgeschützter Tool-Aufruf. Ruhig dargestellt, neutral.

Lesen / Schreiben

Ein Agent, der eine Ressource verändern kann — ein INSERT oder UPDATE, ein schreibendes Tool, ein mutierender Aufruf. Die Kanten, die Ihren Auswirkungsbereich bestimmen.

Unbekannt · näherungsweise

Wo ein Store kein Audit pro Identität bietet oder das Signal schwach ist, sagt Olivares das auch — eine gestrichelte, zurückgenommene Kante — statt Gewissheit zu erfinden.

Least-Privilege-Drift

Erlaubt versus beobachtet — der Befund, der zählt

Drift ist die Lücke zwischen dem Zugriff, den Sie gewährt haben, und dem Zugriff, der tatsächlich stattfindet. Olivares gleicht eine einem Agenten zugeschriebene Beobachtung mit der Identität ab, die dieser Agent wirklich nutzt, und legt drei ehrliche Zustände offen.

  • Unerwarteter Zugriff

    Beobachtet, aber nie erlaubt. Der Befund mit höchster Priorität — ein Zugriff, der ohne dahinterstehende Berechtigung stattfindet.

  • Abgleich ausstehend

    Beobachtet ohne passende Berechtigung, doch die Verknüpfung von Agent zu Identität ist noch ungeklärt. Als ausstehend ausgewiesen, nicht als gesicherter Verstoß — ehrliche Unsicherheit, kein konstruierter Alarm.

  • Ungenutzte Berechtigungen

    Erlaubt, aber nie beobachtet. Eine Überprovisionierung, die es zu straffen gilt — Least Privilege, andersherum.

So funktioniert es

Von Berechtigungen und Beobachtungen zu einem einzigen Urteil

Olivares nimmt, was Sie erlaubt haben, und was es beobachtet hat, gleicht beides über alle Ursprünge hinweg ab und stellt das Ergebnis dar: eine Übereinstimmung, eine Drift oder eine Beziehung, die es nur deklarieren kann — niemals eine, die es zu sehen vorgibt.

Diagramm: Erlaubte Berechtigungen und beobachteter Zugriff werden verglichen; Übereinstimmungen werden bestätigt, Abweichungen orange als Drift markiert und deklarierte, aber nie beobachtete Beziehungen gestrichelt gezeichnet.
Erlaubt vs. beobachtet, abgeglichen über alle Ursprünge. Gestrichelt bedeutet deklariert, nie beobachtet — ehrlich dargestellt, nicht versteckt.

Abdeckung, ehrlich benannt

Zwei Genauigkeitsachsen — und wir täuschen keine vor

Wie gut eine Ressource auditiert werden kann und wie eindeutig ein Zugriff einem bestimmten Agenten zuzuordnen ist, sind zwei verschiedene Dinge. Olivares zeigt beides, pro Knoten, und stuft sauber ab, statt zu raten.

Ressourcenabdeckung

Wie vollständig sich die Ressource selbst auditieren lässt.

Sauber
Natives Audit-Logging — Postgres pgAudit, AWS CloudTrail und Ähnliches. Volle Genauigkeit pro Zugriff.
Verlustbehaftet
Dokument- und Vector Stores: teilweises Signal, als teilweise ausgewiesen — nicht aufgerundet.
Opak
Redis, SQLite, D1 und dergleichen bieten kein Audit pro Identität. Als opak markiert, niemals stillschweigend aufgewertet.

Ursprungszuordnung

Wie eindeutig sich ein Zugriff auf einen bestimmten Agenten zurückführen lässt.

Eindeutig
Eine dedizierte nicht-menschliche Identität — pro Agent ausgestellte SPIFFE/WIF-Anmeldedaten. Durchgezogen gezeichnet.
Näherungsweise
Ein geteiltes oder gepooltes Konto: Der Zugriff ist real, der Agent ist mehrdeutig. Gestrichelt gezeichnet, als näherungsweise gekennzeichnet.
Unbekannt
Überhaupt kein Identitätssignal. Zurückgenommen — und niemals zu einem benannten Agenten heraufgestuft.

Die beiden Achsen sind unabhängig: Ein Zugriff auf einen opaken Store kann dennoch eindeutig zugeordnet werden, wenn ein kooperierendes Signal den Agenten benannt hat. Was Olivares nicht tut, ist, Näherungsweises oder Unbekanntes so darzustellen, als wäre es eindeutig.

Was real ist

Gebaut und verifiziert — und ehrlich an den Rändern

Die Access Map hat ihr technisches Proof-of-Concept-Gate bestanden und ist der Autor des Graphen. Zwei ehrliche Anmerkungen:

  • Das Öffnen der Karte ist eine privilegierte, auditierte Aktion: Jede Abfrage versiegelt einen Eintrag im Append-only-Ledger. Sie dient der defensiven Prüfung — Beziehungen, keine Inhalte.
  • Die Genauigkeit hängt von Ihren Quellen ab. Binden Sie natives Audit (pgAudit, CloudTrail) und Identitäten pro Agent ein, und die Karte ist am schärfsten; ohne sie zeigt Olivares die niedrigere Genauigkeitsstufe statt einer selbstgewissen Fiktion.

Access Map — Fragen

Braucht es einen Proxy oder einen Inline-Agenten?

Nein. Olivares erschließt Zugriffe passiv aus Signalen, die Sie bereits haben — natives Datenbank-Audit, Cloud-Audit-Logs, OpenTelemetry, eBPF und MCP-Introspektion. Es gibt keinen zwingenden Proxy im Datenpfad und nichts, das betreut werden muss.

Speichert die Karte mein SQL, meine Payloads oder Secrets?

Nein. Jeder Zugriff wird aus dem Verb klassifiziert — der SQL-Art, der HTTP-Methode, der Semantik des Tools — und als Beziehung erfasst: Ursprung, Ressource, Lesen oder Schreiben. Der Statement-Text, Parameter, Payloads und Secrets werden nie erfasst.

Was ist mit Stores ohne Audit pro Identität, etwa Redis?

Sie werden als opake Abdeckung markiert. Olivares zeigt die Beziehung in der Genauigkeit, die es tatsächlich belegen kann, und kennzeichnet die Grenze, statt eine Zuordnung pro Identität zu erfinden, die der Store nicht unterstützt.

Wie unterscheidet es Lesen von Lesen/Schreiben?

Aus dem Statement oder Verb selbst, klassifiziert am Connector — ein SELECT gegenüber einem INSERT oder UPDATE, ein GET gegenüber einer mutierenden Methode, ein schreibgeschützter gegenüber einem schreibenden Tool-Aufruf. Die Kantenfarbe folgt daraus: Lesen, Schreiben/RW oder unbekannt, wenn das Signal schwach ist.

Sehen Sie Ihre eigene Access Map

Stellen Sie Olivares auf Ihrer eigenen Infrastruktur bereit, richten Sie es auf Ihre Audit-Quellen aus und erhalten Sie die Read/Write-Map, nach der Ihre Plattform- und Security-Teams gefragt haben.