# Blockierte KI-Agent-Aufrufe untersuchen, ohne schwache Kontrollen zu schaffen Blockierte Aufrufe von KI-Agenten sind kein Hindernis, das man einfach beseitigen sollte. Sie zeigen, an welcher Stelle die Anweisungen des Agenten, die Tool-Schnittstelle, die Zugriffskonfiguration oder sein Verhalten nicht mehr zur Realität passen. Wenn du jede Verweigerung als Wunsch nach mehr Berechtigungen behandelst, gibst du einem Agenten irgendwann genau in dem Moment weitreichende Befugnisse, in dem es den wenigsten Grund gibt, seinem nächsten Schritt zu vertrauen. Ich habe erlebt, wie Teams eine sinnvolle Verweigerung in eine dauerhafte Ausnahme verwandelten, weil der Termin drängte und die Belege über mehrere Stellen verteilt waren. Die erste Freigabe wirkt harmlos. Die zweite wird zur Routine. Bald kann ein Agent mit einem Anmeldedatum, das er nie hätte sehen müssen, über ein Tool, das niemand sauber erklären kann, die Produktionsumgebung erreichen. Das ist kein Effizienzgewinn. Es ist eine Untersuchung, die du nicht durchgeführt hast. Wer blockierte Aufrufe von KI-Agenten untersucht, muss eine begrenzte Reihe von Fragen in der richtigen Reihenfolge beantworten: Was genau hat der Prozess angefordert? Welche Kontrolle hat die Anfrage abgelehnt? Hat die Aufgabe diese Anfrage gerechtfertigt? Und welche kleinste Reparatur ermöglicht die legitime Arbeit? Die Reihenfolge ist entscheidend. Wenn du zuerst den Zugriff erweiterst, wird jeder spätere Datensatz schwerer zu verstehen. ## Ein Verweigerungsprotokoll ist ein Beleg, keine Fehlermeldung Eine blockierte Anfrage hält eine Abweichung zwischen der versuchten Aktion des Agenten und der Autorität fest, die du ihm geben wolltest. Bewahre diese Abweichung lange genug auf, um sie zu verstehen. Eine Verweigerung kann auf fehlende Anmeldedaten, einen nicht freigegebenen Prozess, ein zu vage definiertes Tool, eine falsche Umgebung oder eine Anfrage hinweisen, die nie hätte gestellt werden dürfen. Der Begriff „blockiert“ vermischt zwei Ereignisse, mit denen Teams oft falsch umgehen. Eine Aktion kann scheitern, weil sie am Gateway keine Berechtigung hat. Sie kann aber auch einen externen Dienst erreichen und dort scheitern, weil dieser Dienst sie ablehnt. Das erste Ereignis zeigt, dass deine Kontrolle die Anfrage gestoppt hat. Das zweite zeigt, dass du die Anfrage nach außen gelassen hast und erst das Ziel sie abgewiesen hat. Untersuche das erste Ereignis, bevor es zum zweiten wird. Ein brauchbarer Datensatz beantwortet Fragen, die ein Konsolenprotokoll meist nicht beantworten kann: - Welcher Agent-Prozess hat die Anfrage gestellt, und wie wurde dieser Prozess identifiziert? - Welche genaue HTTP-Operation oder welchen SSH-Befehl hat er angefordert? - Welches Ziel und welchen Verweis auf Anmeldedaten hat er ausgewählt? - Welche Sperre oder Freigabebedingung hat die Anfrage abgelehnt? - Welche Aufgabenanweisung oder welcher Repository-Kontext hat zu dieser Anfrage geführt? Akzeptiere „Der Agent brauchte Zugriff auf die Bereitstellung“ nicht als Antwort auf eine dieser Fragen. Zugriff auf die Bereitstellung ist eine Kategorie. Eine Untersuchung braucht eine Operation, ein Ziel und ein erwartetes Ergebnis. „Den aktuellen Release-Status über die Staging-API lesen“ ist eine Aussage, die du prüfen kannst. „Zugriff auf die Bereitstellung“ lädt dazu ein, alles freizugeben, was als Nächstes auftaucht. Die NIST Special Publication 800-92, Guide to Computer Security Log Management, weist auf einen unspektakulären, aber wichtigen Punkt hin: Protokolle unterstützen Incident Response und die Behebung von Betriebsproblemen. Was Teams oft überspringen, ist die Aufbewahrung. Ein Protokoll muss genug Kontext enthalten, um einen gewöhnlichen Fehler von einer ungewöhnlichen Anfrage zu unterscheiden. Ein Freigabefenster allein ist kein Datensatz. Eine kopierte Terminalzeile ist kein Datensatz. Erfasse den gesamten Lauf und den einzelnen Aufruf, bevor jemand eine Einstellung ändert. Verweigerungen haben einen weiteren Vorteil: Sie zwingen den zuständigen Menschen dazu, die beabsichtigte Autorität zu benennen. Diese Aussage wird zum Prüfmaßstab für den nächsten Agent-Lauf. Wenn niemand sie ohne weit gefasste Begriffe wie „Admin“, „Produktion“ oder „Repository-Zugriff“ formulieren kann, ist die Aufgabe noch nicht für eine autonome Ausführung geeignet. ## Die angeforderte Aktion benennen, bevor du den Zugriff änderst Du kannst einen blockierten Aufruf erst untersuchen, wenn du ihn auf einen Satz reduzieren kannst, den ein anderer Entwickler reproduzieren könnte. Der Satz sollte Akteur, Aktion, Ziel, Authentifizierungsverweis und erwartetes Ergebnis nennen. Fehlt eines dieser Elemente, solltest du die Anfrage nicht als einfachen Berechtigungswunsch behandeln. Erfasse bei HTTP Methode, Pfad, Hostname und die Information, ob der Aufruf Daten liest oder den Zustand verändert. `GET /releases/current` und `POST /releases` können denselben Dienst und dieselben Anmeldedaten verwenden, erzeugen aber völlig unterschiedliche Risiken. Ein Bearer-Token, das einen Status-Endpunkt lesen darf, kann möglicherweise auch eine Bereitstellung auslösen. Leite aus einer freundlich klingenden Bezeichnung für Anmeldedaten keinen sicheren Umfang ab. Bei SSH solltest du Host-Alias, angeforderten Befehl, Arbeitsverzeichnis, sofern das Tool es offenlegt, und erwartetes Ergebnis protokollieren. „Tests auf dem Build-Host ausführen“ ist weiterhin zu ungenau. `git status --short` im ausgecheckten Repository auszuführen, gibt einem Prüfer etwas Konkretes, das er mit der beschriebenen Aufgabe vergleichen kann. Befehle mit Shell-Umleitungen, Befehlsersetzung, Paketinstallation, Löschung oder Netzwerkübertragung verdienen besondere Aufmerksamkeit, weil ihr sichtbares Verb den folgenreichen Teil verbergen kann. Verwende diese kurze Untersuchungsnotiz, solange der Lauf noch verfügbar ist: ```text Run identity: Task instruction: Requested operation: Target host or API path: Credential reference: Control that denied it: Expected result: Why this request belongs to the task: Smallest safe repair: ``` Die Notiz verhindert den typischen Fehler bei der Übergabe: Eine Person sieht den Prompt, eine andere die Freigabekarte und eine dritte die Fehlermeldung des Ziels. Jeder hält ein plausibles Fragment in der Hand, sodass am Ende jemand aus Vertrauen freigibt. Sallyports Sitzungsautorisierung zeigt zuerst die Codesignatur-Berechtigung des Prozesses. Das ist genau das Detail, das du vor der Freigabe eines neuen Laufs prüfen solltest. Die Prozessidentität beweist nicht, dass die Anfrage sinnvoll ist. Sie verhindert aber, dass du jeden lokalen Prozess als austauschbar behandelst. Ein Terminal, das von der erwarteten signierten Anwendung gestartet wurde, und eine unbekannte ausführbare Datei, die dieselbe Aktion anfordert, sind zwei verschiedene Fälle. Verwende die frei formulierte Aufgabenbeschreibung nicht als Beweis. Agenten können sie falsch verstehen, geerbte Anweisungen können sich widersprechen, und ein bösartiges Repository kann Anweisungen einschleusen, die wie gewöhnliche Projektvorgaben aussehen. Vergleiche die angeforderte Aktion mit einer von dir kontrollierten Aufgabenquelle, etwa einem geprüften Ticket oder einer ausdrücklichen Anweisung eines Operators. Repository-Text ist Eingabe, keine Autorität. ## Die Quelle der Verweigerung verändert die Untersuchung Verschiedene Kontrollen verweigern Anfragen aus unterschiedlichen Gründen, und jeder Grund verlangt eine andere Reparatur. Wenn du alle Verweigerungen in einen einzigen Bereich „Zugriff verweigert“ einordnest, entstehen schlechte Lösungen, weil dadurch verborgen bleibt, wo die Entscheidung gefallen ist. Eine Verweigerung durch einen gesperrten Tresor bedeutet, dass keine Aktion fortgesetzt werden sollte. Verschiebe die Anmeldedaten nicht in eine Umgebungsvariable, kopiere sie nicht in einen Prompt und erstelle keinen alternativen Codepfad. Damit würdest du genau den Schutz umgehen, der das Problem erkannt hat. Prüfe, ob die Person am Mac den Zugriff für diese Aufgabe tatsächlich entsperren möchte, und setze den Lauf erst fort, nachdem sie den Kontext geprüft hat. Eine Verweigerung für eine neue Sitzung bedeutet, dass ein Agent-Prozess für seinen aktuellen Lauf noch keine Berechtigung erhalten hat. Prüfe Prozessidentität und Aufgabengrenze. Wenn beides zu der von dir gestarteten Arbeit passt, ist eine Freigabe pro Sitzung sinnvoll, weil sie eine begrenzte Lebensdauer hat: Der Lauf endet, und mit ihm endet diese Berechtigung. Wenn dich die Prozessidentität überrascht, solltest du nicht freigeben, nur weil der angeforderte Aufruf harmlos aussieht. Ein unbekannter Prozess kann mit einem harmlosen ersten Aufruf Vertrauen aufbauen. Eine Freigabe pro Aufruf bedeutet, dass der Besitzer der Anmeldedaten jede Nutzung bewusst einer menschlichen Entscheidung unterstellt hat. Entferne diese Bedingung nicht, nur weil der Agent mehrere ähnliche Anfragen stellt. Frage dich, ob die Aufgabe schlecht zugeschnitten wurde. Eine Sammelaktion braucht möglicherweise einen eigenen, bewusst gestalteten Ablauf und keine Reihe von Bestätigungen, bei denen ein Prüfer irgendwann aufhört zu lesen. Fehlende oder nicht passende Anmeldedaten sind ein anderer Fall. Der Agent kann eine benannte Operation anfordern, die zu seiner Aufgabe gehört, aber im Tresor gibt es keine Anmeldedaten für dieses Ziel, oder die Anmeldedaten haben beim externen Dienst nicht den benötigten Berechtigungsumfang. Prüfe zuerst, ob das Ziel beabsichtigt ist. Ergänze oder korrigiere dann die enge Zuordnung der Anmeldedaten. Übergib das Geheimnis niemals an den Agenten, damit er das Problem diagnostiziert. Das Gateway kann die Authentifizierung übernehmen, während der Agent nur das Ergebnis sieht. Ein Fehler bei der externen Autorisierung erfordert wiederum eine andere Reaktion. Der Aufruf kann korrekt über das Gateway nach außen gelangt sein, aber der Dienst weist ihn mit einer Antwort wie `401`, `403` oder einer domänenspezifischen Fehlermeldung zurück. Bewahre Form und Ergebnis der Anfrage auf. Erweitere den Berechtigungsumfang des Dienstkontos erst, nachdem du bestätigt hast, dass die versuchte Operation zur Aufgabe gehört. Wenn du die Rolle des Dienstes vorher änderst, wird aus einem gewöhnlichen Konfigurationsproblem ein weitreichender dauerhafter Zugriff. Die Unterscheidung hat eine praktische Konsequenz: Eine Gateway-Verweigerung schützt die von dir gesetzte Grenze, während eine externe Ablehnung zeigt, dass deine Grenze den Versuch bereits zugelassen hat. Nenne beide Ereignisse in Incident-Notizen nicht einfach „blockiert“. Verwende getrennte Bezeichnungen. Später musst du wissen, ob die Anfrage lokal gestoppt wurde oder lediglich nachgelagert scheiterte. ## Die Absicht aus der Aufgabe rekonstruieren, nicht aus der Erklärung des Agenten Ein Agent kann erklären, warum er eine Anfrage gestellt hat. Diese Erklärung ist aber ein Beleg für seine Überlegung und keine Begründung für den Zugriff. Der Besitzer der Aufgabe entscheidet, ob die Aktion dazugehört. Das klingt selbstverständlich, bis ein Agent sagt, er brauche einen weitreichenden Befehl, „um die Umgebung zu prüfen“, und der Operator es leid ist, ihn zu blockieren. Beginne mit dem gewünschten Ergebnis. Wenn die Aufgabe lautet, einen fehlschlagenden Test zu beheben, kann ein API-Aufruf zum Lesen des Build-Status passen. Ein Aufruf zum Rotieren eines Bereitstellungs-Schlüssels passt nicht, sofern sich die Aufgabe nicht ausdrücklich um Anmeldedaten dreht. Wenn die Aufgabe lautet, Dokumentation zu aktualisieren, braucht eine SSH-Anfrage zur Paketinstallation auf einem gemeinsam genutzten Host eine deutlich bessere Begründung als „Der Build braucht das“. Untersuche anschließend den kürzesten Weg zu diesem Ergebnis. Agenten wählen oft eine weitreichende Aktion, weil sie sich leicht beschreiben lässt. Ein Tool, das beliebigen Shell-Text akzeptiert, lädt den Agenten dazu ein, Erkundungsbefehle, Umgebungsprüfungen und zusammengesetzte Skripte zu verwenden, obwohl eine benannte Operation ausreichen würde. Ein Tool für beliebige API-URLs lädt dazu ein, Endpunkte außerhalb der Aufgabe zu erkunden. Ich verwende einen einfachen Test: Könntest du vor dem Lauf des Agenten eine enge Aussage über die erwartete Aktion formulieren? Wenn du sagen kannst „die aktuellen Issue-Labels lesen“, aber nicht „Labels ändern“, ist ein Schreibaufruf keine unklare Anfrage. Er liegt außerhalb des Umfangs. Lehne ihn ab und untersuche den Anweisungspfad, der ihn erzeugt hat. Hier machen Teams einen beliebten, aber schlechten Vorschlag: Gib dem Agenten weitreichenden Lesezugriff, denn Lesezugriff sei sicher. Lesezugriff kann Kundendaten, interne Topologie, Bereitstellungsdetails, Zugriffsmuster und versehentlich in einem Dienst gespeicherte Geheimnisse offenlegen. Er ist möglicherweise weniger zerstörerisch als ein Schreibzugriff, bleibt aber eine Autorität. Begrenze Leseoperationen auf den Dienst, die Ressourcenklasse und die Umgebung, die der Job tatsächlich braucht. Auch Prompt-Anweisungen sind schwache Belege, weil Repository-Inhalte einen Agenten steuern können. Ein Skript zur Installation von Abhängigkeiten könnte einen Kommentar enthalten, der den Agenten auffordert, ein lokales Verzeichnis mit Anmeldedaten zu untersuchen. Ein Einrichtungsdokument könnte einen curl-Befehl zu einem unbekannten Host verlangen. Der Agent kann diesem Text genau folgen und dennoch etwas tun, das du nicht autorisiert hast. Behandle nicht vertrauenswürdige Repository-Anweisungen als Daten, die geprüft werden müssen, sobald sie eine neue externe Aktion auslösen. Schreibe die Abweichung in einfachen Worten auf. „Die Aufgabe verlangte das Lesen des Release-Status, der Agent wollte einen Release erstellen.“ „Die Aufgabe nannte Staging, die Anfrage zielte auf Produktion.“ „Die Tool-Beschreibung deutete auf einen bekannten Host hin, die Anfrage enthielt einen neuen Hostnamen.“ Solche Aussagen helfen einem Entwickler, die Ursache zu beheben. „Von der Sicherheit abgelehnt“ hilft nicht. ## Wiederholte Verweigerungen zeigen meist einen Fehler im Tool-Vertrag Eine Tool-Schnittstelle verursacht Probleme, wenn sie Sicherheitsentscheidungen in Form offener Parameter an das Modell delegiert. Der Agent muss dann Host, Branch, Pfad, Anmeldedaten oder Shell-Befehl erraten. Jede Verweigerung sieht wie ein Zugriffsproblem aus, obwohl das eigentliche Problem darin besteht, dass das Tool die erlaubte Aktion nie definiert hat. Stell dir einen Agenten vor, der prüfen soll, ob ein Release abgeschlossen wurde. Ein lockeres HTTP-Tool könnte jede Methode, jede URL, beliebige Header und einen frei wählbaren Verweis auf Anmeldedaten zulassen. Der Agent erstellt eine Anfrage an einen Endpunkt, den er im Repository gefunden hat. Sie wird verweigert. Jemand gibt das Ziel frei, und anschließend wählt der Agent für einen Folgeaufruf einen anderen Endpunkt. Der Operator sieht eine Reihe jeweils plausibler Aufrufe und baut durch Freigabeentscheidungen langsam einen ungeprüften API-Client auf. Ein besseres Tool stellt die tatsächlich unterstützte Operation bereit: den Release-Status für eine benannte Umgebung lesen. Der Tool-Besitzer legt Ziel und HTTP-Methode fest. Der Agent liefert nur einen kleinen Parameter wie die Release-ID. Das Gateway fügt die Anmeldedaten ausschließlich für den vorgesehenen Aufruf ein. Eine Verweigerung hat nun eine klare Bedeutung: Umgebung, ID, Prozess oder Zuordnung der Anmeldedaten passten nicht zum Vertrag. Dasselbe gilt für SSH. Gib einem Coding-Agenten keine allgemeine Remote-Shell, wenn die Arbeit zwei Wartungsaktionen braucht. Stelle diese Aktionen als Skripte mit bekannten Argumenten bereit oder verwende einen Wrapper, der eine enge Befehlsform prüft. Eine restriktive Schnittstelle wirkt bei ihrer Gestaltung unbequem. Sie wirkt sinnvoll, sobald ein Agent zum ersten Mal einen zusammengesetzten Befehl auf dem falschen Host ausführen will. Achte in einer Gruppe von Verweigerungen auf diese Muster: - Der Agent erfindet wiederholt Zielnamen oder API-Pfade. - Eine Anfrage wechselt zwischen Lese- und Schreibaufrufen, ohne dass sich die Aufgabe ändert. - Für dieselbe Aufgabe werden viele nicht zusammengehörige Anmeldedaten benötigt. - Ein Prüfer muss die Wirkung einer langen Befehlszeile erraten. - Eine Tool-Beschreibung verspricht ein Ergebnis, lässt aber die folgenreichen Parameter offen. Behebe nicht jede einzelne Situation mit einer neuen Ausnahme. Ändere den Tool-Vertrag. Enge Tools erhöhen auch die Zuverlässigkeit des Agenten, weil sie Entscheidungen entfernen, mit denen Sprachmodelle schlecht umgehen. Ein Agent sollte aus unterstützten Operationen wählen, nicht seine eigene Sicherheitsgrenze aus Zeichenketten zusammensetzen. Sallyport bewahrt Geheimnisse in seinem verschlüsselten Tresor auf und führt HTTP- oder SSH-Aktionen aus, ohne die Anmeldedaten an den Agenten zu übergeben. Diese Trennung ist nur dann hilfreich, wenn die Aktionsschnittstelle spezifisch genug für eine menschliche Beurteilung ist. Die Isolierung von Anmeldedaten verhindert deren Offenlegung. Sie macht eine zu weitreichende Aktionsanfrage jedoch nicht akzeptabel. ## Einen fehlgeschlagenen Lauf vollständig verfolgen Eine Untersuchung sollte die Reihenfolge bewahren, weil der erste ungewöhnliche Aufruf oft alle späteren Anfragen erklärt. Wenn du nur die abschließend blockierte Aktion prüfst, entsteht die falsche Geschichte, der Agent sei plötzlich verdächtig geworden. Nehmen wir ein realistisches Beispiel. Ein Agent erhält die Aufgabe, nach einem erfolgreichen Staging-Build die Release-Notes eines Dienstes zu aktualisieren. Zunächst liest er Dateien im Repository. Danach fordert er einen HTTP-Aufruf an, um den Status des Staging-Builds abzurufen. Der Aufruf passt zur Aufgabe und gelingt nach der erwarteten Laufautorisierung. Als Nächstes fordert der Agent SSH-Zugriff auf einen Build-Host an, um ein erzeugtes Artefakt zu prüfen. Das kann gerechtfertigt sein, ist aber ein neuer Kanal und muss erneut mit der Aufgabe verglichen werden. Der Host meldet einen Fehler, weil das erwartete Artefakt fehlt. Der Agent liest ein Repository-Skript, das besagt, ein Operator könne Artefakte durch einen Remote-Befehl neu erstellen. Daraufhin fordert er einen Befehl an, der ein Ausgabeverzeichnis leert, Abhängigkeiten installiert und den Build startet. Die Anfrage wird pro Aufruf verweigert. Gib diesen Befehl nicht frei, nur weil der erste HTTP-Aufruf legitim war. Die ursprüngliche Aufgabe sagte nichts über einen Neubau, Änderungen an einem gemeinsam genutzten Host oder die Installation von Abhängigkeiten. Der Tool-Pfad wechselte von der Statusprüfung zu einer Remote-Änderung. Die richtige Untersuchung fragt: 1. Hat ein Mensch den Neubau autorisiert, oder hat der Agent ihn aus Repository-Text abgeleitet? 2. Ist der Build-Host für autonome Änderungen vorgesehen, oder sollte der Agent das fehlende Artefakt melden? 3. Kann eine eigene Build-Operation einen zusammengesetzten Remote-Shell-Befehl ersetzen? 4. Gehört das Ausgabeverzeichnis zu dieser Aufgabe, oder könnte das Leeren einen anderen Lauf beeinträchtigen? 5. Braucht die Aufgabe einen anderen Ablauf, weil der Staging-Build nicht erfolgreich war? Die Reparatur kann darin bestehen, anzuhalten und das fehlende Artefakt zu melden. Sie kann auch darin bestehen, eine geprüfte Build-Aktion mit isoliertem Arbeitsbereich bereitzustellen. Vielleicht muss die Pipeline korrigiert werden, die das Artefakt hätte erzeugen sollen. Eine allgemeine SSH-Berechtigung zu vergeben, ist die schlechteste Lösung, weil sie alle drei Möglichkeiten unter einer einzigen weitreichenden Berechtigung verbirgt. Diese Abfolge erklärt auch, warum Freigabeermüdung ein Designfehler ist. Wer zuerst einen normalen Aufruf und danach mehrere technische Anfragen sieht, gibt irgendwann aus Gewohnheit frei. Die Kontrolle funktioniert technisch noch, aber die Qualität der Prüfung sinkt. Platziere Entscheidungen an sinnvollen Grenzen: bei einem neuen Prozess, bei Anmeldedaten mit weitreichenden Folgen oder bei einem Wechsel des Umfangs. Zwinge niemanden, alle paar Sekunden ein neues Shell-Programm zu interpretieren. ## Der Audit-Spur erst vertrauen, nachdem du ihre Integrität geprüft hast Protokolle helfen nur, wenn du feststellen kannst, ob jemand sie nach dem Ereignis verändert hat. Die bloße Behauptung, ein Protokoll sei nur anhängbar, beantwortet diese Frage nicht, wenn der Rechner des Agenten kompromittiert wurde oder ein Operator einen unangenehmen Eintrag entfernen wollte. Ein hashverkettetes Audit-Protokoll verbindet jeden Eintrag mit dem vorherigen. Wird ein früherer verschlüsselter Eintrag geändert, verändert sich auch die folgende Kettenbeziehung. Dadurch lässt sich eine Manipulation bei der Prüfung erkennen. Das macht das ursprüngliche Ereignis nicht korrekt und verhindert auch nicht, dass ein Angreifer Schaden anrichtet, bevor das Ereignis protokolliert wird. Verwende es für das, was es leistet: für Vertrauen darin, dass die aufbewahrte Reihenfolge nicht unbemerkt verändert wurde. Führe die Prüfung durch, bevor du eine lange Untersuchung beginnst, und wiederhole sie, wenn du Datensätze für einen Incident exportierst. Sallyport kann seine verschlüsselte Audit-Kette offline mit diesem Befehl prüfen: ```text sp audit verify ``` Der Befehl benötigt für die Prüfung keinen Tresorschlüssel. Bewahre das Ergebnis zusammen mit der Untersuchungsnotiz auf, einschließlich des Zeitpunkts der Prüfung und der geprüften Datensätze. Wenn die Prüfung einen Fehler meldet, behandle die betroffene Reihenfolge nicht mehr als vollständige Darstellung. Sichere die zugrunde liegenden Dateien, beschränke den Zugriff auf den Rechner und vergleiche sie mit unabhängigen Belegen wie Protokollen des Zieldienstes, Repository-Verlauf und Aufgabensystem. Überschätze nicht, was unabhängige Protokolle leisten. Ein Zieldienst kann aufzeichnen, dass eine Anfrage eingegangen ist, weiß aber möglicherweise nicht, welcher lokale Agent-Prozess sie ausgelöst hat. Ein Versionskontrollsystem kann einen Commit zeigen, aber nicht, warum der Agent diese Änderung ausgewählt hat. Eine Korrelation funktioniert, wenn du Bezeichner und zeitliche Reihenfolge über mehrere Quellen hinweg bewahrst, nicht wenn du erst im Nachhinein Screenshots sammelst. Trenne in deinen Notizen zwei Fragen. Erstens: „Hat dieser Agent-Lauf diese Aktion angefordert?“ Zweitens: „War die angeforderte Aktion angemessen?“ Die Integrität des Audits hilft bei der ersten Frage. Aufgabenumfang und menschliche Beurteilung entscheiden über die zweite. Teams vermischen beides, weil ein intaktes Protokoll autoritativ wirkt. Ein intaktes Protokoll kann beweisen, dass eine schlechte Anfrage gestellt wurde. Es kann die Anfrage nicht in eine gute verwandeln. ## Die enge Ursache beheben und die Reparatur nachweisen Die richtige Reparatur lässt die beabsichtigte Aufgabe weiterlaufen und bewahrt gleichzeitig den Grund, aus dem die ursprüngliche Anfrage abgelehnt wurde. Jede Reparatur, die lediglich das Freigabefenster verschwinden lässt, ist verdächtig. Bei fehlendem Zugriff ergänzt du einen Verweis auf Anmeldedaten, der dem vorgesehenen Dienst zugeordnet ist, und bestätigst, dass der externe Berechtigungsumfang nur die benötigte Operation unterstützt. Führe dieselbe enge Anfrage erneut aus. Prüfe die Reparatur nicht mit einer weitreichenden Aktion „nur um sicherzugehen“. Ein Test sollte nachweisen, dass der konkrete Fehlerfall jetzt funktioniert und nicht dazugehörige Anfragen weiterhin scheitern. Bei einem unerwarteten Prozess startest du den bekannten Einstiegspunkt des Agenten erneut und vergleichst seine Identität mit der verweigerten Prozessidentität. Wenn sich der erwartete Prozess durch ein Upgrade oder einen Wrapper geändert hat, dokumentiere die Änderung und prüfe, warum die Identität abweicht. Wenn niemand sie erklären kann, überdecke sie nicht mit einer dauerhaften Freigabe. Agent-Tools starten oft untergeordnete Prozesse. Das bedeutet nicht, dass jeder dieser Prozesse die Berechtigungen des übergeordneten Prozesses erhalten sollte. Bei einem Tool-Fehler änderst du die Schnittstelle vor dem nächsten autonomen Lauf. Ersetze beliebige Ziele, wo möglich, durch ein festes Ziel. Ersetze beliebigen Befehlstext durch eine benannte Operation. Entziehe dem Agenten die Kontrolle über sensible Parameter. Prüfe anschließend beide Seiten der Grenze: - Die unterstützte Anfrage gelingt mit dem vorgesehenen Prozess und der vorgesehenen Aufgabe. - Ein anderes Ziel, ein anderer Befehl oder eine Schreiboperation wird verweigert. - Das Aktivitätsprotokoll beschreibt das Geschehen so klar, dass ein Prüfer es verstehen kann. - Das Sitzungsprotokoll ermöglicht den Widerruf des Laufs, falls sich sein Verhalten ändert. Bei einer verdächtigen Anfrage setzt du den Lauf nicht fort, während du über den Umfang diskutierst. Widerrufe die Berechtigung, sichere Sitzungs- und Aufrufprotokolle und prüfe die Anweisungsquellen, die der Anfrage vorausgingen. Eine normale Aufgabe kann unsicher werden, nachdem sie nicht vertrauenswürdige Inhalte gelesen hat. Dass der Prozess als freigegebener Lauf begonnen hat, gibt ihm keinen Freibrief für spätere Aktionen. Sallyport führt Lauf- und Aufrufprotokolle in einem schreibgeschützten, verschlüsselten und hashverketteten Audit-Protokoll zusammen und unterstützt den sofortigen Widerruf eines Laufs über das Sessions-Journal. Nutze diesen Widerruf, wenn die Abfolge der Anfragen nicht mehr schlüssig ist. Das ist eine Maßnahme zur Eingrenzung, kein Urteil über den Entwickler, der den Lauf gestartet hat. Beende die Untersuchung mit einem Satz, der den nächsten Operator anleiten könnte: „Dem Agenten fehlten die Anmeldedaten für den Staging-Status. Wir haben sie für die freigegebene Leseoperation ergänzt.“ Oder: „Der Agent versuchte nach dem Lesen von Repository-Text, einen nicht freigegebenen Remote-Neubau auszuführen. Wir haben den Lauf gestoppt und werden eine geprüfte Build-Aktion bereitstellen.“ Wenn du diesen Satz nicht schreiben kannst, hast du die Ursache noch nicht gefunden. ## Verweigerungen müssen leichter zu verstehen sein als zu umgehen Menschen umgehen Kontrollen, wenn die Untersuchung mehr Aufwand verursacht, als die Aufgabe ihnen wert erscheint. Die Antwort sind keine schwächeren Kontrollen. Sie sind Protokolle und Tool-Schnittstellen, die den legitimen Weg offensichtlich und den ungewöhnlichen Weg sichtbar machen. Halte Aufgabenanweisungen begrenzt. Nenne die Umgebung, die beabsichtigte externe Aktion und die Bedingung, bei der der Lauf endet. „Untersuche die fehlgeschlagene Staging-Bereitstellung und melde die Ursache“ lässt Raum für einen Bericht. „Bringe Produktion auf den Stand von Staging“ lädt stillschweigend zu Schreibvorgängen, Anmeldedaten und Systemänderungen ein, die niemand geprüft hat. Gib Prüfern genug Kontext, damit sie eine Entscheidung gut treffen können. Eine Sitzungsfreigabe sollte zeigen, wer den Prozess gestartet hat und zu welchem Lauf er gehört. Eine Freigabe für eine sensible Aktion sollte Operation und Ziel in Begriffen nennen, die ein Mensch versteht. Wenn der Prüfer einen Namen für Anmeldedaten entschlüsseln, einer undurchsichtigen URL folgen und eine Shell-Pipeline gedanklich ausführen muss, hast du die Sicherheitsarbeit in einen hektischen Klick verlagert. Miss wiederkehrende Verweigerungen nach ihrer Ursache, nicht nach ihrer Anzahl. Zehn blockierte Anfragen, weil ein Agent einen nicht unterstützten Endpunkt gewählt hat, zeigen ein Tool-Problem. Zehn blockierte Anfragen, weil bei jedem Lauf ein neuer Prozess auftaucht, zeigen ein Problem mit Identität oder Aufruf. Zehn blockierte Anfragen, weil eine Aufgabe immer weiter wächst, zeigen ein Planungsproblem. Die Zahl allein sagt wenig. Versuche nicht, autonome Agenten wie gewöhnliche Skripte wirken zu lassen. Skripte erhalten ihre Berechtigungen meist, weil ein Mensch ihr genaues Verhalten geschrieben und geprüft hat. Ein Agent wählt sein Verhalten während der Ausführung und kann neue Repository-Inhalte, Tool-Ausgaben und Fehler einbeziehen. Deshalb braucht ein Aktions-Gateway einen menschlichen Entscheidungsweg und ein Protokoll, das über den Moment hinaus Bestand hat. Der nächste verweigerte Aufruf sollte zu einer besseren Aufgabe oder einem besseren Tool führen, nicht zu einer weiter gefassten Ausnahme. Wenn dein Team diese Regel übernimmt, werden Verweigerungen aus dem richtigen Grund seltener: Der Agent erhält klare, begrenzte Berechtigungen, und die verbleibenden Blockierungen machen auf Verhalten aufmerksam, das weiterhin gestoppt werden sollte.