Prompt Injection in Agentic Workflows GithubAI gibt auf Anfrage private Daten preis

Anbieter zum Thema

cidaas by Widas ID GmbH

FAST LTA GmbH

FTAPI Software GmbH

Mittels Prompt Injection können KI-Agenten oft dazu gebracht werden, interne Sicherheitsschranken zu umgehen und etwa eigentlich geheime und private Daten preiszugeben. Sicherheitsforscher haben dies auch bei Githubs Copilot-basiertem Assistenten demonstriert. Dazu reichte es grundsätzlich, sich etwa als ein Manager auszugeben.

Sicherheitsforscher haben unter dem Namen GitLost eine Prompt-Injection-Schwachstelle in GitHubs Agentic Workflows beschrieben. In einem Blogpost beschreibt das Unternehmen Noma Security, wie der auf Copilot basierende KI-Agent durch ein präpariertes Issue in einem öffentlichen Repository dazu gebracht werden kann, Inhalte aus einem privaten Repository derselben Organisation abzurufen und als öffentlichen Kommentar auszugeben.

GitHub Agentic Workflows verbinden GitHub Actions mit einem KI-Agenten, der auf Claude oder GitHub Copilot basieren kann. Teams können Workflows in Markdown beschreiben, die anschließend in GitHub-Actions-Workflows umgesetzt werden. Der Agent kann Issues lesen, Tools aufrufen und abhängig von seinen Berechtigungen auch auf weitere Repositories innerhalb einer Organisation zugreifen.

Untrusted Input als Steueranweisung

Die Ursache liegt in einer indirekten Prompt Injection. Dabei werden Anweisungen nicht in Code, sondern in Inhalte eingebettet, die der Agent verarbeitet. Im beschriebenen Fall stand die manipulierte Anweisung im Body eines GitHub-Issues. Der Agent trennte offenbar nicht ausreichend zwischen vertrauenswürdigen Systemanweisungen und nutzergenerierten Inhalten.

Der von Noma Labs getestete Workflow wurde bei einem issues.assigned-Event ausgelöst. Er las Titel und Body des Issues, konnte Kommentare posten und verfügte über Leserechte auf weitere Repositories der Organisation. Diese Kombination reichte aus, um den Agenten zum Abruf von README.md-Dateien aus mehreren Repositories zu veranlassen.

Für den Angriff waren laut Noma Labs weder Zugangsdaten noch Codekenntnisse erforderlich. Ein Angreifer musste lediglich ein Issue in einem öffentlichen Repository einer Organisation erstellen, die eine entsprechende Agentic-Workflow-Konfiguration nutzt. Nach der Zuweisung des Issues führte der Workflow die eingebetteten Anweisungen aus.

Im Proof of Concept verwendeten die Forschenden ein plausibel formuliertes Issue, das wie eine geschäftliche Anfrage nach einem Kundentermin wirkte, etwa mit dem folgenden Beispiel:

Der Agent rief daraufhin Inhalte aus einem öffentlichen Repository sowie aus einem privaten Repository ab und veröffentlichte sie als Kommentar im öffentlichen Issue.

Berechtigungen und Ausgabekanäle begrenzen

Besonders relevant ist der Fall für Organisationen, die öffentliche und private Repositories in derselben GitHub-Organisation betreiben und KI-Agenten mit organisationsweiten oder repositoryübergreifenden Rechten einsetzen. Je größer der Berechtigungsumfang eines Agenten ist, desto größer fällt auch der mögliche Schaden bei einer Fehlsteuerung aus.

Noma Labs berichtet außerdem, dass bestehende Guardrails in der getesteten Konstellation umgangen werden konnten. Eine Formulierung mit dem Wort „Additionally“ habe dazu geführt, dass das Modell die Anfrage anders einordnete und nicht verweigerte. Der Fall zeigt damit auch die Grenzen rein promptbasierter Schutzmechanismen.

Die Forschenden haben GitLost nach eigenen Angaben verantwortungsvoll an GitHub gemeldet und die Details mit GitHubs Kenntnis veröffentlicht. Zum veröffentlichten Material gehören auch der Workflow-Lauf und das auslösende Issue, mit denen der Ablauf nachvollzogen werden kann.

Als Gegenmaßnahmen empfehlen die Sicherheitsforscher klassische Least-Privilege-Prinzipien und zusätzliche Kontrollschichten für KI-Agenten. User-generierte Inhalte sollten nie als vertrauenswürdige Instruktionen behandelt werden. Agenten sollten nur die minimal nötigen Repository-Rechte erhalten, öffentliche Ausgaben sollten begrenzt oder geprüft werden, und Nutzereingaben sollten klar vom Instruktionskontext des Modells getrennt werden.

Dieser Artikel stammt von unserem Partnerportal Embedded Software Engineering.

(ID:50923294)