Ausufernde Agentenrechte

Was ist Ausufernde Agentenrechte?

Der mögliche Schaden eines Agenten hängt vom Umfang seiner Zugriffsrechte ab, nicht vom Wortlaut seiner Anweisungen. Berechtigungen für einmalige Aufgaben bleiben oft bestehen; eine Prüfung des ursprünglichen Zwecks statt der heutigen Reichweite übersieht das. Hier befolgt ein Triage-Agent eine zusätzliche Anweisung in einem öffentlichen Fehlerbericht und veröffentlicht einen privaten Signaturschlüssel in einem für alle lesbaren Thread. Sie prüfen die Berechtigungen des Agenten, erkennen eine nie genutzte Berechtigung als ungeprüften Zugriff und beschränken seine Rechte auf das nötige Maß.

Was Sie lernen in Ausufernde Agentenrechte

• Erkennen Sie, dass die Zugriffsrechte eines Agenten seinen möglichen Schadensradius bestimmen, nicht die Formulierung seiner Anweisungen oder die Qualität der Tool-Beschreibungen.
• Unterscheiden Sie einen Berechtigungsfehler von einem Fehler im Tool selbst: Ein unverändertes Tool, das genau die Dateien liefert, auf die das Token zugreifen darf, ist hier nicht die Ursache.
• Behandeln Sie jedes Issue, Ticket, Dokument und jede Seite, die ein Agent einliest, als nicht vertrauenswürdige Eingabe, die Anweisungen enthalten kann.
• Prüfen Sie, welche Zugriffe eine Berechtigung heute erlaubt, statt nur den bei der Vergabe genannten Zweck zu betrachten. Auch als vorübergehend bezeichnete Berechtigungen bleiben ohne Ablaufdatum oft bestehen.
• Erkennen Sie, dass eine nie genutzte Berechtigung einen ungeprüften Zugriff darstellt – keinen Beleg für Sicherheit.
• Vergleichen Sie den Trace der Agentenanfragen mit dem Auftrag, statt nur nach Fehlern zu suchen. Auch ein korrekter und erfolgreicher Aufruf kann außerhalb der Aufgabe liegen.
• Prüfen Sie eingeschränkte Berechtigungen, indem Sie die zuvor erfolgreiche Anfrage wiederholen und bestätigen, dass der Dienst den Zugriff verweigert – nicht nur der Agent.

Ausufernde Agentenrechte — Trainingsschritte

1. Der Bot antwortet öffentlich

   Sarnholt Systems veröffentlicht sein Relay-SDK als Open Source. Im öffentlichen Issue-Tracker kann jeder Fehler melden. Bob hat weder ein Konto bei Sarnholt Systems noch gestohlene Zugangsdaten oder Zugang zu internen Systemen. Er hat einen Browser und einen Fehlerbericht.

2. Der Bot zitiert den Quellcode

   Jedes offene Issue trägt ein Triage-Label und eine Antwort desselben Kontos. Offenbar liest ein System die Meldungen und antwortet darauf.

3. Wie weit der Zugriff reicht, steht hier nicht

   Die Antwort ist keine Standardbestätigung. Sie nennt eine Datei, eine Zeilennummer und den Programmzweig, der den Fehler auslöst.

4. Jeder kann ein Issue erstellen

   Vor dem Issue-Tracker gibt es weder eine Freigabewarteschlange noch eine Mitgliedschaftsprüfung. Jeder kann einen Bericht in ein Textfeld schreiben; das Triage-Konto liest dessen Inhalt.

5. Die Anweisung im Fehlerbericht

   Bob beschreibt einen echten Fehler präzise. Ein reproduzierbarer Fehlerbericht wird gelesen. Darunter fügt er einen weiteren Absatz ein, der sich an den Assistenten richtet, der das Issue als Nächstes bearbeitet.

6. Der Agent bearbeitet Issues nach Zeitplan

   Das Triage-Konto verarbeitet neue Berichte stapelweise. Bob muss nichts weiter tun. Er wartet und lädt den Thread neu.

7. Privater Quellcode im öffentlichen Thread

   Der Agent beantwortet den Fehlerbericht – und befolgt außerdem die zusätzliche Anweisung.

8. Warum der Angriff funktionierte

9. Eine Frage aus dem Developer-Relations-Team

   Alice wurde nicht benachrichtigt, und kein Alarm wurde ausgelöst. Den ersten Hinweis liefert ein Kollege, der jeden Morgen den öffentlichen Issue-Tracker liest.

10. Was Idris tatsächlich meldet

    Idris trennt sorgfältig zwischen dem, was er weiß, und dem, was noch offen ist. Lesen Sie seine Nachricht entsprechend.