Ein Sicherheitstool, das übertreibt, was es weiß, ist schlimmer als kein Tool: Es vermittelt ein falsches Sicherheitsgefühl. Daher trägt jede Kante in der Zugriffskarte zwei unabhängige Genauigkeitslabels, und das Produkt stellt sie ehrlich dar — es kleidet nie eine kaum bekannte Kante als bewiesene auf.
Die zwei Achsen beantworten zwei verschiedene Fragen:
- Abdeckung — wie gut die Quelle beweisen kann, ob dieser Zugriff ein Lesen oder ein Schreiben war.
- Zuordnung — wie sicher der Zugriff einem einzelnen Agenten zugeordnet werden kann, gegenüber einer geteilten Identität.
Sie bewegen sich unabhängig. Ein Data Warehouse mit nativem Audit liefert saubere Abdeckung; wenn jeder Agent ein gemeinsames Dienstkonto dagegen verwendet, ist die Zuordnung dennoch nur ungefähr. Keine Achse wird aus der anderen abgeleitet.
Abdeckung: Lesen vs Schreiben
Abdeckung beschreibt, was der zugrunde liegende Speicher uns über die Lese-/Schreibnatur eines Zugriffs sagen kann. Es ist eine Eigenschaft der Quelle, nicht des Agenten.
clean— der Speicher gibt natives, autoritatives Audit aus, sodass Lesen vs Schreiben wörtlich klassifiziert wird. Das sind Postgres über pgAudit, Objektspeicher über CloudTrail (s3.readOnly), und die Data Warehouses und Data Lakes (Snowflake, BigQuery, Redshift, Databricks, MSSQL, Oracle), plus die Kernel-Level eBPF Ground Truth.lossy— der Speicher liefert Kanten, aber grobe. Dokumentspeicher (zum Beispiel MongoDB) fallen hierher: Eine Kante existiert, aber die Lese-/Schreibaufteilung ist ungefähr.opaque— der Speicher gibt überhaupt kein passives Lese-/Schreibsignal. Redis, SQLite und D1 können nicht durch Beobachtung rekonstruiert werden, daher wird dermodeder Kante alsunknownmarkiert, anstatt zu raten.
Es gibt auch eine mixed-Stufe für kooperative oder Tool-Level-Signale — MCP-Tools, HTTP-APIs, Agenten-Tasks — die nicht an eine Speicherklasse gebunden sind.
Die Grundregel: Wenn ein Speicher opaque ist, ist die Lese-/Schreibklassifikation unknown, nie erfunden. Und eine fehlende Kante bei einer lossy- oder opaque-Quelle ist kein Beweis, dass ein Zugriff nicht stattfand — nur dass die Quelle ihn nicht belegen konnte. Das ist der Unterschied zwischen Erlaubt und Beobachtet.
Zuordnung: Welcher Agent
Zuordnung beschreibt, wie sicher ein beobachteter Zugriff auf einen konkreten Agenten zurückgeführt werden kann. Audit-Logs ordnen Aktivität einem Credential oder einer Rolle zu, nicht inhärent einem Agenten — daher ist diese Achse strenger als bloßes Signalvertrauen, und sie ist standardmäßig-ablehnend: Ohne ein sicheres Pro-Agent-Signal bleibt sie niedrig.
firm— der Zugriff löst sich eindeutig zu einem Agenten auf. Das erfordert ein echtes Pro-Agent-Identitätssignal: eine SPIFFE-Workload-SVID, ein Workload-Identity-föderiertes Dienstkonto, eine governance-geprägt dedizierte nicht-menschliche Identität, oder ein Credential, das an genau einen Agenten gebunden ist.approximate— eine Identität ist bekannt, aber ein einzelner Agent kann nicht festgemacht werden. Ein gemeinsames oder gepooltes Dienstkonto hinter einem Connection-Pool, ein mehrdeutiges Credential, oder eine Pro-Agent-Verknüpfung, die noch aussteht, landen alle hier.unknown— überhaupt keine Pro-Identitäts-Zuordnung möglich. Das ist der Boden für einenopaque-Speicher, der von einem nicht-kooperativen Backstop gesehen wird, oder einen Zugriff, der keiner Identität zugeordnet werden kann. Nie ein fabrizierter Agent.
Weil die Zuordnung standardmäßig-ablehnend ist, kann ein späteres, schwächeres Signal eine fest zugeordnete Kante nie herabstufen — aber ein starkes Signal kann eine schwache anheben. Die beiden Achsen interagieren auch in genau einer Richtung: Bei einem opaque-Speicher wird jede Zuordnung unterhalb von firm auf unknown begrenzt, anstatt als gemeinsam-Konto-Vermutung verkauft zu werden, die als approximate verkleidet ist.
Pro-Agent-Identität ist daher eine harte Abhängigkeit für die hochgenaue Karte. Gut steuern bedeutet, Identität pro Agent auszugeben — siehe Identität und das Governance-Modell.
Warum das wichtig ist
Der Zweck der Kennzeichnung beider Achsen ist Zurückhaltung. Das Produkt wird eine lossy/approximate-Kante nicht als Verstoß hervorheben, wie es das bei einer clean/firm-Kante täte, und es zeigt unknown und approximate offen an, anstatt sie zu verbergen. Ein Drift-Befund, den das System noch nicht sicher zuordnen kann, wird als Abstimmung-ausstehend markiert, nicht als bestätigter Verstoß dargestellt.
Deshalb kann die Zugriffskarte als Beweis vertraut werden und nicht nur als Vermutung: Jede Kante sagt in zwei Dimensionen genau, wie viel sie weiß. Wo sie wenig weiß, sagt sie das.
Wo diese Labels auftauchen
Beide Labels reisen mit jeder Kante in der Graph-API und der UI-Überlagerung, zusammen mit der Signalquelle, die die Kante produziert hat. Das Lesen des Zugriffsgraphen ist eine privilegierte, mandantenbezogene, vollständig auditierte Aktion.
Die genauen Feld-Level-Strukturen für den Zugriffskarten-Graphen und Drift befinden sich in den typisierten Interfaces des Produkts und sind bewusst nicht Teil des bereitgestellten OpenAPI-Vertrags — siehe die Referenz-Module und die Seite Ehrlichkeit und Grenzen für die vollständige Grenze zwischen Bewiesenem und Abgeleitetem.
Verwandte Themen
- Die Zugriffskarte — was eine Kante ist und wie sie aufgebaut wird.
- Erlaubt vs Beobachtet — der Least-Privilege-Drift, den diese Labels qualifizieren.
- Ehrlichkeit und Grenzen — der vollständige Vertrag darüber, was läuft, was Designphase ist, und was das Produkt bewusst nicht tut.