# Aktionskatalog für AI-Agents: Zugriff finden, den du nicht brauchst Ein Aktionskatalog für einen AI-Agent ist der schnellste Weg, Berechtigungen zu finden, die niemand bewusst ausgewählt hat. Er listet die Vorgänge auf, die ein Agent außerhalb seines eigenen Arbeitsbereichs ausführen kann, und verlangt für jeden eine Entscheidung: Wem gehört die Aktion, was passiert bei einem Fehler und muss ein Mensch sie genehmigen? Die meisten Teams beginnen an der falschen Stelle. Sie erfassen API-Schlüssel, Integrationen oder Softwarekonten und glauben anschließend, den Zugriff zu verstehen. Das tun sie nicht. Eine Zugangsdaten ist nur ein Behälter. Die Sicherheitsentscheidung liegt auf Ebene der einzelnen Aktion: «Eine Rechnungsentwurf erstellen» unterscheidet sich deutlich von «Eine Rückerstattung auslösen», selbst wenn beide Aufrufe dasselbe Token verwenden. Ich habe erlebt, wie Berechtigungsprüfungen scheiterten, weil ein Team fragte: «Braucht der Agent Zugriff auf das Abrechnungssystem?» Diese Frage ist zu allgemein, um sie ehrlich zu beantworten. Frage stattdessen, ob er eine einzelne Rechnung lesen, einen Entwurf erstellen, eine Rückerstattung einreichen, Auszahlungsdaten ändern oder die Kundenliste exportieren muss. Die Antworten unterscheiden sich meist. In diesen Unterschieden zeigt sich der unnötige Zugriff. ## Eine Integrationsliste verbirgt die wichtigen Berechtigungen Ein Systeminventar zeigt, womit sich ein Agent verbindet. Ein Aktionskatalog zeigt, was er bewirken kann. Führe beides, aber verwechsle sie nicht. Betrachte einen Agent, der mit einem Quellcodeverwaltungssystem verbunden ist. «Repository-Zugriff» kann das Lesen von Code, das Eröffnen eines Pull Requests, das Ändern des Branch-Schutzes, das Erstellen eines Deployment-Schlüssels, das Veröffentlichen eines Releases oder das Löschen eines Repositorys umfassen. Diese Sammlung als eine einzige Berechtigung zu behandeln, macht aus mehreren getrennten Risikoentscheidungen ein bequemes Ja oder Nein. Der gleiche Fehler tritt bei SSH auf. «Der Agent kann sich per SSH mit Staging verbinden» sagt fast nichts aus. Ein eingeschränkter Befehl, der den Dienststatus abruft, hat andere Folgen als Shell-Zugriff über ein Konto, das Dienste neu starten, Deployment-Geheimnisse lesen oder Firewall-Regeln ändern kann. Katalogisiere die Befehlsfamilie oder den Endpunkt, nicht nur das Transportprotokoll. Der Unterschied ist wichtig, weil Teams zwei Dimensionen der Gefährdung regelmäßig vermischen: - **Erreichbarkeit** bedeutet, dass der Agent ein System kontaktieren kann. - **Befugnis** bedeutet, was das System nach dem Kontakt erlaubt. - **Folge** bedeutet, was passiert, wenn der Agent eine falsche oder manipulierte Anfrage stellt. Ein interner Endpunkt kann schwer erreichbar sein und trotzdem sehr weitreichende Befugnisse haben. Eine öffentliche API kann breit erreichbar sein, aber nur begrenzte Befugnisse bieten. Ein Genehmigungsdesign, das sich nur daran orientiert, ob ein Dienst «intern» ist, übersieht beide Fälle. NIST Special Publication 800-53, Kontrolle AC-6, beschreibt das Prinzip der geringsten Rechte als die Vergabe genau der Zugriffe, die für die zugewiesenen Aufgaben erforderlich sind. Das klingt selbstverständlich, bis man es auf einen Agent anwendet. «Zugewiesene Aufgabe» darf nicht «bei der Entwicklung helfen» bedeuten. Gemeint sein muss eine Aktion mit Ziel, Methode, Grenze und erwartetem Ergebnis. Wenn du das nicht aufschreiben kannst, kannst du auch nicht behaupten, dem Prinzip der geringsten Rechte zu folgen. Beginne mit Aktionsnamen, die ein Prüfer versteht, ohne ein Code-Repository zu öffnen. «POST /v1/issues» ist ein nützlicher Nachweis, aber «Issue im Engineering-Tracker erstellen» sagt dem Eigentümer, was er genehmigt. Halte beides im Datensatz fest. ## Eine Zeile für jede extern sichtbare Aktion Jede Katalogzeile sollte die kleinstmögliche Aktion darstellen, für die eine eigene Zugriffs- oder Genehmigungsentscheidung getroffen werden kann. Wenn zwei Vorgänge sinnvollerweise unterschiedliche Eigentümer, Auswirkungen oder Genehmigungsanforderungen haben können, brauchen sie getrennte Zeilen. Eine praktische Zeile enthält genug Details, damit ein Entwickler eine Kontrolle umsetzen kann, und genug Klartext, damit der Systemeigentümer sie ablehnen kann. Verwende diese Felder: | Feld | Was festgehalten wird | Zweck | |---|---|---| | Aktions-ID | Stabile Kennung, etwa `deploy.production.restart-service` | Bewahrt die Entscheidung, wenn sich Namen ändern | | System | Zielsystem und Umgebung | Trennt Produktions- und Testzugriff | | Aktion | Verständliches Verb und Objekt | Macht die Berechtigung prüfbar | | Technischer Weg | API-Methode und Pfad, Befehlsmuster oder Tool-Aufruf | Ermöglicht die technische Durchsetzung der Grenze | | Identität | Zugangsdatenart, Konten, Berechtigungsbereiche und Delegationsmodell | Macht geteilte oder übergroße Befugnisse sichtbar | | Verarbeitete Daten | Gesendete Eingaben und zurückgegebene Ausgaben | Zeigt das Risiko von Datenabfluss | | Auswirkungen | Folgenkategorie und Reversibilität | Steuert die Genehmigungsentscheidung | | Eigentümer | Benannte fachliche oder technische entscheidende Person | Gibt der Berechtigung eine verantwortliche Person | | Genehmigung | Keine, pro Sitzung oder pro Aufruf | Definiert den menschlichen Kontrollpunkt | | Nachweis | Test, Log-Referenz oder Implementierungsort | Belegt, dass die Zeile der Realität entspricht | | Prüfdatum | Datum und Prüfer | Verhindert, dass alte Ausnahmen dauerhaft bestehen | Schreibe in ein Aktionsfeld nicht «verschieden», «Admin-Aufgaben», «vollständige API» oder «nach Bedarf». Diese Formulierungen bedeuten, dass der Katalog endet, bevor die eigentliche Arbeit beginnt. Teile den Eintrag auf, bis eine Person ohne zu raten Ja oder Nein sagen kann. Hier ein kompaktes Beispiel für einen Entwicklungsagent: ```yaml action_id: issue-tracker.create-bug system: issue tracker, production tenant operation: Create a bug report in the Engineering project technical_route: POST /api/projects/engineering/issues identity: service account agent-issues, scope issues:write inputs: title, body, labels, repository reference outputs: issue ID and URL impact: internal write, reversible by project members owner: Engineering operations manager approval: per-session review_date: 2026-09-30 ``` Die Bezeichnung «production tenant» gehört in diese Zeile, selbst wenn die Aktion nur Tickets erstellt. Viele Teams verwenden einen einzigen produktiven SaaS-Mandanten für echte Kunden-, Mitarbeiter- und Vorfallinformationen. Die Umgebungsbezeichnung zeigt den Prüfern, welche Grenze sie überschreiten. Vermeide falsche Präzision. Du brauchst keine eigene Zeile für jedes harmlose Feldupdate, wenn Ziel, Eigentümer, Identität, Genehmigung und Folge wirklich identisch sind. Separate Zeilen sind nötig, wenn ein besonderes Feld das Ergebnis verändert. «Vorfallstatus aktualisieren» und «Incident Commander ändern» können über denselben Endpunkt laufen, sollten aber nicht dieselbe Genehmigungsentscheidung erhalten. ## Aktionen über Zugangsdaten und Abläufe finden Die vollständige Aktionsmenge findest du nicht durch das Lesen eines Agent-Prompts. Prompts beschreiben Absichten. Code, Konfiguration, Zugangsdaten und beobachteter Datenverkehr zeigen, was der Agent tatsächlich anfordern kann. Beginne mit den Abläufen, die der Agent nach den Erwartungen des Teams ausführen soll. Bitte Entwickler, die letzten zehn Aufgaben zu beschreiben, die sie ihm gegeben haben oder geben wollen, und dabei Verben zu verwenden. «Einen fehlgeschlagenen Build untersuchen» kann das Lesen von Logs, eine Abfrage des Deployment-Dienstes, das Eröffnen eines Issues, den Neustart einer Testumgebung und das Veröffentlichen einer Nachricht umfassen. Erfasse jede überschrittene externe Grenze. Arbeite anschließend von jeder Zugangsdaten zurück. Prüfe API-Bereiche, OAuth-Gewährungen, Rollen von Dienstkonten, autorisierte SSH-Schlüssel, Befehls-Wrapper, CI-Variablen und lokale Geheimnisspeicher. Zugangsdaten machen oft Aktionen sichtbar, die niemand im Workflow-Gespräch genannt hat. Ein API-Token mit Benutzerverwaltungsrechten ist ein Kandidat für den Katalog, selbst wenn das Team darauf besteht, dass der Agent nur Tickets anlegt. Vergleiche zum Schluss die Absicht mit den Nachweisen. Netzwerkspuren, API-Gateway-Logs, Befehlsauditaufzeichnungen und Agent-Tooldefinitionen zeigen Aufrufe, die im Workflow-Dokument fehlen. Führe diesen Schritt nach Möglichkeit zuerst in einer sicheren Testumgebung aus. Produktionslogs bleiben trotzdem wichtig, weil Agents und Menschen unter Zeitdruck Abkürzungen entdecken. Verwende diese Routine mit fünf Durchgängen: 1. Liste jeden Agent-Workflow auf, der über die lokale Aufgabe hinausreicht. 2. Extrahiere aus Konfiguration und Code jeden Tool-Aufruf, Endpunkt und jedes Shell-Befehlsmuster. 3. Ermittle, was jede Zugangsdaten erlaubt, einschließlich geerbter Rollen und Wildcard-Bereiche. 4. Prüfe aktuelle Aktionslogs auf Ziele oder Verben, die in der Liste fehlen. 5. Kläre die Unterschiede mit der Person, der das Zielsystem gehört. Im vierten Durchgang tauchen die unangenehmen Erkenntnisse auf. Vielleicht findest du ein altes Token mit umfassender Repository-Administration, einen Staging-SSH-Schlüssel, der von Produktionshosts akzeptiert wird, oder einen «internen» Webhook, der ein Release auslösen kann. Reduziere den Eintrag nicht stillschweigend, damit er zum ursprünglichen Plan passt. Nimm die tatsächlich mögliche Aktion in den Katalog auf und lass jemanden entscheiden, ob sie bestehen bleibt. Ein guter Test ist, die Zeile einer Kollegin zu geben, die die Integration nicht gebaut hat. Sie sollte erklären können, was der Agent sendet, was er zurückbekommt und welcher plausible Fehler am schlimmsten wäre. Kann sie das nicht, ist die Zeile technischer Ballast und kein Kontrollnachweis. ## Auswirkungen brauchen Folgen, keine allgemeine Risikozahl Ordne Auswirkungen danach ein, was eine falsche Aktion verändert, offenlegt, ausgibt oder verbindlich festlegt. Eine einzige Bewertung «hoch, mittel, niedrig» reicht nicht, weil sie den Grund verschweigt, aus dem eine Aktion menschliche Aufmerksamkeit braucht. Ich verwende im Katalog fünf Folgenkategorien: Offenlegung, Integrität, Verfügbarkeit, externe Verpflichtung und Berechtigungsänderung. Eine Zeile kann mehrere Kategorien tragen. Das Lesen eines Kundenexports hat eine Folge für die Offenlegung. Das Löschen einer Bereitstellung verändert die Verfügbarkeit. Das Hinzufügen eines Administrators verändert Berechtigungen. Das Senden eines Vertrags erzeugt eine externe Verpflichtung, selbst wenn die Aktion technisch rückgängig gemacht werden kann. Füge zwei weitere Merkmale hinzu: Reversibilität und Wirkungsradius. Bei der Reversibilität geht es darum, ob eine kompetente Person die Aktion ohne Verlust oder Verwirrung rückgängig machen kann. Der Wirkungsradius fragt, ob ein Fehler einen Entwurf, ein Projekt, viele Benutzer oder eine gesamte Umgebung betrifft. So entstehen Entscheidungen, die sich begründen lassen. «Temporären Test-Branch löschen» kann eine reversible und begrenzte Integritätsänderung sein. «Produktionsdatenbank-Zugangsdaten rotieren» kann zwar die Sicherheit verbessern, aber auch die Verfügbarkeit vieler Dienste beeinträchtigen. Beides sind Schreibaktionen, gehören aber in unterschiedliche Genehmigungskategorien. Lass dich bei der Reversibilität nicht mit «Die API unterstützt Rückgängigmachen» abspeisen. Eine Rückerstattung kann im Hauptbuch rückgängig gemacht werden, während der Kunde bereits eine verwirrende E-Mail erhalten hat. Ein veröffentlichtes Paket kann zurückgezogen werden, nachdem nachgelagerte Systeme es abgerufen haben. Ein gelöschtes Konto kann wiederhergestellt werden, während sein früherer Eigentümer während eines Vorfalls den Zugriff verliert. Betrachte die betriebliche Folge und nicht nur den Datenbankvorgang. Die von einer Aktion zurückgegebenen Daten verdienen dieselbe Aufmerksamkeit wie die gesendeten Daten. Eine scheinbar harmlose Statusabfrage, die vollständige Umgebungsvariablen, Supportverläufe oder private Schlüssel zurückgibt, ist eine Offenlegungsaktion. Teams konzentrieren sich oft zu stark auf Schreibzugriffe, weil Schreiben aktiv wirkt. Ein Agent, der alle Geheimnisse lesen und anschließend einen externen Endpunkt aufrufen kann, verfügt über genug Zugriff für einen schweren Vorfall. Formuliere Auswirkungen konkret. Ersetze «hohe Auswirkungen» durch «kann die Produktionsautorisierung für alle Mitglieder des Arbeitsbereichs ändern» oder «kann Kundenkennungen an eine Drittanbieter-API übertragen». Die erste Beschreibung sagt dem Eigentümer, was er entscheiden muss. Das Etikett allein tut es nicht. ## Eigentümer müssen Nein sagen können Jede Aktion braucht einen benannten Eigentümer, der sie ablehnen, einschränken oder entfernen kann. Diese Person besitzt die Berechtigungsentscheidung, nicht jedes operative Ergebnis, das der Agent erzeugt. Der beste Eigentümer gehört meist zum Zielsystem oder trägt die geschäftliche Folge. Eine Engineering-Leitung kann für Produktionsbereitstellungen zuständig sein. Die Finanzabteilung besitzt die Einreichung von Rückerstattungen. Das Sicherheitsteam kann Bedingungen für die Zugriffsverwaltung festlegen, sollte aber nicht automatisch Eigentümer jeder Zeile werden, nur weil es das Sicherheitsteam ist. Gemeinsame Eigentümerschaft lässt Kataloge verfallen. «Sicherheit und Engineering» bedeutet, dass jede Gruppe annimmt, die andere werde prüfen. Trage eine einzige verantwortliche Person ein und führe beteiligte Teams bei Bedarf in den Notizen auf. Wenn ein Eigentümer die Stelle oder das Team wechselt, übertrage die Katalogzeilen als Teil der Übergabe. Eigentümer brauchen ein Entscheidungspaket, das auf einen Bildschirm passt. Gib ihnen Aktion, System, effektive Identität, betroffene Daten, Folge, vorgeschlagene Genehmigung und einen kurzen Grund für den Zugriff des Agents. Eine rohe Liste von OAuth-Bereichen ist keine Governance. Der Eigentümer sollte vier Fragen beantworten: - Braucht der Agent dieses Ergebnis, oder ist es nur für den Workflow bequem? - Kann ein engerer Endpunkt, eine kleinere Rolle, ein anderes Konto, ein begrenzteres Ziel oder ein eingeschränkter Befehl dasselbe Ergebnis liefern? - Welcher Fehler hätte eine nicht akzeptable Folge? - Wer sollte die Nutzung genehmigen, und wann sollte diese Entscheidung ablaufen? Die unangenehme Frage ist meist die erste. Teams gewähren oft eine weitreichende Aktion, weil sie damit ein späteres Gespräch vermeiden. Das ist keine Anforderung, sondern eine aufgeschobene Zugriffsprüfung mit angehängten Zugangsdaten. Mach die Eigentümerschaft im Ausführungspfad sichtbar. Wenn bei einem Vorfall niemand den Eigentümer identifizieren kann, hat der Katalog seine Aufgabe nicht erfüllt. Ein benannter Eigentümer macht auch regelmäßige Prüfungen praktikabel, denn die Frage lautet direkt: «Genehmigst du die Aktion X für diesen Agent und diese Identität weiterhin?» ## Die Genehmigung muss zum Moment der Verpflichtung passen Eine Genehmigung ist sinnvoll, wenn sie vor dem Punkt erscheint, an dem der Agent eine Folge auslöst, und wenn der Prüfer versteht, was er erlaubt. Eine Schaltfläche mit «Tool-Nutzung erlauben», nachdem der Agent zehn unzusammenhängende Aktionen gebündelt hat, ist nur Sicherheitstheater. Verwende im Katalog drei Genehmigungszustände. «Keine» bedeutet, dass die Aktion ausgeführt werden kann, sobald der Agent seine Sitzungsberechtigung erhalten hat. «Pro Sitzung» bedeutet, dass ein Mensch einen konkreten Agent-Prozess genehmigt, bevor dieser autorisierte Aktionen aufrufen kann. «Pro Aufruf» bedeutet, dass ein Mensch jede Nutzung dieser Aktion prüft. Eine Genehmigung pro Sitzung eignet sich für enge, regelmäßige Aktionen mit überschaubaren Folgen, etwa das Lesen des Build-Status oder das Erstellen interner Entwurfstickets. Sie bestätigt, dass der vorgesehene Agent-Prozess aktiv ist, und lässt ihn die normale Arbeit erledigen, ohne dass jemand wiederholt auf Bestätigungen klicken muss. Eine Genehmigung pro Aufruf passt zu Aktionen, die eine Verpflichtung erzeugen oder eine schwierige Grenze überschreiten. Verwende sie für Änderungen an Produktionszugriffen, das Löschen wichtiger Datensätze, kundenwirksame Bereitstellungen, Nachrichten außerhalb des Unternehmens, Geldtransaktionen und den Export sensibler Datensätze. Hier ist es angemessen, dass ein Mensch jede Anfrage prüft. Der Genehmigungsdatensatz braucht Kontext. Zeige mindestens die Identität des aufrufenden Prozesses, die Aktion, das Ziel, die Zielumgebung und die wesentlichen Parameter. «Agent fordert POST an» zwingt den Prüfer, die Aktion unter Druck zu rekonstruieren. «Zahlungsdienst in Produktion neu starten, angefordert von signiertem Prozess X» ermöglicht eine echte Entscheidung. Verwende Genehmigungsdialoge nicht als Ausgleich für eine Berechtigung, die gar nicht existieren sollte. Ein Dialog pro Aufruf für «beliebigen Shell-Befehl in Produktion ausführen» lässt den Prüfer weiterhin wiederholt einen Blankoscheck unterschreiben. Ersetze die weitreichende Shell-Fähigkeit durch eingeschränkte Befehle oder getrennte Aktionen und genehmige diese bei Bedarf. Der Aktions-Gateway ist hier wichtig, weil er Zugangsdaten vom Agent fernhalten und die menschliche Entscheidung nahe an der Ausführung platzieren kann. Sallyport verwendet eine feste Entscheidungskette: Ein gesperrter Tresor verweigert jede Aktion, ein neuer Agent-Prozess erhält standardmäßig eine Genehmigung pro Sitzung und ausgewählte Schlüssel können bei jeder Verwendung eine Genehmigung verlangen. Diese Struktur vermeidet einen häufigen Fehler: eine umfangreiche Regelsprache zu erfinden, bevor die Aktionen so gut katalogisiert sind, dass sichere Regeln möglich wären. Komplexe Richtlinien wirken in einem Entwurfsdokument ausgereift und werden unprüfbar, sobald Ausnahmen hinzukommen. Beginne mit klaren Aktionen, engen Identitäten und Genehmigungen, die zu den Auswirkungen passen. ## Ein Katalog zeigt den Fehlerpfad, bevor es die Produktion tut Ein Katalog bewährt sich, wenn er eine Kette gewöhnlicher Entscheidungen erkennt, die einzeln akzeptabel wirkt. Stell dir einen Coding-Agent vor, der untersuchen soll, warum ein Bestellablauf fehlgeschlagen ist. Ein Entwickler gibt ihm ein Diensttoken, weil dieses Logs lesen kann. Dasselbe Token darf auch die Bestell-API abfragen. Der Agent findet eine fehlerhafte Bestellung und erhält die Anweisung, «Testdaten aufzuräumen». Er ruft einen Löschendpunkt im produktiven Mandanten auf, weil die Integration Mandantennamen nicht eindeutig trennt. Der Endpunkt akzeptiert die Anfrage. Später erkennt ein Mensch, dass die Bestellung echt war, doch ihre Wiederherstellung erfordert einen Abgleich zwischen Zahlungs-, Inventar- und Kundensupportsystemen. Jede einzelne Aussage klang harmlos: Logs lesen, Bestellungen abfragen, Testdaten entfernen. Der Aktionskatalog hätte die Kette in Zeilen aufgeteilt: | Aktion | Verstecktes Problem | Bessere Entscheidung | |---|---|---| | Logs des Bestellablaufs lesen | Logs enthalten Kundenkennungen | Zurückgegebene Felder begrenzen und Offenlegungsfolgen dokumentieren | | Bestellung nach ID abfragen | Token erlaubt weitreichenden Bestellzugriff | Eine schreibgeschützte Identität auf den erforderlichen Mandanten begrenzen | | Testbestellung löschen | Produktion und Test teilen eine Endpunktfamilie | Zielumgebungen trennen und Genehmigung pro Aufruf verlangen | | Kundenbestellung korrigieren | Das ist keine Aufräumarbeit | Eigentümerschaft den Betriebsmitarbeitern zuweisen und aus dem Agent-Umfang entfernen | Die nützliche Erkenntnis lautet nicht «Agents machen Fehler». Menschen erzeugen dieselbe Fehlerkette, wenn Zugriffsgrenzen unklar sind. Agents handeln schneller, wiederholen Versuche bereitwilliger und können einer Anweisung folgen, die lokal vernünftig klingt, ohne den geschäftlichen Kontext zu bemerken, den ein Mensch erschließen würde. Schreibe bei Zeilen mit weitreichenden Folgen mögliche Fehlerpfade in die Notizen. Verwende ein einfaches Format: Auslöser, falsches Ziel oder falsche Interpretation, ausgeführte Aktion, unmittelbare Wirkung, Aufwand der Wiederherstellung. So werden Genehmigungsentscheidungen konkreter und Prüfer erhalten einen Grund, weitreichenden Zugriff abzulehnen. Ein Katalog erkennt auch gefährliche Kombinationen. Das Lesen von Vorfallsnotizen kann akzeptabel sein. Das Veröffentlichen auf einer öffentlichen Statusseite kann mit Prüfung ebenfalls akzeptabel sein. Wenn ein Agent beides ohne Inhaltsgrenze darf, können interne Vorfalldetails offengelegt werden. Prüfe Kombinationen, bei denen eine Aktion sensible Eingaben liefert und eine andere Daten aus der Organisation heraus sendet. ## Den Katalog durchsetzbar machen und mit der Realität abgleichen Ein Katalog, der nur in einer Tabelle lebt, wird zu einer Wunschliste von Berechtigungen. Verknüpfe jede genehmigte Zeile mit einer technischen Grenze: eigenen Zugangsdaten, einem eingeschränkten API-Bereich, einer Zielliste, einem begrenzten SSH-Befehl oder einer Genehmigungskonfiguration. Verwende Aktions-IDs in Konfiguration und Logs. So entsteht ein einfacher Test: Jede beobachtete externe Aktion sollte einer Katalog-ID entsprechen, und jede aktive Katalog-ID sollte auf eine aktuelle Durchsetzungsstelle verweisen. Untersuche beide Abweichungen. Eine beobachtete Aktion ohne Zeile ist Schattenzugriff. Eine Zeile ohne Durchsetzung kann ein veralteter Plan oder ein unkontrollierter Pfad sein. Bei HTTP-Aufrufen prüfst du Methode, Host, Pfadmuster, Zielumgebung und Berechtigungsbereich der Zugangsdaten. Bei SSH prüfst du Konto, Hostgruppe, Befehlsbeschränkungen und die Möglichkeit, beliebige Argumente zu übergeben. «SSH-Zugriff ist genehmigt» ist keine durchsetzbare Aussage. Dieser Katalogeintrag behauptet beispielsweise, dass der Agent nur einen Bereitstellungsstatus abrufen kann: ```text Action ID: deploy.status.read Host: deploy.internal.example Command: deployment-status --service Identity: agent-deploy-read Approval: per-session ``` Diese Implementierung widerlegt die Behauptung: ```sh command="/usr/local/bin/deployment-status $SSH_ORIGINAL_COMMAND" ssh-ed25519 AAAA... agent ``` Der Wrapper übergibt einen beliebigen ursprünglichen Befehl als Argument. Wenn `deployment-status` eine Shell aufruft oder eine ungeprüfte Option akzeptiert, ist die Kataloggrenze nur eine Behauptung. Ein sichereres Design ordnet einen genehmigten Dienstnamen einem festen Befehl zu und weist jede andere Eingabe zurück. Teste den Ablehnungspfad bewusst. ```sh case "$1" in checkout) exec /usr/local/bin/deployment-status --service checkout ;; search) exec /usr/local/bin/deployment-status --service search ;; *) echo "service not permitted" >&2; exit 1 ;; esac ``` Kopiere diesen Ausschnitt nicht unbesehen in eine authorized-keys-Konfiguration. Er zeigt die benötigte Eigenschaft: Der Agent wählt aus definierten Aktionen und nicht aus einer beliebigen Befehlssprache. Deine Umgebung braucht weiterhin Eingabevalidierung, Kontobeschränkungen und Tests durch jemanden, der das Verhalten des Befehls versteht. Halte für jeden Aktionsnachweis einen Test fest, der beide Seiten der Grenze beweist. Ein positiver Test zeigt, dass der genehmigte Aufruf funktioniert. Ein negativer Test zeigt, dass ein nahegelegener verbotener Aufruf scheitert. Teams bewahren oft nur den positiven Test auf. Deshalb bleiben weitreichende Zugangsdaten unbemerkt bestehen. Sallyport erfasst Agent-Sitzungen und einzelne Aufrufe in einem einzigen verschlüsselten, hashverketteten Audit-Log. Mit `sp audit verify` lässt sich diese Kette offline über dem Chiffretext prüfen, ohne Zugriff auf den Tresorschlüssel. Dieser Nachweis hilft beim Abgleich des Katalogs mit dem tatsächlichen Verhalten, ersetzt aber nicht die Entscheidung, eine unnötige Aktion zu entfernen. ## Zugriff prüfen, wenn sich die Arbeit ändert Prüfe den Katalog, wenn du ein Tool hinzufügst, einen Agent-Workflow veränderst, Zugangsdaten ausstellst oder rotierst, ein Systemeigentümer wechselt oder ein Beinahevorfall entdeckt wird. Diese Ereignisse verändern den tatsächlichen Zugriff. Wer auf eine Prüfung nach Kalender wartet, lässt alte Annahmen bestehen, während Integrationen weiter wachsen. Setze trotzdem für jede Zeile ein Prüfdatum. Aktionen mit weitreichenden Folgen verdienen kürzere Abstände als harmlose interne Lesevorgänge. Bei einer Prüfung sollte nicht gefragt werden, ob die Tabelle noch existiert. Die Fragen sollten lauten, ob der Agent diese genaue Aktion weiterhin braucht, ob die Identität noch eng begrenzt ist, ob der Eigentümer noch stimmt und ob die beobachtete Nutzung ihre Beibehaltung rechtfertigt. Entferne ungenutzte Aktionen konsequent. Teams sträuben sich dagegen, weil sie befürchten, ein Agent könne die Berechtigung später benötigen. Falls das geschieht, füge sie über dieselbe Eigentümer- und Genehmigungsentscheidung wieder hinzu. Eine bekannte Aktion erneut zu gewähren, kostet weniger Aufwand als eine Aktion aufzuräumen, die nie hätte bestehen bleiben dürfen. Der erste brauchbare Katalog muss nicht vollständig sein. Wähle einen Agent, liste jede externe Aktion auf, die er heute ausführen kann, und zwinge einen Eigentümer, über jede Zeile zu entscheiden. Du wirst Zugriff finden, der existiert, weil ihn bisher niemand benennen musste. Genau diesen Zugriff solltest du entfernen, bevor er im ungünstigsten Moment verwendet wird.