GitLost bedeutet nicht, dass jedes private GitHub-Repository über ein öffentliches Issue gestohlen werden kann. Der Fall zeigt eine gefährliche Kombination für KI-Agenten: private Daten, nicht vertrauenswürdige Eingaben und ein öffentlicher Ausgabekanal im selben Workflow.

KI-Agent mit Vertrauensgrenze zwischen öffentlichen Issues und privaten Repositories

Noma Labs veröffentlichte GitLost am 6. Juli. Ziel war GitHub Agentic Workflows, eine Preview-Funktion, mit der Teams Repository-Automation in Markdown beschreiben und einen Agenten in GitHub Actions ausführen lassen. GitHub verweist auf standardmäßig read-only Tokens, Sandboxing, Safe Outputs und einen Threat-Detection-Schritt vor der Veröffentlichung.

Im Proof of Concept von Noma konnte ein öffentliches Issue den Agenten dazu bringen, Inhalte aus einem privaten Repository zu lesen und in einem öffentlichen Kommentar zu posten. Laut Noma und The Hacker News brauchte der Angreifer keine gestohlenen Zugangsdaten und keinen Zugriff auf das private Repository. Kritisch war die Architektur: Der Agent las öffentlichen Input, hatte breiten Lesezugriff auf private Repositories und konnte öffentlich antworten.

Was passiert ist

Agentic Workflows übersetzen natürlichsprachliche Markdown-Anweisungen über gh-aw in GitHub Actions. Der Agent kann Issues triagieren, Pull Requests prüfen, CI-Fehler untersuchen oder Wartungsaufgaben vorbereiten.

Aus Produktsicht ist das nützlich. Aus Security-Sicht ist es ein Service Account mit Sprachinterface.

Der von Noma getestete Workflow startete, wenn ein Issue zugewiesen wurde. Er las Titel und Body und antwortete per Kommentar. Zusätzlich hatte er Lesezugriff auf andere Repositories der Organisation. Das Issue sah wie eine normale geschäftliche Anfrage aus. Nach dem Start holte der Agent Inhalte aus einem öffentlichen und einem privaten Repository und schrieb sie in einen öffentlichen Kommentar.

Die genaue Formulierung des Tests sollte nicht als Anleitung wiederholt werden. Die wichtige Lehre ist: Ein Filter ist keine Sicherheitsgrenze. Wenn der Schutz davon abhängt, dass ein Modell eine verdächtige Anweisung erkennt, wird er irgendwann scheitern.

Begrenzter Umfang, echtes Risiko

GitLost braucht mehrere Bedingungen: einen aktivierten agentischen Workflow, öffentlichen oder vom Angreifer kontrollierten Input, ein Token mit Zugriff auf private Repositories und einen nach außen sichtbaren Output. Es ist keine universelle GitHub-Lücke.

Trotzdem ähneln viele Unternehmens-Workflows genau diesem Muster. Ein Agent liest Tickets, Pull Requests, Sentry Events, Support-Nachrichten oder Kommentare. Er sammelt internen Kontext. Dann veröffentlicht er eine Antwort. Der Nutzen entsteht durch das Verbinden von Vertrauenszonen. Das Risiko ebenfalls.

Read-only klingt harmloser, als es ist. Ein read-only Token kann nicht pushen, aber sensible Informationen lesen. Wenn derselbe Agent öffentlich schreiben kann, reicht Lesen für eine Datenabfluss-Kette.

Die lethal trifecta passt

Simon Willisons Modell beschreibt die Mischung aus privaten Daten, nicht vertrauenswürdigem Inhalt und externer Kommunikation. GitLost passt genau dazu: Repository-Inhalt als private Daten, öffentliches Issue als untrusted content, öffentlicher Kommentar als external communication.

Entfernt man eine Komponente, sinkt das Risiko. Ein öffentliches Issue ohne Zugriff auf private Daten ist weniger gefährlich. Private Analyse ohne öffentlichen Output ist schwerer auszunutzen. Ein öffentlicher Kommentarbot ohne Zugriff auf private Repositories hat weniger preiszugeben.

Was Teams ändern sollten

Stellen Sie vor dem Aktivieren eines Agenten drei Fragen: Was kann er lesen? Wer kann in seinen Kontext schreiben? Wohin kann er Ergebnisse senden?

Wenn die Antworten private Repositories, jeder öffentliche Issue-Autor und öffentliche Kommentare lauten, muss der Workflow gestoppt werden. Das ist keine harmlose Automatisierung, sondern ein möglicher Exfiltrationspfad.

Nutzen Sie Tokens pro Repository oder Zweck statt breiten Organisationszugriff. Trennen Sie öffentliche und private Agenten. Der Agent, der auf öffentliche Issues antwortet, sollte nicht derselbe Akteur sein, der sensible interne Repositories liest.

Private Analyse sollte in privaten Kanälen bleiben. Eine Veröffentlichung nach außen braucht Review, Freigabe und brauchbare Logs: auslösendes Issue, gelesene Repositories, verwendetes Token, vorgeschlagener Output, Genehmigung.

Was Anbieter liefern müssen

Agentenplattformen brauchen sichtbare Vertrauenslabels. Inhalte aus öffentlichen Issues, externen PRs, Logs, Webseiten und MCP-Tools sollten ihre Herkunft behalten. Policies müssen sagen können: Dieser Text darf die Analyse informieren, aber keinen privaten Lesezugriff oder öffentlichen Schreibvorgang autorisieren.

Read-only reicht als Beschreibung nicht aus, wenn der Agent private Daten lesen und öffentlich sprechen kann. Autonomous reicht nicht aus, wenn Admins die Tools, Repositories, Outputs und Netzwerkpfade nicht sehen.

GitLost ist kein Grund, KI-Automation zu verwerfen. Es ist ein Grund, Agenten nicht wie Chatfenster zu behandeln. Ein Agent im Developer Workflow ist ein berechtigter Akteur. Die praktische Regel: Kombinieren Sie öffentlichen Input, private Daten und öffentlichen Output nicht in einem unbeaufsichtigten Agenten.