Arbeitsblatt für das Zugangsverzeichnis von KI-Coding-Agents

KI-Coding-Agents sollten nicht einfach einen Haufen geerbter Zugangsdaten und die vage Aufforderung erhalten, vorsichtig zu sein. Bevor ein Agent eine API aufruft, einen Dienst ausrollt oder eine SSH-Verbindung öffnet, braucht jemand einen Nachweis, aus dem hervorgeht, was der Zugang erreicht, wer dafür die Verantwortung übernimmt und wie das Team ihn abschaltet.

Ein Arbeitsblatt für Zugangsdaten klingt nach Verwaltungsarbeit, bis ein Agent zwanzig Aufrufe macht, während die zuständige Person nicht am Rechner ist. Dann entscheidet es darüber, ob sich eine bekannte Fähigkeit gezielt widerrufen lässt oder ob die halbe Entwicklungsorganisation handlungsunfähig wird, weil niemand den Token zuordnen kann. Ich habe Teams erlebt, die erst nach einer automatisierten Änderung an der falschen Stelle bemerkten, dass ihre „Staging“-Automatisierung über einen Produktions-Token mit Schreibrechten verfügte.

Das Verzeichnis muss Berechtigungen beschreiben, keine Geheimnisse

Ein Arbeitsblatt für Zugangsdaten erfasst Berechtigungen. Es enthält weder den API-Token, private SSH-Daten, ein Passwort, einen Wiederherstellungscode noch einen verschlüsselten Export davon. Wenn ein Arbeitsblatt sich irgendwo authentifizieren kann, ist es zu einem weiteren Geheimnisspeicher mit schwächeren Zugriffskontrollen und deutlich mehr Lesern geworden.

Diese Unterscheidung ist wichtig, weil Teams eine Kennung oft mit einem Zugang verwechseln. Die letzten vier Zeichen eines API-Tokens helfen einer zuständigen Person, den richtigen Eintrag bei der Rotation zu finden. Sie sagen aber nicht, ob der Token ein Projekt löschen kann. Der Fingerabdruck eines öffentlichen SSH-Schlüssels identifiziert eine Identität. Er sagt nicht, welches Unix-Konto sie öffnet, ob Portweiterleitung erlaubt ist oder welchen Hosts sie vertrauen.

Verwende für jede unabhängig widerrufbare Berechtigung eine eigene Zeile. Ein Anbieter-Konto kann mehrere Zeilen benötigen: einen Nur-Lese-Token für Produktionsberichte, einen Deployment-Token für Staging, einen Notfall-Administrator-Token, den Agents nicht verwenden dürfen, und ein Geheimnis zum Signieren von Webhooks. Werden sie in einer Zeile zusammengefasst, verschwinden ihre unterschiedlichen Risiken und Rotationsanforderungen.

Dasselbe gilt für SSH. Schreibe nicht „Git und Server“ in eine Zelle, nur weil ein privater Schlüssel an beiden Stellen funktioniert. Eine Identität mit Schreibrechten für die Quellcodeverwaltung und eine Identität für die Host-Anmeldung haben unterschiedliche Folgen. Sie brauchen eigene Zeilen, selbst wenn dieselbe Person sie am selben Nachmittag erstellt hat.

NIST SP 800-57 Part 1 behandelt die Verwaltung kryptografischer Schlüssel als Lebenszyklusproblem: Erzeugung, Verteilung, Speicherung, Verwendung, Ersetzung und Vernichtung müssen kontrolliert werden. Das Dokument konzentriert sich auf kryptografische Schlüssel, aber seine Grundsätze gelten hier unmittelbar. Eine Liste, die bei „Wir haben einen Token erstellt“ endet, ist kein Verzeichnis. Sie ist eine Gedächtnisstütze, die genau dann versagt, wenn das Team verlässliche Unterlagen braucht.

Weise jedem Zugang eine verantwortliche Person zu

Jede Zeile braucht eine namentlich genannte verantwortliche Person, die die Frage beantworten kann: „Soll diese Berechtigung noch existieren?“ Diese Person muss weder den Geheimnisspeicher betreiben noch die Agent-Integration programmieren. Sie braucht aber genug Wissen über das betroffene System, um den Zugriff zu genehmigen und die betrieblichen Folgen zu übernehmen.

Vermeide Angaben wie „Plattform“, „Entwicklungsteam“, „geteilt“ oder den Namen eines ehemaligen Mitarbeiters. Eine Gruppe kann einen Prozess betreiben, aber ein Gruppenname sagt einer Person im Sicherheitsvorfall nicht, wen sie um zwei Uhr morgens anrufen soll. Erfasse eine primäre und bei Bedarf eine stellvertretende verantwortliche Person, die den Zugang widerrufen oder ersetzen darf.

Halte vier Rollen auseinander, die Teams regelmäßig vermischen:

• Der Systemverantwortliche entscheidet, ob der Zugriff weiterhin angemessen ist.
• Die für den Zugang zuständige Person kann ihn erstellen, speichern, widerrufen und rotieren.
• Die für den Agent zuständige Person startet den Agent-Lauf oder überwacht ihn.
• Der Incident-Kontakt kümmert sich um einen dringenden Fehler, wenn die ersten drei Personen nicht erreichbar sind.

In einem kleinen Team kann eine Person mehrere Rollen innehaben. Das Arbeitsblatt sollte die Rollen trotzdem getrennt benennen. Wenn ein Token während eines Releases ausfällt, kann die zuständige Person die Speicherung reparieren, während der Systemverantwortliche entscheidet, ob ein vorübergehender Ersatz denselben Umfang erhalten soll.

Bei einer Anbieter-API liegt die Verantwortung oft beim Team, das für das Konto bezahlt oder es betreibt, nicht beim Entwickler, der den ersten Token in eine lokale Konfigurationsdatei kopiert hat. Bei SSH liegt sie normalerweise beim Host- oder Anwendungsverantwortlichen, nicht bei der Person, die das Schlüsselpaar erzeugt hat. Das klingt selbstverständlich, doch verwaiste Zugangsdaten beginnen meist als sinnvoller Abkürzungsweg einer Person, die später das Team gewechselt hat.

Füge ein Prüfdatum hinzu, das nicht mit dem Rotationsdatum eines Geheimnisses identisch ist. Ein Token kann technisch gültig bleiben, obwohl sein geschäftlicher Zweck entfallen ist. Bei der Prüfung geht es darum, ob der Zugriff noch existieren sollte. Bei der Rotation wird Material ersetzt, das gealtert oder bekannt geworden sein könnte. Das eine erledigt nicht automatisch das andere.

Erlaubte Aktionen als Verben und Ziele formulieren

„Produktionszugriff“ beschreibt keine Berechtigung. Es ist ein Warnhinweis, der der für den Agent zuständigen Person nichts Brauchbares sagt. Das Arbeitsblatt braucht Verben, Zielressourcen und Grenzen, die ein Prüfer testen kann.

Formuliere Berechtigungen nach diesem Muster:

Verb + Ziel + Grenze + verbotene Aktion

Zum Beispiel:

• GET /v1/projects/acme/builds in Staging; keine Anfragen an Produktionsmandanten
• Deployment-Revisionen für den Dienst catalog-api erstellen; kein Zurücksetzen und kein Löschen
• Als deploy in der Build-Hostgruppe per SSH anmelden; nur den freigegebenen Release-Befehl ausführen; keine interaktive Shell
• Issue-Kommentare im Repository alpha erstellen; kein Mergen, Löschen von Branches oder Ändern von Einstellungen

Das ist hilfreicher als eine allgemeine Anbieterbezeichnung wie „Schreiben“. Ein Agent, der eine Deployment-Revision erstellen kann, und ein Agent, der ein Deployment entfernen kann, besitzen beide Schreibrechte, aber die möglichen Folgen sind überhaupt nicht vergleichbar.

Erfasse, ob die geplante Aktion Lesen, Erstellen, Ändern, Löschen, Ausführen oder eine administrative Änderung bedeutet. „Ausführen“ verdient besondere Aufmerksamkeit. Ein API-Aufruf, der einen Cloud-Job startet, einen Dienstzugang rotiert, einen Zahlungsvorgang auslöst oder eine entfernte Shell ausführt, kann in einem Anfrageprotokoll harmlos aussehen und downstream trotzdem ein teures oder irreversibles Ergebnis verursachen.

Mach aus dem Arbeitsblatt kein juristisches Dokument voller schwammiger Formulierungen. „Nur bei Bedarf verwenden“ und „normale Deployment-Arbeit“ setzen keine Grenze. Niemand kann dagegen eine Genehmigung erteilen, und kein Engineer kann daraus Kontrollen bauen. Hängt die Aktion vom Kontext ab, nenne den Kontext: eine bestimmte Umgebung, ein Repository, eine Hostgruppe, ein Konto oder eine Änderungsart.

Die verbreitete Abkürzung besteht darin, einen allgemeinen Administrator-Token zu vergeben und sich darauf zu verlassen, dass der Agent aufgrund seiner Eingabeaufforderung gefährliche Aufrufe vermeidet. Sie ist beliebt, weil ein Prototyp damit in wenigen Minuten läuft. Sie ist falsch, weil Eingabeaufforderungen keine Zugriffskontrolle sind und spätere Tool-Aufrufe die weitreichende Berechtigung übernehmen können, ohne dass die Person, die die Eingabeaufforderung geschrieben hat, es bemerkt.

Umgebungen brauchen getrennte Zeilen und getrennte Folgen

Ein Staging-Zugang und ein Produktionszugang sollten niemals dieselbe Zeile teilen, nur weil sie dieselbe API aufrufen. Die verantwortlichen Personen können identisch sein, aber Zielkonto, Datenrisiko, Genehmigungsanforderung und Dringlichkeit des Widerrufs unterscheiden sich oft.

Behandle die Umgebung nicht bloß als Bezeichnung. Erfasse Anbieter-Konto oder Mandant, Endpunkt oder Hostgruppe, Datenklassifizierung und die Frage, ob ein Aufruf eine Umgebungsgrenze überschreiten kann. „Prod“ ist zu vage, wenn eine Organisation mehrere Produktionskonten, Regionen oder Kundenbereiche hat.

Ein brauchbares Umgebungsfeld könnte so aussehen:

Produktion / Mandant 4821 / Kundendaten / Endpunkt api.example.internal

Trage keinen tatsächlichen internen Hostnamen in ein Arbeitsblatt ein, das viele Personen lesen können, wenn der Hostname selbst sensibel ist. Entscheidend ist, das Ziel für das berechtigte Team präzise genug zu benennen. Die Zugriffsrichtlinie für das Verzeichnis sollte zur Sensibilität seiner betrieblichen Details passen.

Füge ein eigenes Feld für die Daten hinzu, die ein Agent in der Antwort erhalten kann. Die Berechtigung, einen Endpunkt aufzurufen, und die Berechtigung, seine Antwort zu sehen, sind verwandte, aber nicht identische Risiken. Eine Leseanfrage kann Quellcode, Kontaktdaten von Kunden, Rechnungen, Zugriffsmetadaten oder ein Geheimnis aus einem alten Konfigurationswert zurückgeben.

Damit wird ein häufiges Fehlermuster sichtbar. Ein Team erstellt einen Agent-Zugang für „Nur-Lese-Diagnosen“ in Staging. Später richtet ein Entwickler den Diagnose-Client während eines Vorfalls auf die Produktion, weil die Befehlssyntax identisch ist. Der Zugang funktioniert, weil der Anbieter den Umfang auf Kontoebene festgelegt hat, und der Agent gibt Kundendaten in seinem Protokoll aus. Die ursprüngliche Zeile hätte die fehlende Grenze offengelegt, wenn sie statt „Diagnose lesen“ den Mandanten und die Antwortdaten genannt hätte.

Kann ein Anbieter Umgebungen nicht voneinander trennen, darfst du das nicht durch Wunschdenken in der Dokumentation ausgleichen. Markiere den Zugang als umgebungsübergreifend, erhöhe seine Genehmigungsstufe und entscheide, ob ein Agent ihn überhaupt verwenden sollte. Die ehrliche Antwort lautet manchmal nein.

SSH-Zugriff braucht mehr Details als API-Zugriff

SSH-Zugangsdaten brauchen eigene Felder, weil eine SSH-Verbindung mehrere Arten von Berechtigungen gleichzeitig übertragen kann. Anmeldekonto, akzeptierte Hosts, Befehlsbeschränkungen, Weiterleitungsrechte und die Einstellung für Agent-Weiterleitung verändern, was die Verbindung tun kann.

Erfasse für jede SSH-Zeile den Fingerabdruck des öffentlichen Schlüssels, den Speicherort des privaten Materials, das Anmeldekonto, den Host oder die Hostgruppe und den genau vorgesehenen Befehl. Kopiere den privaten Schlüssel nicht in das Blatt. Ein SHA256-Fingerabdruck reicht zur Identifikation aus und kann lokal ermittelt werden.

Führe diesen Befehl für die Datei mit dem öffentlichen Schlüssel aus:

ssh-keygen -lf ~/.ssh/id_agent_deploy.pub

Ein normales Ergebnis hat diese Form:

256 SHA256:AbCdEfGhIjKlMnOpQrStUvWxYz0123456789abcd agent-deploy (ED25519)

Speichere den Wert SHA256: und den Kommentar nur dann, wenn der Kommentar Menschen bei der Zuordnung der Rolle hilft. Kommentare sind keine Sicherheitskontrollen. Jeder kann sie ändern, wenn er einen öffentlichen Schlüssel kopiert.

Prüfe bei den Zielhosts die Einschränkungen in authorized_keys, statt anzunehmen, dass ein Deploy-Konto begrenzt ist, nur weil das beabsichtigt ist. OpenSSH dokumentiert Optionen wie command=, no-port-forwarding, no-agent-forwarding und no-pty im Handbuch zu sshd. Diese Einschränkungen können aus einer Automatisierungsidentität einen Befehlsausführer mit begrenzten Rechten machen. Sie können jedoch keinen Zugang reparieren, der sich als uneingeschränktes Administratorkonto anmeldet.

Ein Eintrag könnte lauten: „Anmeldung als deploy, Hosts der Release-Gruppe A, erzwungener Befehl /usr/local/bin/release-catalog, keine Portweiterleitung, kein PTY, keine Agent-Weiterleitung.“ Wenn der Zugriff für Notfallarbeiten eine interaktive Shell braucht, erstelle eine separate, von Menschen verwendete Identität. Verwende nicht stillschweigend die Agent-Identität weiter, nur weil sie bereits verfügbar ist.

Auch die Hostprüfung gehört in den Nachweis. Halte fest, wie die Agent-Integration die Hostidentität prüft, wo die Known-Hosts-Einträge liegen und wer sie nach dem legitimen Austausch eines Hosts aktualisiert. Die Hostprüfung zu deaktivieren, um einen Wiederaufbau zu überstehen, lädt dazu ein, gültige Zugangsdaten an den falschen Rechner zu senden.

Ein brauchbares Arbeitsblatt erzwingt klare Antworten

Kopiere diese Vorlage in ein geschütztes Dokument, ein Ticketsystem oder eine Verzeichnisdatenbank. Entferne Spalten, die dein Team nicht pflegen kann, aber nicht die Felder, die Berechtigung, Umfang und Wiederherstellung festlegen.

Die Spalte Agent-Pfad erzwingt eine wichtige Frage: Wie erhält der Agent die Wirkung dieses Zugangs? „Umgebungsvariable in der Coding-Shell“ ist eine Antwort, sollte dich aber beunruhigen, weil der Prozess sie ausgeben, übertragen oder dauerhaft speichern kann. „Aktions-Gateway führt die Anfrage aus und gibt die Antwort zurück“ beschreibt ein anderes Design mit einem kleineren Offenlegungspfad.

Das Feld Widerrufsmethode sollte von einer anderen Person ausgeführt werden können. „Sam fragen“ ist keine Methode. „Token in den Projekteinstellungen des Anbieters deaktivieren und anschließend die aktive Agent-Sitzung widerrufen“ ist eine Methode. Teste diese Anweisung beim ersten Anlegen der Zeile, bevor ein Vorfall jede Konsolenseite unbekannt wirken lässt.

Vermeide ein Statusfeld, das lediglich „aktiv“ oder „inaktiv“ sagt. Nimm zuletzt verwendet, zuletzt geprüft und geplante Ausmusterung auf. Ein ungenutzter Zugang ist nicht harmlos. Oft ist es genau der Zugang, dessen Widerruf niemand nach dem Ende eines Projekts bedacht hat.

Rotationspläne müssen Ersatz und Nachweis enthalten

Eine Rotation ist erst abgeschlossen, wenn der alte Zugang deaktiviert wurde und der Ersatz über den echten Agent-Pfad eine vorgesehene Aktion erfolgreich ausgeführt hat. Einen neuen Token zu erstellen, ihn im Speicher abzulegen und den alten später zu bearbeiten, lässt beide Identitäten aktiv. Bei einem Vorfall verdoppelt das den Aufwand.

Ein Rotationsplan sollte fünf betriebliche Fakten nennen:

1. Das Ereignis, das die Rotation auslöst, etwa geplantes Ablaufdatum, Ausscheiden einer Person, vermutete Offenlegung oder Änderung des Umfangs.
2. Die Person, die den Ersatz erstellt, und die Person, die die geänderte Berechtigung genehmigt.
3. Der Ort, an dem das neue Material gespeichert wird, ohne den Agent zu erreichen.
4. Die eng begrenzte Testaktion, die den Ersatz bestätigt.
5. Der genaue Zeitpunkt, zu dem das alte Material widerrufen und der Nachweis festgehalten wird.

Verwende einen engen Test. Bei einem HTTP-Zugang rufst du einen harmlosen Endpunkt auf, der den vorgesehenen Umfang erfordert, und bestätigst Status und Form der Antwort. Bei SSH führst du den erzwungenen Statusbefehl für das Deployment in der freigegebenen Hostgruppe aus, statt mit einer allgemeinen Shell-Anmeldung zu testen.

Ein Testnachweis kann so schlicht sein:

Zugang-ID: api-catalog-deploy-prod-01
Suffix der Ersatz-ID: ...7KQ2
Test: POST /deployments/validate für catalog-api, Revision 8f3c
Erwartet: HTTP 200 mit Validierungsstatus accepted
Alter Zugang widerrufen: Anbieter-Audit-Ereignis aufgezeichnet
Prüfer: Verantwortlicher des Produktionsdienstes

Lege keine Rotationsintervalle fest, die dein Team nicht einhalten kann. Ein kurzes Intervall mit wiederholten Ausnahmen bringt die Menschen dazu, das Verzeichnis für Fiktion zu halten. Nutze das Ablaufdatum des Anbieters, wo es verfügbar ist, definiere ereignisgesteuerte Auslöser und plane einen Prüfrhythmus, der zum Risiko passt. Produktionszugänge mit Schreibrechten, weitreichende Lesezugriffe auf sensible Daten und SSH-Zugriff auf gemeinsam genutzte Hosts verdienen mehr Aufmerksamkeit als ein kurzlebiger Staging-Token ohne sensible Antwortdaten.

Wenn eine Offenlegung vermutet wird, widerrufe den Zugang zuerst, sofern der Dienst das verkraftet. Teams verschwenden Zeit damit, herauszufinden, ob ein geleakter Token aus einem Terminalpuffer, CI-Log, Prompt-Protokoll oder lokalen Verlauf kopiert wurde. Du brauchst diesen Beweis normalerweise nicht, bevor du den Zugang stoppst. Sichere die Logs, ersetze den Zugang und untersuche danach den Weg.

Die Genehmigung eines Agents sollte den Folgen des Aufrufs folgen

Ein Agent-Lauf hat einen Lebenszyklus, den gewöhnliche Skripte oft nicht haben: Eine Person kann ihn starten, ihn weiterarbeiten lassen, später zurückkehren und feststellen, dass er viele externe Aufrufe gemacht hat. Das Arbeitsblatt sollte daher festhalten, wann eine menschliche Genehmigung erforderlich ist, nicht nur, wer für den Zugang verantwortlich ist.

Eine Genehmigung pro Sitzung passt zu einem begrenzten Lauf mit einem vertrauenswürdigen, identifizierten lokalen Agent-Prozess und geringen bis mittleren Folgen. Sie bestätigt, dass dieser Prozess die aufgeführten Berechtigungen verwenden darf, solange er läuft. Das bedeutet nicht, dass jeder spätere Aufruf automatisch freigegeben ist.

Fordere eine Genehmigung bei jeder Verwendung für Vorgänge, die veröffentlichen, deployen, Produktionsdaten ändern, Antworten mit hoher Sensibilität erreichen oder eine neue externe Verpflichtung schaffen können. Der zusätzliche Klick ist günstiger, als einem Kunden oder einem Finanzteam eine unbeabsichtigte Aktion erklären zu müssen. Verwende einen separaten Zugang für Aktionen mit einer anderen Genehmigungsstufe, sofern der Anbieter das unterstützt.

Eine Genehmigung ersetzt keinen begrenzten Umfang. Ein Mensch kann das Falsche genehmigen, weil die Beschreibung der Anfrage unklar war, die Aktion während eines Vorfalls eintraf oder der Agent in kurzer Folge mehrere ähnliche Aufrufe machte. Begrenze die Berechtigungen zuerst und nutze die Genehmigung anschließend für das verbleibende Risiko, das sich durch den Umfang nicht ausdrücken lässt.

Sallyport bewahrt API- und SSH-Zugangsdaten in einem verschlüsselten Tresor auf dem Mac auf. Es kann eine Genehmigung für einen neuen Agent-Prozess oder für jede Verwendung eines ausgewählten Zugangs verlangen, während der Agent Ergebnisse statt Geheimnisse erhält.

Ein gutes Arbeitsblatt verknüpft jede Zeile mit weitreichenden Folgen mit den Audit-Nachweisen, die nach der Verwendung erwartet werden. Erfasse, sofern zutreffend, Sitzungs-ID oder Speicherort des Laufjournals, Aktivitätsnachweis auf Aufrufebene, Ziel, Zeitstempel, Ergebnis und genehmigende Person. Kann der Nachweis nicht zeigen, welcher Zugang zu welchem Ergebnis geführt hat, ist die Agent-Integration für die erteilte Berechtigung zu undurchsichtig.

Audit-Nachweise klären die Fragen nach einem schlechten Lauf

Das Verzeichnis dient der Vorbeugung. Audit-Nachweise beantworten nach einem unerwarteten Verhalten des Agents eine andere Frage: Was hat er tatsächlich versucht, was war erfolgreich und welche Berechtigung hat es ermöglicht? Vermische diese Aufgaben nicht. Ein sorgfältig gepflegtes Arbeitsblatt beweist nicht, dass ein Aufruf stattgefunden hat, und ein Log beweist nicht, dass eine Berechtigung gerechtfertigt war.

Baue eine Notfallübung rund um eine Zeile des Verzeichnisses. Lass eine zuständige Person den Verantwortlichen finden, den Zugang widerrufen, den aktuellen Agent-Zugriff stoppen, den letzten erfolgreichen Aufruf ermitteln und prüfen, dass die Audit-Spur nicht verändert wurde. Miss die Verwirrung, nicht die verstrichene Zeit. Können die Beteiligten das Zielkonto nicht nennen oder den alten Token nicht vom Ersatz unterscheiden, müssen die Felder des Arbeitsblatts verbessert werden.

Manipulationsnachweise sind wichtig, wenn mehrere Personen Logs prüfen oder exportieren können. Eine einfache Nur-Anhängen-Datenbank kann von einem Administrator mit ausreichenden Rechten verändert und anschließend als Historie präsentiert werden. Ein hashverkettetes Log macht unerlaubte Änderungen erkennbar, wenn die Kette mit der gespeicherten Reihenfolge abgeglichen wird. Es macht die ursprüngliche Anfrage nicht klug und verhindert nicht, dass eine berechtigte Person einen schlechten Aufruf macht. Das sind getrennte Kontrollen.

Halte die Entscheidung zur Audit-Aufbewahrung zusammen mit dem Verzeichniseintrag fest, besonders wenn Antworten sensible Ausgaben enthalten können. Ein Aktivitätsnachweis sollte genug Kontext für eine Untersuchung bewahren, ohne vollständige Kundennutzdaten dauerhaft und unbedacht zu speichern. Speichere möglichst Anfragemetadaten und Ergebnisstatus. Vollständige Antworten solltest du nur erfassen, wenn das wirklich nötig und erlaubt ist.

Die erste Zeile, die du ausfüllen solltest, gehört zu dem Zugang, mit dem ein Agent heute eine Produktionsänderung vornehmen kann. Benenne das Ziel genau, formuliere das erlaubte Verb konkret, schreibe die Widerrufsanweisung so, dass eine andere Person ihr folgen kann, und teste den Ersatzweg. Enthält diese Zeile Vermutungen, ist der Rest des Verzeichnisses Dekoration.