Agent-Identität vs. Zugangsdatenidentität: Verbergen Sie Akteure nicht

Ein KI-Agent, der Produktionszugangsdaten besitzt, schafft gleichzeitig zwei Identitätsprobleme. Der Agent kann als das Konto handeln, und später muss das Team so tun, als würde der Kontoname erklären, wer gehandelt hat. Das tut er nicht. Eine als deploy-bot authentifizierte API-Anfrage zeigt, dass jemand die Zugangsdaten für deploy-bot besaß. Sie zeigt nicht, ob der Aufrufer der freigegebene Coding-Agent, ein kopiertes Shell-Skript, eine schädliche Abhängigkeit oder ein nach einem Test weiterlaufender Prozess war.

Teams müssen den Prozess, der eine Aktion angefordert hat, getrennt von dem Konto identifizieren, das sie ausführen durfte. Das ist keine Frage schönerer Audit-Logs. Davon hängt ab, ob Sie einen bestimmten Agent-Lauf freigeben, ihn stoppen können, ohne andere Arbeit zu stören, eine fehlerhafte Bereitstellung untersuchen und ein offengelegtes Zugangsmittel eindämmen können, ohne zu raten.

Eine Zugangsdaten-ID identifiziert die Berechtigung, nicht den Aufrufer

Zugangsdaten zeigen, welche Berechtigung ein Dienst gewährt, während die Agent-Identität den Prozess beschreibt, der diese Berechtigung angefordert hat. Wer beides vermischt, macht jede spätere Sicherheitsentscheidung zu grob.

Nehmen wir eine Anfrage, die ein Objekt im Cloud-Speicher löscht. Die empfangende API sieht möglicherweise ein Bearer-Token und ordnet es einem Dienstkonto namens release-publisher zu. Dieses Konto beantwortet eine Autorisierungsfrage: Darf dieses Konto das Objekt löschen? Es beantwortet keine Zuordnungsfrage: Welcher lokale Prozess hat das Token verwendet, wer hat ihn gestartet, welchen Code hat er ausgeführt und hat jemand diesen Lauf freigegeben?

In ruhigen Zeiten klingen diese Fragen ähnlich, weil der erwartete Prozess und das Konto oft denselben Eigentümer haben. Unter Druck gehen sie auseinander. Ein Entwickler kopiert das Token in eine lokale Umgebung. Ein Code-Agent übernimmt diese Umgebung. Ein vom Agenten gestartetes Plugin liest es. Jede Anfrage erscheint weiterhin als release-publisher. Die Autorisierung funktioniert genau wie konfiguriert, während der Untersuchung der Akteur fehlt.

Die Identität von Zugangsdaten lebt meist lange und hat einen breiten Zweck. Sie kann ein API-Token, ein privater SSH-Schlüssel, ein Cloud-Dienstkonto oder der Name eines Client-Zertifikats sein. Die Prozessidentität sollte etwas viel Engeres beschreiben: diese ausführbare Datei, von dieser Signatur oder diesem Image, in diesem Kontext und während dieses Laufs gestartet.

Die Unterscheidung hat eine praktische Folge:

• Widerrufen Sie eine Prozesssitzung, wenn ein Agent-Lauf nicht mehr vertrauenswürdig ist.
• Deaktivieren oder rotieren Sie Zugangsdaten, wenn ihr Geheimnis nach außen gelangt sein könnte.
• Ändern Sie Kontoberechtigungen, wenn die Berechtigung selbst zu weit gefasst war.
• Untersuchen Sie den Prozessdatensatz, wenn Sie wissen müssen, was tatsächlich passiert ist.

Wenn ein Feld alle vier Aufgaben übernehmen soll, wird es keine davon gut erfüllen. Das Konto agent-prod-42 zu nennen, löst das Problem nicht. Ein besseres Etikett macht aus einem Bearer-Token keinen Beleg für den Träger.

In einer Agent-Anfrage treten vier Identitäten auf

Eine Produktionsaktion umfasst normalerweise mindestens vier Identitäten. Ein Audit-Eintrag sollte sie alle bewahren, statt sie zu einem Kontonamen zu reduzieren.

Erstens gibt es den Menschen oder das System, der oder das die Arbeit gestartet hat. Das kann ein Entwickler im Terminal, der Auslöser eines CI-Jobs oder eine geplante Aufgabe sein. Die Eigentümerschaft zeigt, wer den Agent-Lauf angefordert hat und wer Warnungen erhalten sollte.

Zweitens gibt es den Agent-Prozess. Bei einem lokalen Coding-Agenten können der Pfad der ausführbaren Datei, die Signaturinstanz, die Prozess-ID, der übergeordnete Prozess, die Startzeit und eine beim Start vergebene zufällige Sitzungs-ID wichtige Belege liefern. In einer Containerumgebung können ein Image-Digest, ein vom Workload ausgestelltes Identitätsdokument, der Name des Orchestrator-Workloads und die Pod- oder Task-Instanz diese Rolle übernehmen. Diese Identität beantwortet, welches laufende Programm eine Aktion angefordert hat.

Drittens gibt es die Identität der Zugangsdaten. Das ist das Dienstkonto, der SSH-Prinzipal, der OAuth-Client oder der Datensatz des API-Tokens, den das Ziel akzeptiert. Sie zeigt, was das Ziel erlaubt.

Viertens gibt es die Zielidentität: den Hostnamen, das Repository, das Cloud-Projekt, die Datenbank oder die API-Zielgruppe, die von der Anfrage betroffen ist. Teams protokollieren oft nur einen allgemeinen Endpunkt und stellen später fest, dass die Aktion eine Umgebungsgrenze überschritten hat, die sie nie freigeben wollten.

Ein sauberer Eintrag kann so aussehen:

{
  "event": "http.request",
  "session_id": "ses_7zQ2...",
  "process": {
    "pid": 8421,
    "signing_authority": "Example Developer ID",
    "parent_pid": 8190,
    "launch": "interactive-terminal"
  },
  "credential_ref": "cred_release_publisher",
  "credential_subject": "release-publisher",
  "target": "api.example.internal",
  "operation": "POST /releases",
  "decision": "approved",
  "result": 201
}

credential_ref verweist auf einen Tresordatensatz. Es ist nicht das Geheimnis. Der Prozessblock liefert den Beleg, den die Zugangsdaten-ID nicht liefern kann. Ein Prüfer sieht nun, dass eine freigegebene Sitzung release-publisher für ein Ziel verwendet hat, und kann diesen Lauf von einem späteren Prozess unterscheiden, der dasselbe Konto benutzt.

Überfrachten Sie auch das Feld für den menschlichen Eigentümer nicht. Wer einen Agenten gebeten hat, die Dokumentation zu aktualisieren, ist nicht automatisch die Person, die eine Produktionsbereitstellung freigegeben hat, die der Agent später versucht hat. Halten Sie Start, Prozess, Zugangsdaten und Ziel getrennt. Die unangenehmen Lücken werden sichtbar. Genau darum geht es.

Bearer-Tokens löschen die wichtigsten Belege

Ein Bearer-Token wird akzeptiert, weil der Aufrufer es besitzt. Deshalb kann es nicht zeigen, welcher Prozess es vorlegt. Das ist eine Eigenschaft des Verfahrens und kein Fehler im Logging Ihres API-Anbieters.

RFC 6750 beschreibt die Verwendung von Bearer-Tokens direkt: Jede Partei, die das Token besitzt, kann es verwenden. Das machte Bearer-Tokens einfach einsetzbar. Es bedeutet aber auch, dass eine API den freigegebenen Agenten nicht von einem kopierten Prozess unterscheiden kann, sofern Sie keine zusätzliche Kontrolle einführen. Die häufige Antwort «Wir legen das Token in einem Secrets Manager ab» betrifft die Speicherung im Ruhezustand. Sie beantwortet nicht, was geschieht, nachdem ein Prozess den Wert erhalten hat.

Die OAuth 2.0 Security Best Current Practice, RFC 9700, geht in die richtige Richtung. Sie empfiehlt, wo passend, an den Sender gebundene Zugriffstokens sowie kurze Laufzeiten und eine Einschränkung der Zielgruppe. Eine Senderbindung kann Token-Wiederholungen begrenzen, weil der Ressourcenserver einen Nachweis des vorgesehenen Clients prüft. Sie macht die Identifizierung des Prozesses, der diesen Client kontrolliert, jedoch nicht überflüssig. Wenn ein Agent-Prozess das private Beweismaterial verwenden kann, kann ein Angreifer, der diesen Prozess kontrolliert, weiterhin als Client handeln.

Diese Unterscheidung ist für KI-Agenten wichtig, weil ihre Betriebsumgebung ungewöhnlich durchlässig ist. Sie lesen Repositories, führen Befehle aus, rufen Tools auf, untersuchen Umgebungsvariablen und handeln mitunter nach Anweisungen aus Dateien oder Issue-Kommentaren. Ein Token, das dem Agenten offengelegt wird, bleibt nicht in einer sauberen Vertrauensgrenze, nur weil das Team es für einen einzelnen Tool-Aufruf vorgesehen hat.

Vermeiden Sie die beliebte Empfehlung, jedem Agenten ein eigenes langlebiges Token zu geben und das Problem damit für gelöst zu erklären. Sie ist beliebt, weil sie übersichtliche Kontonamen und einfache Dashboards schafft. Sie scheitert, wenn der Agent das Token lesen kann, ein anderer Prozess dieselbe Umgebung lesen kann oder das Konto nach dem Ende des Agent-Laufs bestehen bleibt. Eigene Zugangsdaten verbessern die Zuordnung des Schadensradius, beweisen aber nicht die Herkunft des Prozesses.

Sie brauchen zwei Kontrollen: Verhindern Sie, dass der Agent wiederverwendbares Geheimnismaterial erhält, und bewahren Sie einen getrennten Datensatz des Agent-Prozesses auf, der jede Aktion angefordert hat. Die erste Kontrolle begrenzt Diebstahl. Die zweite macht Freigabe, Widerruf und Untersuchung so genau, dass sie nützlich werden.

Eine Prozessidentität braucht Belege, die einen Prompt überstehen

Eine Prozessidentität sollte aus Fakten stammen, die das Betriebssystem oder die Ausführungsumgebung melden kann, nicht aus einer Zeichenfolge, die der Agent in einer Tool-Anfrage selbst angibt. Wenn ein Agent name: trusted-release-agent meldet, ist das eine Behauptung, aber kein Identitätsbeleg.

Auf einem verwalteten Mac bietet die Code-Signaturinstanz einen guten Ausgangspunkt. Das Betriebssystem kann einer überwachenden Anwendung mitteilen, welche signierte ausführbare Datei gestartet wurde und welche Instanz sie signiert hat. Das bedeutet nicht, dass jedes signierte Programm eine Freigabe verdient. Es bedeutet, dass ein Freigabebildschirm einen schwerer zu fälschenden Fakt anzeigen kann als ein vom Prozess geliefertes Etikett.

Suchen Sie auf einem Server nach gleichwertigen Belegen. Eine von der Laufzeit ausgestellte Workload-Identität, ein überprüfter Image-Digest, ein gegenseitig authentifizierter Kanal oder eine Bescheinigung des Prozess-Supervisors kann eine Aktion an eine Workload-Instanz binden. SPIFFE beschreibt dieses Modell mit dem SPIFFE Verifiable Identity Document und X.509 SVIDs: Der Workload erhält eine Identität aus seiner Umgebung und legt sie anschließend einem anderen Workload vor. Dieses Modell ist stärker als eine gemeinsam genutzte Umgebungsvariable, weil die Identität auf einen Workload begrenzt ist.

Verwechseln Sie einen statischen Image-Digest nicht mit einer vollständigen Prozessidentität. Er identifiziert den Codeinhalt, aber eine brauchbare Aktionsentscheidung braucht zusätzlich die laufende Instanz und den Startkontext. Dasselbe Image kann im vorgesehenen Produktionsjob, in der Testumgebung eines Entwicklers oder in einer von einem Angreifer kontrollierten Aufgabe ausgeführt werden. Ziel und Sitzung bleiben Teil der Entscheidung.

Erfassen Sie bei lokaler Agent-Arbeit die Belege beim Erstellen der Sitzung und binden Sie spätere Aktionen an diese Sitzung. Ein minimaler Sitzungsdatensatz könnte enthalten:

session_id: ses_7zQ2...
executable: /Applications/Agent.app/Contents/MacOS/agent
signing_authority: Example Developer ID
parent_process: /Applications/Terminal.app
started_at: 2025-03-08T14:03:19Z
owner: [email protected]

Die genauen Felder unterscheiden sich je nach Betriebssystem. Die Disziplin bleibt gleich: Die Komponente, die eine Aktion freigibt, sollte die Prozessfakten selbst sammeln. Sie sollte nicht darauf vertrauen, dass der Agent sich korrekt beschreibt, nachdem er bereits nicht vertrauenswürdige Eingaben erhalten hat.

Auch die Prozessidentität hat Grenzen. Eine Codesignatur beweist nicht, dass ein signierter Agent sicheren Anweisungen gefolgt ist. Ein Image-Digest beweist nicht, dass seine Konfiguration sicher ist. Die Identität zeigt, welchen Akteur Sie freigegeben haben, und bietet einen Ansatzpunkt für den Widerruf. Eine riskante angeforderte Aktion wird dadurch allein nicht sicher.

Die Freigabe muss an einen Lauf gebunden sein, nicht an einen Kontonamen

Eine menschliche Freigabe sollte eine bestimmte Prozesssitzung für einen begrenzten Zeitraum autorisieren, statt jeden späteren Prozess dauerhaft zu legitimieren, der ein Konto verwendet. Sonst wird die Freigabe zu einer verdeckten Vergabe dauerhafter Zugriffsrechte.

Freigabemüdigkeit beginnt oft mit der falschen Einheit. Teams bitten entweder für jede harmlose Anfrage um eine Freigabe, worauf Menschen nur noch klicken, oder sie geben ein Dienstkonto einmal frei und sehen danach keinen sinnvollen Dialog mehr. Keine dieser Varianten identifiziert den aktiven Prozess.

Verwenden Sie eine Sitzungsfreigabe, wenn ein Agent einen Lauf beginnt. Zeigen Sie die Prozessbelege, die ein Bediener bewerten kann: ausführbare Datei oder Workload-Name, Signaturinstanz oder Image-Digest, übergeordneter Prozess oder Starter, vorgesehene Kanäle und Sitzungs-ID. Erlauben Sie nach der Freigabe Aktionen über diese Sitzung, bis der Prozess endet oder der Bediener sie widerruft. Ein neuer Prozess muss eine neue Sitzung anfordern, selbst wenn er dieselben Zugangsdaten verwenden möchte.

Reservieren Sie eine Freigabe pro Aktion für Zugangsdaten, deren Einfluss eine Unterbrechung rechtfertigt. Zugangsdaten eines Produktionsdatenbankadministrators, eine SSH-Identität mit Zugriff auf Flotten-Hosts oder ein Konto, das öffentliche Artefakte veröffentlichen kann, benötigen möglicherweise jedes Mal eine menschliche Entscheidung. Für gewöhnlichen Lesezugriff gilt das nicht. Der Mechanismus sollte diesen Unterschied deutlich machen, statt ihn in einer riesigen Richtliniendatei zu verstecken, die niemand prüft.

Dieses Modell bietet Eindämmungsmöglichkeiten, die gemeinsam genutzter Zugriff nicht bieten kann. Wenn ein Agent sich auffällig verhält, widerrufen Sie seine Sitzung. Die Zugangsdaten bleiben für einen anderen freigegebenen Release-Prozess verfügbar. Vermuten Sie eine Offenlegung des Geheimnisses, deaktivieren Sie zusätzlich die Zugangsdaten und prüfen Sie jede Sitzung, die auf sie verwiesen hat.

Sallyport verwendet diese Trennung direkt: Ein neuer Agent-Prozess erhält standardmäßig eine sitzungsbezogene Autorisierung, während Zugangsdaten in seinem verschlüsselten Tresor bleiben und Aktionen außerhalb des Agent-Prozesses ausgeführt werden. Der Sitzungsdialog zeigt zuerst die Codesignaturinstanz des Prozesses, also den Beleg, den eine freigebende Person vor der Zulassung eines Laufs braucht.

Der Freigabedatensatz sollte sowohl die Prozesssitzung als auch die später verwendete Zugangsdatenreferenz enthalten. Zeigen Sie den Wert der Zugangsdaten nicht im Dialog und geben Sie ihn nicht als Aktionsergebnis zurück. Ein System, das ein Token in der Oberfläche verbirgt, es aber in einer Agent-Tool-Antwort ausgibt, hat es dem Agenten trotzdem übergeben.

Die Injektion von Zugangsdaten hält Geheimnisse außerhalb der Reichweite des Agenten

Der Agent sollte eine Aktion anfordern, indem er eine Zugangsdatenreferenz und ein Ziel nennt. Ein vertrauenswürdiger Ausführer fügt das Geheimnis erst in dem Moment ein, in dem er den HTTP- oder SSH-Aufruf ausführt. Der Agent erhält das Ergebnis, nicht die wiederverwendbare Zugangsdaten.

Das ist eine viel klarere Grenze, als ein Token in eine Shell-Umgebung zu legen und den Agenten zu bitten, es nicht auszugeben. Umgebungsvariablen gelangen in Kindprozesse, Debug-Ausgaben, Absturzberichte, Befehlsverlauf-Wrapper und Tool-Aufrufe. Redaction hilft nachträglich bei versehentlicher Anzeige. Sie kann ein Geheimnis aber nicht aus einem Prozess zurückholen, der es bereits gelesen hat.

Eine sichere Aktionsanfrage enthält genug Angaben, um den Aufruf freizugeben und auszuführen, aber nicht die Zugangsdaten selbst:

{
  "session_id": "ses_7zQ2...",
  "credential_ref": "cred_release_publisher",
  "channel": "http",
  "request": {
    "method": "POST",
    "url": "https://api.example.internal/releases",
    "headers": {"Content-Type": "application/json"},
    "body": {"version": "1.4.2"}
  }
}

Der Ausführer prüft, ob die Sitzung weiterhin freigegeben ist, bestätigt die Verfügbarkeit des Tresors, holt cred_release_publisher, fügt die Zugangsdaten in den erforderlichen Autorisierungs-Header ein, führt die Anfrage aus und protokolliert Entscheidung und Ergebnis. Er sollte die für die Aufgabe des Agenten erforderlichen Antwortdaten zurückgeben und dabei die üblichen Regeln für sensible Antwortinhalte anwenden.

Dasselbe Prinzip gilt für SSH. Der Agent kann git fetch oder einen Remote-Befehl über einen SSH-Kanal anfordern, sollte aber weder den privaten Schlüssel als PEM-Block noch einen Agent-Socket erhalten, den jeder Kindprozess ohne Überwachung verwenden kann. Der Ausführer kann den privaten Schlüssel für die Verbindung verwenden und das Ereignis an die Agent-Sitzung binden.

Sallyport unterstützt derzeit die Injektion von HTTP-Zugangsdaten und SSH-Aktionen über seinen mitgelieferten Helfer. So kann ein MCP-fähiger Agent die Arbeit anfordern, ohne das API- oder SSH-Geheimnis zu besitzen. Dieses Design macht nicht jede Aktion sicher. Es bewahrt die Trennung, die nötig ist, um zu entscheiden, ob der Prozess sie anfordern darf.

Ein gemeinsames Deployment-Token verbirgt den Fehler, bis er wichtig wird

Gemeinsame Zugangsdaten machen aus einem überschaubaren Vorfall eine Rekonstruktionsaufgabe, weil in jeder relevanten Log-Zeile derselbe Kontoname auftaucht. Der Fehler beginnt oft mit einer vernünftigen Abkürzung.

Stellen Sie sich ein Team vor, das PUBLISH_TOKEN in einem CI-Secret-Speicher aufbewahrt. Der Deployment-Job liest es, wie vorgesehen. Ein Entwickler exportiert es zusätzlich lokal, um ein Release-Problem nachzustellen. Später startet er in dieser Shell einen Coding-Agenten, weil der Agent die Deployment-Skripte untersuchen soll. Der Agent kann nun über seine Umgebung die Release-API aufrufen.

Eine in einer Repository-Datei versteckte Anweisung fordert den Agenten auf, einen Befehl auszuführen, der ein Entwurfs-Release hochlädt. Der Befehl gelingt. Der API-Audit-Eintrag sagt: release-publisher created release 1.4.2. Das CI-Log zeigt keinen passenden Job. Der Entwickler sagt, er habe den Agenten nur gebeten, Dateien zu prüfen. Alle können diesen Fakten zustimmen, aber keiner identifiziert den Prozess, der den Aufruf ausgeführt hat.

Das Team reagiert häufig mit der Rotation von PUBLISH_TOKEN. Das verhindert eine erneute Verwendung, falls das Token nach außen gelangt ist, unterbricht aber auch den legitimen CI-Job und erzwingt eine hektische Reparatur. Danach beschuldigt das Team möglicherweise den Entwickler, den Agenten oder die Repository-Anweisung, ohne Belege zu haben. Der Kontoname bietet keine Möglichkeit, einen CI-Aufruf von einer lokalen Agent-Aktion zu unterscheiden.

Ändern Sie nun das Design. Die Release-Zugangsdaten bleiben in einem Tresor, der von einem Aktionsausführer kontrolliert wird. Der Agent startet eine Sitzung, die seine Signaturinstanz und das übergeordnete Terminal erfasst. Er fordert den Upload über diese Sitzung an. Der Ausführer protokolliert die Freigabeentscheidung, die Zugangsdatenreferenz, die Ziel-API, den Anfragepfad und den Antwortstatus.

Wenn der verdächtige Upload geschieht, beantwortet der Vorfallsdatensatz die ersten wichtigen Fragen sofort: Er kam aus einer lokalen Agent-Sitzung, diese Sitzung wurde von einem bestimmten Terminal gestartet, sie erhielt zu einem bestimmten Zeitpunkt eine Autorisierung und verwendete die Release-Zugangsdaten für einen POST-Aufruf. Der Bediener widerruft diese Sitzung. CI läuft weiter, weil sein separat identifizierter Prozess nicht widerrufen wurde. Falls die Repository-Anweisung umfassendere Geheimnisse offengelegt haben könnte, kann das Team die Zugangsdaten weiterhin rotieren. Es tut dies dann aber aufgrund von Belegen und nicht, weil jede andere Kontrolle fehlt.

Der Unterschied ist keine perfekte Vermeidung. Ein freigegebener Agent kann weiterhin eine Aktion anfordern, deren Freigabe ein Mensch später bereut. Der Unterschied besteht darin, dass das System einen Akteur, eine Autorisierungsentscheidung und eine gezielte Möglichkeit zum Stoppen bewahrt. Das reicht, um einen Vorfall zu verkürzen, statt ihn in einen Streit zu verwandeln.

Audit-Einträge müssen Identitäten verbinden, ohne Geheimnisse zu speichern

Ein Audit-Trail sollte eine Prozesssitzung, eine Zugangsdatenreferenz und eine externe Aktion miteinander verbinden können, während geheimes Material aus dem Datensatz herausbleibt. Liegen diese Daten in getrennten Produkten ohne gemeinsame Ereignis-ID, wird die Reaktion auf Vorfälle unter Zeitdruck zu manueller Korrelation.

Schreiben Sie einen Eintrag für die Sitzungsentscheidung und einen für jede Aktion. Geben Sie beiden dieselbe session_id und jeder Aktion eine eigene Ereignis-ID. Speichern Sie eine Zugangsdatenreferenz und, sofern sicher, das Subjekt der Zugangsdaten. Speichern Sie niemals das Bearer-Token, den privaten Schlüssel oder den unveränderten Autorisierungs-Header.

Ein nützlicher Aktionsdatensatz enthält das normalisierte Ziel, die Methode oder den Remote-Befehl, bei möglicherweise sensiblen Bodies einen Request-Digest, Entscheidung, Antwortstatus und Zeitstempel. Erfassen Sie bei SSH Host, Remote-Benutzer, angeforderten Befehl und Exit-Ergebnis. Erfassen Sie bei HTTP Methode, Host, Pfad und Status. Den vollständigen Body sollten Sie nur speichern, wenn Aufbewahrungs- und Datenverarbeitungsregeln dies erlauben.

Manipulationsnachweise sind wichtig, weil der Prozess, der eine Aktion ausführt, später beschuldigt werden kann, sie verborgen zu haben. Eine Hash-Kette macht das Entfernen oder Umstellen von Einträgen erkennbar, wenn der Ermittler die vollständige Sequenz besitzt. Sie macht einen Eintrag nicht wahr. Wenn Ihr Collector einen vom Agenten gelieferten Prozessnamen akzeptiert, bewahrt ein perfekt verkettetes Log diese falsche Behauptung für immer. Erfassen Sie die Identitätsbelege zuerst an der überwachenden Grenze und schützen Sie dann den Datensatz.

Ein einfacher Prüfprozess sollte unabhängig vom Inhalt des Tresors funktionieren. Der Prüfer liest jede verschlüsselte Ereignisdatei, prüft, ob der gespeicherte vorherige Hash zum Hash des vorherigen Ereignisses passt, berechnet den aktuellen Hash neu und meldet die erste fehlerhafte Position. Die Ausgabe sollte die Position in der Sequenz nennen, ohne Geheimnisse offenzulegen:

$ audit verify events.log
verified: 184 events
chain: valid
first_event: evt_01J...
last_event: evt_01K...

Wenn die Prüfung fehlschlägt, bewahren Sie die Originaldateien auf, bevor Sie eine Reparatur versuchen. Ein fehlender Eintrag kann auf Beschädigung, einen unterbrochenen Schreibvorgang, fehlerhafte Exportverarbeitung oder absichtliche Veränderung hindeuten. Die Kette zeigt die Inkonsistenz. Ihre übrigen Logs und Speicherkontrollen erklären die Ursache.

Trennen Sie Identitäten, bevor Sie mehr Automatisierung hinzufügen

Teams können dieses Modell übernehmen, ohne jede API-Integration neu zu bauen. Beginnen Sie mit Zugangsdaten, die Produktionszustand ändern, Artefakte veröffentlichen, auf Kundendaten zugreifen oder per SSH Verbindungen herstellen können. Das sind die Konten, die die schwierigsten Vorfälle verursachen, wenn ein Agent-Prozess sie übernimmt.

Machen Sie den ersten Schritt konkret:

1. Listen Sie jedes Zugangsdaten-Subjekt, die erreichbaren Dienste und jeden Prozess auf, der derzeit sein Geheimnis erhält.
2. Entfernen Sie wiederverwendbare Geheimniswerte aus Agent-Prompts, Agent-Konfiguration und Umgebungen von Agent-Prozessen.
3. Legen Sie fest, welche Prozessbelege Sie dort sammeln können, wo Aktionen autorisiert werden.
4. Vergeben Sie für jeden Agent-Lauf eine Sitzungs-ID und protokollieren Sie sie bei jeder Aktion neben der Zugangsdatenreferenz.
5. Testen Sie die Eindämmung, indem Sie eine Sitzung widerrufen, während ein anderer freigegebener Workload dasselbe Konto weiterverwendet.

Der letzte Test macht den häufigsten Fehler schnell sichtbar. Wenn Sie einen Agenten nur stoppen können, indem Sie das gemeinsame Konto deaktivieren, haben Sie Agent-Identität und Zugangsdatenidentität nicht getrennt. Sie haben einem gemeinsamen Risiko einen freundlichen Namen gegeben.

Beginnen Sie nicht mit einer ausufernden Regel-Engine. Die meisten Teams brauchen einige klare Entscheidungen: Ist der Tresor verfügbar, ist diese Prozesssitzung freigegeben und benötigt diese Zugangsdaten für diese Aktion eine Freigabe? Der schwierigere Teil ist die operative Disziplin: Senden Sie keine Geheimnisse mehr in Agent-Prozesse, sammeln Sie vertrauenswürdige Prozessbelege und behandeln Sie den Namen eines Dienstkontos nicht als Person oder Programm.

Wenn die nächste fragwürdige Aktion auftaucht, verlangen Sie Antworten auf zwei getrennte Fragen: Welcher Prozess hat dies angefordert und welche Berechtigung hat es ausgeführt? Wenn Ihre Aufzeichnungen beides nicht beantworten können, beheben Sie das, bevor Sie einem weiteren Agenten Produktionszugriff geben.