Erlaubt vs. beobachtet: Drift als erstklassiger Befund

In einem Begleitbeitrag wurde die Least-Privilege-Drift als Lücke zwischen dem, was ein KI-Agent tun darf, und dem, was er tut, eingeführt. In diesem Beitrag ging es um das Konzept: Warum sich die Lücke bildet, wie die Read-First-Beobachtung einen erlaubten versus beobachteten Unterschied erzeugt und wie Policy-as-Code ihn zum Zeitpunkt des Zugriffs schließt. In diesem Beitrag gehen wir noch eine Ebene tiefer – wie Drift zu einem strukturierten, klassifizierten und selektierbaren Befund innerhalb des Sicherheitsmoduls wird und was mit ihm passiert, sobald er existiert.

Die Kurzfassung: Drift ist keine Dashboard-Metrik oder Protokollzeile. Es handelt sich um eine persistente Entität mit einer Klassifizierung, einem Schweregrad, einem Konfidenzniveau und einem Triage-Lebenszyklus. Es füllt die Anomalie-Warteschlange, bereichert forensische Zeitpläne und ist ehrlich darüber, was es beweisen kann und was nicht.

Die drei Signalquellen

Jede Kante in der Access Map zeichnet eine Zugriffsbeziehung zwischen einem Ursprung (einem Agenten, einer Identität, einer Sitzung) und einer Ressource auf. Jede Kante trägt zwei boolesche Flags: Zulässig und Beobachtet. Die interessanten Kanten sind diejenigen, an denen diese Flaggen nicht übereinstimmen.

Doch die Fahnen kommen nicht aus dem Nichts. Sie stammen aus unterschiedlichen Signalquellen mit jeweils unterschiedlichem Vertrauensprofil:

Richtlinie (zulässig). Ein Edge mit signal_source=policy oder signal_source=scoped_grant stellt eine deklarierte Gewährung dar: etwas, das laut Anmeldeinformationen, einer IAM-Rolle oder der eigenen Source-Scoping-Ebene der Plattform diesem Agenten gestattet ist. Diese Kanten sind permitted=true, observed=false, bis die Telemetrie sie bestätigt. Sie sind die Decke. Die Identitätskonnektoren (WIF-Aussteller, API-Schlüssellisten, Arbeitsbereichsrollen) versorgen diese Seite. Ein Verbunddienstkonto, das den OAuth-Bereich seiner Regel in einem Arbeitsbereich zulässt, ist ein solcher Rand.

Telemetrie (beobachtet). Kooperative Signale von OpenTelemetry-Traces, pgAudit-Protokollen, CloudTrail-Datensätzen, MCP-Anmerkungen, A2A-Protokollbeobachtungen und GitHub/GitLab-Webhooks. Diese erzeugen Kanten, bei denen observed=true. Ihre Zuverlässigkeit hängt von der Quelle ab: Es wird eine pgAudit READ-Klassifizierung zugewiesen (die Datenbank weiß, wer abgefragt hat und ob es sich um einen Lese- oder Schreibvorgang handelte); ein MCP readOnlyHint ist laut Spezifikation ein Näherungswert – die MCP-Spezifikation selbst besagt, dass Werkzeuganmerkungen nicht vertrauenswürdig sind.

Kernel (Grundwahrheit). Der eBPF-Backstop (signal_source=ebpf) beobachtet auf Systemaufrufebene. Es ist das Signal, das ein Agent nicht umgehen kann. Wenn die eBPF-Schicht einen connect() oder einen write() erkennt, den die kooperative Telemetrie nicht gemeldet hat, handelt es sich nicht um eine Protokollierungslücke, sondern um ein Anti-Umgehungssignal. Das Sicherheitsmodul verbindet die Beobachtungen der Kernel-Seite und der kooperativen Seite zu einer korrelierten Anomalie, sodass ein Agent, der seine eigene Telemetrie zum Schweigen bringt, zu einer Entdeckung und nicht zu einem blinden Fleck wird.

Die Zugriffszuordnung ist eine Abfrage über diese Kanten, kein separates Schema. Die Drift der geringsten Privilegien ist die Teilmenge, bei der die beiden Flags nicht übereinstimmen.

Wie Drift zur Erkenntnis wird

Eine Unstimmigkeit zwischen Permitted und Observed ist das Rohsignal. Die Engine klassifiziert es in eine von zwei Driftarten, bevor es in die Anomaliewarteschlange gelangt:

// DriftKind klassifiziert eine Drift der geringsten Rechte zwischen erlaubt und beobachtet.
type DriftKind string

const (
    // DriftUnusedGrant ist ein erlaubter Zugriff, der nie beobachtet wird (überbereitgestellt).
    DriftUnusedGrant DriftKind = "unused_grant"
    // DriftViolation ist ein beobachteter Zugriff, der nicht zulässig ist.
    DriftViolation DriftKind = "violation"
)

unused_grant bedeutet, dass eine Richtlinie besagt, dass der Agent etwas tun kann, was er noch nie zuvor getan hat. Das ist ein totes Privileg – Risiko wird ohne Nutzen getragen. Es ist das Bereinigungssignal für regelmäßige Zugriffsüberprüfungen: Widerrufen Sie, was nicht ausgeübt wird.

violation bedeutet, dass der Agent dabei beobachtet wurde, wie er etwas tat, für das keine Richtlinien oder Genehmigungen vorliegen. Dies ist der aktive Befund. Es ist die Zeile in der Diff-Tabelle, die „Unreviewed Write“ lautet – die Kante, die zählt, die von der Anomaliewarteschlange priorisiert wird.

Die Klassifizierung erfolgt nicht binär zwischen „gut“ und „problematisch“. Die Struktur PrivilegeDrift ordnet die fehlerhafte Kante ihrer Art zu:

// PrivilegeDrift ist eine Least-Privilege-Diskrepanz: eine Kante, deren Flags Permitted
// und Observed nicht übereinstimmen.
type PrivilegeDrift struct {
    Edge AccessEdge
    Kind DriftKind
}

Die Kante selbst trägt die vollständige Herkunft: den Ursprung (welcher Agent), die Ressource, den Lesemodus, die Signalquelle, die sie erzeugt hat, das Vertrauen in die Zuordnung und das Beobachtungsfenster (FirstSeen, LastSeen, OccurrenceCount). Ein Drift-Befund bedeutet nie: „Irgendwo stimmt etwas nicht.“ Es verweist auf einen bestimmten Agenten, eine bestimmte Ressource, einen bestimmten Zugriffsmodus, der von einem bestimmten Kollektor beobachtet wird, mit einem Zeitbereich.

Die Anomalie-Warteschlange: nicht nur „anders“, sondern klassifiziert

Wenn das Sicherheitsmodul die Anomalieansicht erstellt (den GET /v1/m/security/anomalies-Endpunkt), ruft es Drift aus dem Access-Edge-Speicher ab und klassifiziert jeden Verstoß in eine priorisierte Anomalie. Die Klassifizierung fügt Kontext hinzu, den die Rohkante nicht trägt:

Zugriffsdrift. Die Basislinie: ein beobachteter, aber nicht erlaubter Zugriff. Die Anomalie trägt den Titel „Unerwarteter Zugriff: beobachtet, aber nicht erlaubt“, hat einen mittleren Schweregrad und ist mit confidence=approximate gekennzeichnet, da die Drift auf Filialebene das Rohsignal ist – noch nicht mit dem vollständigen Agent-zu-Identitäts-Diagramm abgeglichen. Die abgeglichene Ansicht befindet sich im /drift-Endpunkt der Zugriffszuordnung. Die Anomaliewarteschlange verbraucht das Rohsignal und kennzeichnet es ehrlich.

Egress/exfiltration vermutet. Wenn die Ressource an der Driftkante ein Netzwerkendpunkt zu einem externen, nicht privaten Ziel ist (der eBPF-Connector gibt diese als tcp://host:port-URIs aus), wird die Anomalie in egress_exfil_suspected umklassifiziert und auf den Schweregrad „Hoch“ heraufgestuft. Ein Agent, der an einen externen Endpunkt schreibt, auf den ihm nie Zugriff gewährt wurde, stellt eine andere Form der Feststellung dar als ein Agent, der eine Datenbanktabelle liest, für die er keinen Zugriff hatte.

Vertraulichkeitseskalation. Wenn die Ressource eine Vertraulichkeitsbezeichnung (high oder secret) trägt, wird der Schweregrad heraufgestuft, unabhängig davon, ob der Zugriff ausgehend ist. Ein Verstoß gegen eine hochsensible Ressource erfordert eine schnellere Triage, selbst wenn das Ziel intern ist.

Zu jeder Anomalie gehört eine evidence-Karte mit den Rohdetails:

ev := map[string]any{
    "origin_kind":      edge.OriginKind,
    "origin_id":        edge.OriginID.String(),
    "resource_id":      edge.ResourceID.String(),
    "mode":             string(edge.Mode),
    "signal_source":    string(edge.SignalSource),
    "occurrence_count": edge.OccurrenceCount,
    "reconciled":       false,
}

Der reconciled: false ist absichtlich. Es teilt dem Verbraucher mit, dass es sich hierbei um das Rohsignal auf Filialebene handelt und nicht um die abgeglichene Agent-zu-Identitäts-Ansicht der Zugriffszuordnung. Die Anomaliewarteschlange wartet nicht auf eine Versöhnung, um einen Verstoß ans Licht zu bringen – sie gibt aber auch nicht vor, dass die Zuordnung eindeutig ist, obwohl dies nicht der Fall ist.

Konfidenzniveaus: Was bewiesen werden kann

Jede Kante in der Access Map trägt ein Konfidenzniveau. Das Produkt verwendet zwei:

• Zugeschrieben (confidence=attributed): Der Zugriff ist durch eigene Beweise des Sammlers fest mit der Herkunft verknüpft. Ein pgAudit-Datensatz, der die Datenbankrolle des Agenten benennt, ein CloudTrail-Ereignis, das mit den IAM-Anmeldeinformationen des Agenten verknüpft ist, eine eBPF-Beobachtung, die mit einer Prozess-ID verknüpft ist, die die Laufzeit einem Agenten zuordnet. Die Attributionskette ist durchgängig.

• Ungefähr (confidence=approximate): Die Namensnennung ist abgeleitet und kann verlustbehaftet sein. Das Signal kam von einem gemeinsam genutzten Dienstkonto, bei dem mehrere Agenten dieselben Anmeldeinformationen verwenden, von einem verlustbehafteten Speicher (einer Redis-Instanz, die keine Identität pro Verbindung protokolliert) oder von einer MCP-Anmerkung, die laut Spezifikation nicht vertrauenswürdig ist. Die Kante ist immer noch ein Signal – aber der Bediener weiß, dass der Beweis schwächer ist.

Das Konfidenzniveau beeinflusst den Prioritätswert der Anomalie. Die Prioritätsfunktion (priorityFor) bewertet jede Anomalie von 0 bis 100, und eine Abweichung der ungefähren Konfidenz wird abgezinst:

if confidence == string(sdkmodel.ConfidenceApproximate) {
    // Rabatt: Unvereinbare Drift ist laut
}

Dadurch wird verhindert, dass ein lautes Shared-Identity-Signal einen eindeutig zugeschriebenen Verstoß verdrängt. Beide erscheinen in der Warteschlange; der ungefähre rangiert niedriger. Es ist das gleiche Prinzip wie bei der forensischen Anreicherung: Wenn eine gemeinsame Identität (SharedIdentity: true, AgentCount > 1) gefunden wird, vermerkt die Zeitleiste, dass „die Zuordnung pro Agent möglicherweise nicht eindeutig ist“, anstatt so zu tun, als sei die Zuordnung genau.

Das Produkt täuscht niemals Gewissheit vor. Eine Kante nur mit MCP-Annotation hat nicht das gleiche Gewicht wie eine Kante mit eBPF-Bestätigung. Ein Abweichungsbefund von einem gemeinsam genutzten Dienstkonto hat nicht das gleiche Gewicht wie einer von einer Pro-Agent-Identität. Der Bediener erkennt den Unterschied und wählt entsprechend aus.

Drift in der forensischen Zeitleiste

Abweichungsbefunde sind nicht nur in der Anomaliewarteschlange vorhanden. Wenn ein forensischer Fall eröffnet und sein Zeitplan aus dem Hash-verketteten Audit-Ledger rekonstruiert wird, reichert das Sicherheitsmodul die Rekonstruktion mit der Drift des Subjekts an:

out.Drift = subjectDrift(r.Context(), sc, c.SubjectRef)

Die Funktion subjectDrift fragt den Zugriffs-Edge-Speicher nach Abweichungen vom Typ der Verletzung ab, bei denen das Subjekt der Ursprung ist, und gibt eine Liste von driftRefDTO-Einträgen zurück – jeder enthält den Ursprung, die Ressource, den Zugriffsmodus, die Signalquelle, die Anzahl der Vorkommnisse und den zuletzt gesehenen Zeitstempel. Diese werden aus der eigenen Driftberechnung des Geschäfts gelesen und nicht vom Sicherheitsmodul neu berechnet.

Die Zeitleiste enthält auch die Identitätszuordnung und die Datenherkunft des Subjekts, sodass ein Ermittler, der einen Fall prüft, das vollständige Bild sieht: als wen der Agent auftritt (und ob diese Identität geteilt wird), worauf er zugegriffen hat, was er nicht haben sollte, und aus welchen Daten er Antworten abgeleitet hat. Jede dieser Anreicherungen ist tolerant gegenüber fehlenden Nachbarn – wenn das Wissensmodul nicht installiert ist, wird die Abstammung weggelassen und nicht gefälscht; Wenn für die Identität keine geklärte Agentenbindung vorliegt, sagt die Zuschreibung „noch nicht gebunden“, anstatt eine zu erfinden.

Der Triage-Lebenszyklus

Ein durch Abweichungen verursachter Befund geht mit dem Status open in das System ein. Von da an folgt der standardmäßige Triage-Lebenszyklus für Befunde:

• offen: Der Befund liegt vor, noch hat niemand darauf reagiert.
• geprüft: Ein Operator hat es bestätigt und es zur Überprüfung zugewiesen.
• behoben: Die zugrunde liegende Ursache wurde behoben (der Zuschuss wurde widerrufen, die Richtlinie wurde verschärft, der Agent wurde neu eingestuft).
• verworfen: Der Betreiber hat es überprüft und festgestellt, dass es sich nicht um ein echtes Risiko handelt (ein bekanntes Verhalten, ein falsch positives Ergebnis aufgrund einer ungefähren Zuordnung).

Jede Änderung des Triage-Status wird vom tatsächlichen Auftraggeber selbst geprüft. Der Vorgang des Ablehnens einer Feststellung wird im manipulationssicheren Ledger aufgezeichnet, sodass ein Prüfer nicht nur sehen kann, welche Abweichung aufgetreten ist, sondern auch, wer die Feststellung überprüft hat und welche Entscheidung er getroffen hat. Die Beweise des Befundes (Art, Schweregrad und Detail-Hash) sind nach der Erstellung unveränderlich; Die Triage ändert nur den Workflow-Status.

Was das in der Praxis bedeutet

Ein Agent erhält einen API-Schlüssel, der auf einen Claude-Arbeitsbereich beschränkt ist. Der Identitätskonnektor liest die Liste des Arbeitsbereichs und gibt einen Richtlinienrand aus: Dieser Schlüssel darf die API in diesem Arbeitsbereich aufrufen. Der Agent läuft drei Wochen. Die Telemetrie zeigt, dass die API in diesem Arbeitsbereich aufgerufen wird – keine Abweichung. Anschließend erhält der Agent durch eine Bereitstellungsänderung Zugriff auf den Schlüssel eines zweiten Arbeitsbereichs. Telemetrie beobachtet, wie der Agent beide Arbeitsbereiche anruft. Der zweite Arbeitsbereich hat keinen Richtlinienrand. Es wird ein Driftbefund der Art violation erstellt: beobachtet, aber nicht zulässig. Es wird als access_drift mit mittlerem Schweregrad und ungefährer Konfidenz in die Anomaliewarteschlange aufgenommen (die Kante wurde noch nicht mit dem Identitätsdiagramm abgeglichen). Wenn die Ressource im zweiten Arbeitsbereich die Vertraulichkeitsbezeichnung high trägt, wird der Schweregrad heraufgestuft. Der Befund verbleibt in der Warteschlange des Operators, bis ihn jemand selektiert.

Das ist der Unterschied zwischen Protokollierung und strukturierter Drift: Der Befund wird klassifiziert, zugeordnet (mit ehrlichem Vertrauen), priorisiert und kann selektiert werden. Es bleibt bestehen, bis jemand es löst oder verwirft. Es erscheint in der forensischen Zeitleiste, wenn der Agent später Gegenstand eines Vorfallsfalls wird. Und jede daran vorgenommene Aktion wird in einer Kette aufgezeichnet, deren Integrität das Produkt nachweisen kann.

Drift ist keine zu minimierende Kennzahl. Es handelt sich um einen Befund zur Triage. Die Kluft zwischen dem, was einem Agenten erlaubt ist, und dem, was er tut, ist die stärkste Signaloberfläche für die Durchsetzung des Least-Privilege-Prinzips – aber nur, wenn die Kluft strukturiert, klassifiziert und ehrlich ist, was sie beweisen kann.

Um die Access Map und die Driftoberfläche auf einem bewirtschafteten Gelände anzuzeigen, besuchen Sie die Produktseite der Access Map oder die Produktübersicht.