GitHub Agenten-Workflows: Wie ein Wort Datendiebstahl möglich macht

Ein öffentliches GitHub-Issue, eine versteckte Anweisung und eine einzige geänderte Textzeile reichten aus, um einen KI-Agenten dazu zu bringen, sensible Daten aus privaten Repositories auszulesen. Die Methode erfordert keine gestohlenen Anmeldedaten – und wirft damit ein Schlaglicht auf ein längst bekanntes, aber immer wieder unterschätztes Sicherheitsrisiko in agentengesteuerten Workflows.

Der Angriff: Ein Wort als Türöffner für Datendiebstahl

Das Team hinter der Demonstration zeigte, wie ein KI-Agent in GitHub – ein sogenanntes agentisches Workflow-System – durch eine gezielte Manipulation der Eingabe dazu gebracht wurde, auf private Repos zuzugreifen. Der Angriff nutzte eine einfache Technik: Ein öffentliches Issue enthielt eine scheinbar harmlose Anweisung, die durch eine minimale Änderung (z. B. ein einzelnes Wort) als direkte Steueranweisung für den Agenten interpretiert wurde. Da der Agent über weitreichende Berechtigungen verfügte – etwa Lesezugriff auf mehrere Repos – konnte er die manipulierte Eingabe als legitime Anweisung ausführen und sensible Daten preisgeben.

Dieser Angriff ist kein neues Phänomen, sondern eine moderne Variante eines klassischen Problems: dem Confused-Deputy-Problem. Seit Jahrzehnten gibt es Systeme, die im Namen von Benutzern mit erweiterten Berechtigungen handeln. Doch die Auswirkungen sind heute größer denn je. Agentische Workflows in GitHub, die mit großen Sprachmodellen (LLMs) betrieben werden, erben oft pauschale Lesezugriffe auf Repos – sei es zur Bearbeitung von Issues, zur Prüfung von Pull Requests oder anderen Aufgaben. Die Methode GitLost macht deutlich, was passiert, wenn ein Agent nicht zwischen Benutzeranweisungen und potenziell bösartigem Inhalt unterscheiden kann: Er wird zum effizienten Werkzeug für Datenexfiltration.

Warum die Diskussion um "sophistizierte Angriffe" irreführend ist

In der öffentlichen Debatte wird dieser Vorfall oft als hochkomplexer Angriff dargestellt. Doch die Realität ist weit weniger glamourös: Ein einziger Wortwechsel in einer Anweisung reichte aus, um die Sicherheitsfilter zu umgehen. Das ist weniger ein Beweis für die Kreativität der Angreifer als vielmehr ein Indiz für die Schwächen der implementierten Schutzmechanismen.

Viele Anbieter neigen dazu, solche Vorfälle als „bahnbrechende Forschungsergebnisse“ zu präsentieren – ein Narrativ, das zwar medienwirksam ist, aber die eigentliche Problematik verschleiert. Die eigentliche Schwachstelle liegt nicht in der Komplexität des Angriffs, sondern in der Architektur der Berechtigungsmodelle. Solange Agenten pauschale, unbegrenzte Zugriffe auf Repos erhalten, wird es immer Angriffsvektoren geben, die diese Schwachstellen ausnutzen – unabhängig davon, wie ausgeklügelt die Eingabefilter sind.

Ein weiterer kritischer Punkt: Die Diskussion um „Prompt-Injection“-Angriffe ist nicht neu. Bereits seit zwei Jahren zeigen Sicherheitsforscher, wie ungeschützte KI-Systeme durch manipulierte Eingaben getäuscht werden können – sei es bei Chatbots, Browser-Agenten oder E-Mail-Assistenten. Der hier vorgestellte Angriff ist lediglich eine spezifische Anwendung dieses Prinzips im Kontext von GitHubs agentischen Workflows. Dass dies nun als „neue Bedrohung“ dargestellt wird, lenkt von der eigentlichen Frage ab: Warum werden solche Systeme überhaupt mit so weitreichenden Berechtigungen ausgestattet?

Die eigentliche Schwachstelle: Berechtigungsmodelle ohne Sicherheitsdenken

Die meisten agentischen Workflows in GitHub sind nach dem Prinzip „einmal Berechtigung erteilen, dann nie wieder überprüfen“ aufgebaut. Das mag für menschliche Nutzer praktikabel sein, ist aber für autonome Agenten ein schwerwiegendes Sicherheitsrisiko. Ein Agent, der im Hintergrund läuft und sowohl auf öffentliche Issues als auch auf private Repos zugreifen kann, ist ein gefundenes Fressen für Angreifer – selbst wenn die Eingabefilter technisch einwandfrei funktionieren.

Für Entwickler und Sicherheitsverantwortliche bedeutet das: Agentische Workflows müssen nach dem Prinzip der geringsten Rechte gestaltet werden.

• Jeder Agent sollte nur die Berechtigungen erhalten, die für seine spezifische Aufgabe zwingend erforderlich sind.
• Berechtigungen sollten nicht dauerhaft, sondern nur für den Zeitraum der Ausführung gelten.
• Jeder Inhalt, den ein Agent verarbeitet – sei es ein Issue, eine Pull-Request-Beschreibung oder eine Commit-Nachricht – muss als potenziell unsicher behandelt werden, bis das Gegenteil bewiesen ist.

Die Realität sieht jedoch oft anders aus. Viele Teams aktivieren agentische Workflows mit pauschalen Berechtigungen, weil es „bequemer“ ist. Doch Bequemlichkeit sollte nie über Sicherheit gestellt werden – besonders nicht in Systemen, die mit sensiblen Daten umgehen.

Wer trägt die Verantwortung? Eine unbequeme Frage

Wenn ein agentischer Workflow durch eine manipulierte Eingabe sensible Daten preisgibt, wer ist dann verantwortlich? Die Plattform, die die Berechtigungen vergeben hat? Das Team, das den Workflow aktiviert hat? Oder der Anbieter des Sprachmodells, dessen Filter versagt haben?

Aktuell gibt es keine klare Antwort. Viele Plattformen behandeln solche Vorfälle als „gepatchte Sicherheitslücken“ und nicht als systemische Designfehler. Sicherheitsforscher erhalten zwar Aufmerksamkeit für ihre „bahnbrechenden Entdeckungen“, während die eigentlichen Ursachen – wie etwa ein fehlendes Berechtigungskonzept für autonome Agenten – weiterhin ignoriert werden.

Doch die Zeit der Ignoranz könnte bald vorbei sein. Immer mehr Unternehmen setzen agentische Workflows ein, ohne die damit verbundenen Risiken vollständig zu verstehen. Die Frage ist nicht mehr, ob solche Angriffe passieren, sondern wann sie in größerem Umfang auftreten – und wer dann die Konsequenzen tragen muss.

Fazit: Ein Weckruf für eine neue Sicherheitskultur

Agentische Workflows sind keine Zukunftsmusik mehr – sie sind bereits Realität in vielen Entwicklungsumgebungen. Doch solange Berechtigungsmodelle nach dem Prinzip „Vertrauen statt Kontrolle“ funktionieren, werden solche Angriffe weiterhin möglich sein. Die Lösung liegt nicht in noch ausgefeilteren Eingabefiltern, sondern in einem grundlegenden Umdenken:

• Berechtigungen müssen granular und temporär sein.
• Jeder Inhalt muss als potenziell unsicher gelten.
• Sicherheit darf nicht der Bequemlichkeit geopfert werden.

Die nächste große Herausforderung wird nicht sein, neue Angriffe zu entdecken – sondern endlich die Architektur zu schaffen, die solche Angriffe von vornherein verhindert.