GitLost zeigt: Ihr KI-Agent muss nicht gehackt werden, um Daten preiszugeben

Ein Angreifer benötigte weder gestohlene Passwörter, noch Phishing-E-Mails oder Exploit-Chains, um vertraulichen Quellcode aus einer GitHub-Organisation zu stehlen. Ein einziger Satz, in ein öffentliches GitHub-Issue geschrieben, reichte aus. Sicherheitsforscher von Noma Labs veröffentlichten die Schwachstelle am 6. Juli 2026 und nannten sie GitLost. Sie steckt in GitHub Agentic Workflows, die GitHub Actions mit einem KI-Agenten kombinieren, der von Claude oder GitHub Copilot unterstützt wird – und es handelt sich nicht um einen klassischen Bug. Es ist eine Demonstration dessen, was passiert, wenn ein KI-Agent mehr Zugriffsrechte erhält, als für eine einzelne Aufgabe nötig ist, und dann Inhalte liest, die niemand geprüft hat.

Das ist das ganze Problem: Der Agent wurde nicht gehackt. Er hat seine Aufgabe erfüllt. Er las ein Issue, folgte den darin eingebetteten Anweisungen und nutzte das ihm zur Verfügung stehende Werkzeug – das Veröffentlichen eines öffentlichen Kommentars –, um einem Fremden den Inhalt eines privaten Repositories zu übermitteln. Dark Reading berichtete, dass GitHub daraufhin seine Dokumentation aktualisierte. Noma zufolge bestand der zugrundeliegende Designfehler zum Zeitpunkt der Veröffentlichung weiterhin.

Diese Unterscheidung ist wichtiger als die Schwachstelle selbst. Sicherheitsteams haben zwei Jahrzehnte lang Erkennungsmechanismen für unbefugten Zugriff aufgebaut – gestohlene Zugangsdaten, Privilegieneskalation, laterale Bewegungen. GitLost umging all das. Der Agent war autorisiert. Er tat genau das, wofür er gebaut wurde. Er hätte nur nie auf das zugreifen dürfen, was er letztlich erreichte.

Wichtige Erkenntnisse

1. Ein Satz, keine Zugangsdaten.

Noma Labs, die Forschungsabteilung von Noma Security, exfiltrierte vertrauliche GitHub-Repository-Daten, indem sie einen einfachen englischen Befehl in einem öffentlichen Issue versteckte – ohne Account-Kompromittierung, Malware oder Programmierkenntnisse.

2. Die Schutzmaßnahme scheiterte an einem Wort.

Allein das Voranstellen der Anweisung mit „Additionally“ reichte aus, damit der KI-Agent von GitHub eine Übernahme als legitime Folgeaufgabe statt als Bedrohung einstufte und nicht verweigerte.

3. Das Problem war der Zugriff, nicht die Intelligenz.

Der kompromittierte Agent hatte dauerhaften Lesezugriff auf alle öffentlichen und privaten Repositories der Organisation, um eine einzelne Issue-Triage durchzuführen. Das ist eine Gefährdung von geistigem Eigentum im Unternehmensmaßstab, keine punktuelle Schwachstelle.

4. Das ist jetzt der Regelfall, kein Einzelfall.

Das OWASP GenAI Security Project ordnet Prompt Injection sechs der zehn Kategorien in den Top 10 für Agentic Applications zu und bezeichnet sie als Hauptursache für Sicherheitsvorfälle mit agentischer KI im Produktivbetrieb.

5. Die meisten Unternehmen erkennen die Lücke nicht – geschweige denn, dass sie sie schließen könnten.

Forschung der Cloud Security Alliance ergab, dass weniger als ein Viertel der Unternehmen dokumentierte Richtlinien zur Governance von KI-Identitäten hat und nur 12 % sehr zuversichtlich sind, Angriffe über nicht-menschliche Identitäten stoppen zu können. Ein formales Risikomanagement, das den aktuellen Zugriffsumfang jedes KI-Agenten mit dem Minimum für seine jeweilige Aufgabe abgleicht, ist der erste Schritt, um diese Lücke zu schließen.

Was geschah: Die GitLost-Angriffskette im Detail

Der von Noma Labs angegriffene Workflow war alltäglich. Er wurde ausgelöst, wenn ein Issue zugewiesen wurde, las den Titel und Inhalt des Issues und antwortete mit dem Kommentartool des Agenten. Dafür lief der Agent mit Lesezugriff auf alle anderen Repositories der Organisation – öffentlich und privat.

Ein Angreifer ohne Zugangsdaten, ohne Repository-Zugriff und ohne Programmierkenntnisse eröffnete ein öffentliches Issue, das wie eine normale interne Anfrage aussah. Im Text versteckt war eine Anweisung in einfachem Englisch, die den Agenten aufforderte, eine Datei aus einem privaten Repository zu holen und deren Inhalt als öffentlichen Kommentar zu posten. Sobald das Issue zugewiesen wurde, las der Agent den Text, behandelte die eingebettete Anweisung als legitimen Teil seiner Aufgabe, holte die private Datei und veröffentlichte sie öffentlich. Nomas Proof-of-Concept exfiltrierte so innerhalb weniger Minuten vertrauliche Repository-Daten.

Keine Malware. Kein Exploit. Keine Account-Übernahme. Nur Sprache, eingebettet in Inhalte, die der Agent im Rahmen seiner normalen Aufgabe lesen sollte.

Genau das sollten CISOs bedenken. Es war kein Versagen von Access Controls im üblichen Sinne. Der Agent hatte die Zugriffsrechte, die ihm zugewiesen waren. Das Versagen lag darin, was „zugewiesen“ bedeuten durfte. Jede private Repository-Datei, die ein Agent ohne eine Autorisierungsprüfung pro Anfrage erreichen kann, ist potenzielles Exfiltrationsziel – eine Datenklassifizierung der Repository-Inhalte würde zumindest sichtbar machen, welche Assets im Falle eines Leaks das höchste regulatorische oder wettbewerbsrelevante Risiko bergen.

Die Schutzmaßnahme scheiterte an einem Wort

GitHub hatte explizite Schutzmaßnahmen, um genau das zu verhindern. Nomas Forscher testeten den Workflow wie ein Angreifer, variierten die Formulierung, bis etwas funktionierte. Was funktionierte, war fast schon banal: Die Anweisung mit „Additionally“ einzuleiten.

Lesen Sie das noch einmal. Ein einziges Wort, das die Übernahme als Routineaufgabe umdeutete, reichte aus, damit das Modell gehorchte statt verweigerte.

Genau das sollte alle beunruhigen, die ihre KI-Sicherheitsstrategie auf Prompt-Filterung aufbauen. Eine Verteidigung, die durch eine einzige Konjunktion ausgehebelt werden kann, ist keine Verteidigung. Sie ist ein Bremshügel – und Bremshügel stoppen keine Angreifer, die beliebig oft, unbeobachtet und kostenlos iterieren können, bis etwas durchkommt.

Prompt Injection ist kein theoretisches Risiko mehr

GitLost ist kein Ausreißer. Es ist das Muster. Das OWASP GenAI Security Project (State of Agentic AI Security and Governance, Version 2.01) ordnet Prompt Injection sechs der zehn Kategorien in den Top 10 für Agentic Applications zu – und laut Help Net Security identifiziert der Bericht Prompt Injection als Hauptursache für agentische KI-Sicherheitsvorfälle im Produktivbetrieb.

Die Ursache liegt in der Architektur, nicht in Trainingslücken, die bessere Modelle irgendwann schließen könnten. Große Sprachmodelle verarbeiten den Systemprompt, die Nutzeranfrage und jeden aus externen Quellen geholten Text als einen einzigen Token-Stream. Es gibt keinen verlässlichen Mechanismus, um einige dieser Tokens als vertrauenswürdige Befehle und andere als unzuverlässige Daten zu markieren. Ein feindlicher Satz, versteckt in einem GitHub-Issue, einer Kalendereinladung oder einer Kunden-E-Mail, hat für das Modell exakt die gleiche Autorität wie eine Anweisung des tatsächlichen Betreibers.

Genau diese architektonische Tatsache ist der Grund, warum „einfach einen besseren Systemprompt schreiben“ als Strategie immer wieder scheitert – auch bei GitLost.

Die Belege enden nicht bei GitLost. Forscher veröffentlichten CVE-2025-6514, eine Remote-Code-Execution-Schwachstelle mit einem CVSS-Score von 9,6, in einem weit verbreiteten Model-Context-Protocol-Paket, nachdem dieses fünfzehn saubere Releases ausgeliefert hatte, bevor stillschweigend eine Zeile Exfiltrationscode hinzugefügt wurde – laut OWASP-zitierter Erkenntnisse, berichtet von Help Net Security. Separat zeigte CVE-2026-22708 gegen den Cursor-Coding-Agenten, dass ein Angreifer, der die Ausführungsumgebung eines Agenten vergiftet, dessen erlaubte Befehle als Transportweg für beliebige Payloads missbrauchen kann – die Allowlist erleichterte den Angriff sogar, weil sie genau die Befehle automatisch genehmigte, die der Angreifer benötigte. CVE-2025-59532 gegen OpenAIs Codex CLI zeigte, dass ein Agent seine eigene Sandbox-Grenze durch seine eigene Ausgabe neu definieren konnte.

Drei verschiedene Anbieter, drei verschiedene Mechanismen, eine gemeinsame Ursache: Ein Agent vertraute Inhalten oder Befehlen, die er als feindlich hätte behandeln müssen, und niemand hatte seinen Zugriff eng genug gefasst, um die Folgen einzudämmen. Ein Datenschutzverstoß über einen dieser Vektoren löst die gleichen regulatorischen Meldepflichten aus wie ein Credential-Leak – der Exfiltrationskanal ist KI, aber die Compliance-Uhr läuft ab Entdeckung in jedem Fall.

Die eigentliche Schwachstelle ist dauerhafter Zugriff, nicht das Modellverhalten

Hier wird es unangenehm. Die Reflexreaktion der Sicherheitsbranche nach einem solchen Vorfall ist, das Modell zu hinterfragen: Warum fiel es auf „Additionally“ herein, welcher Filter hätte das verhindern müssen, welcher Anbieter patcht zuerst? Diese Reaktion behandelt das Symptom als Ursache.

Der GitLost-Agent brauchte die Berechtigung, ein einziges Issue in einem Repository zu lesen. Er hatte dauerhaften Lesezugriff auf alle Repositories der Organisation – öffentlich und privat, unbegrenzt. Diese Lücke zwischen dem, was eine Aufgabe erfordert, und dem, was einer Identität gewährt wird, verursachte den eigentlichen Schaden. Die Prompt Injection war nur der Auslöser.

Nennen wir es beim Namen: der All-Access-Agent. Unternehmen statten KI-Agenten mit Berechtigungen aus wie IT-Abteilungen 2005 Service-Accounts – breit, dauerhaft, selten überprüft. Nur sitzen diese Zugangsdaten jetzt hinter einem System, das jeder, der einen Satz tippen kann, dazu bringen kann, sie zu nutzen.

Der State of Non-Human Identity and AI Security Survey Report der Cloud Security Alliance liefert Zahlen zur Verbreitung dieser Lücke. Weniger als ein Viertel der Unternehmen verfügt über dokumentierte, formell eingeführte Richtlinien zur Erstellung oder Stilllegung von KI-Identitäten. Nur 12 % geben an, sehr zuversichtlich zu sein, Angriffe über nicht-menschliche Identitäten verhindern zu können. Über 16 % erfassen nicht einmal, wann neue KI-bezogene Identitäten überhaupt erstellt werden.

Zwölf Prozent. Das ist kein Rundungsfehler in einem Reifegradmodell. Das bedeutet, dass fast neun von zehn Sicherheitsverantwortlichen auf Nachfrage zugeben, dass sie einen solchen Vorfall morgen nicht verhindern könnten. Lieferketten-Risikomanagementprogramme, die den Zugriff menschlicher Dienstleister regeln, aber nicht auf von denselben Anbietern bereitgestellte KI-Agenten-Identitäten ausgeweitet werden, übersehen die am schnellsten wachsende nicht-menschliche Identitätspopulation im Unternehmen.

Warum Schutzmaßnahmen allein weiterhin scheitern werden

Es gibt zwei intuitive Reaktionen auf GitLost – beide sind falsch.

Die erste ist, agentische KI komplett zu blockieren, bis die Technologie reifer ist – GitHub Agentic Workflows einfrieren, Copilot-Integrationen stoppen, warten, bis die Anbieter das Problem lösen. Das gibt die Produktivitätsgewinne auf, die ein Agent bei der Triage von Issues rund um die Uhr tatsächlich bringt, und ist im Wettbewerb nicht durchzuhalten. Entwicklungsteams, denen man ein Verbot erteilt, finden einen Workaround – ob genehmigt oder nicht. Dieser Workaround ist Schatten-KI: unkontrollierte Agenten außerhalb des Policy-Perimeters, ohne Audit-Trail und ohne Zugriffskontrolle.

Die zweite ist, dem Modell zu vertrauen. Bessere Prompts schreiben, das neueste Schutz-Update des Anbieters abonnieren, „Additionally“ als Einzelfall betrachten, den die nächste Modellversion erkennt. Der State of AI Agent Security 2026 Report von Gravitee zeigt, wie diese Wette ausgeht: 88 % der Unternehmen mit produktiven KI-Agenten bestätigten oder vermuteten im letzten Jahr einen Sicherheitsvorfall im Zusammenhang mit diesen Agenten, obwohl 82 % der Führungskräfte angaben, ihre bestehenden Richtlinien würden sie bereits vor unbefugten Agentenaktionen schützen.

Beides stimmt. Gleichzeitig. Führungskräfte glauben, sie seien abgesichert. Die Vorfalldaten sagen das Gegenteil. In dieser Lücke zwischen Vertrauen und Realität entstehen GitLost-Angriffe – und kein Prompt Engineering schließt sie, weil die Schutzmaßnahme auf der falschen Ebene greift.

Die Lösung ist weder, KI zu blockieren, noch ihr blind zu vertrauen. Es geht darum, Agentenzugriffe so zu behandeln, wie Sicherheitsteams es längst für menschliche Zugriffe tun – und das bisher einfach noch nicht umgesetzt haben.

Die Governance-Lücke hinter der Einführung von KI-Agenten

Jedes Unternehmen, das einen KI-Agenten auf eigene Daten ansetzt, hat bereits eine implizite Entscheidung darüber getroffen, wie viel dieser Agent sehen darf. Fast niemand hat sie bewusst getroffen.

Dauerhafter, breiter, selten geprüfter Zugriff ist Standard – nicht, weil jemand das so wollte, sondern weil das Scoping pro Aufgabe mehr Aufwand ist, als einmalige Provisionierung und dann weiterzugehen. Das ist derselbe Shortcut, der zu ausufernden Service-Account-Berechtigungen, vergessenen IAM-Rollen und Drittanbieter-Integrationen führte, an die sich niemand mehr erinnert. Agentische KI agiert nur schneller, greift auf mehr Systeme zu und – wie GitLost zeigt – lässt sich von jedem steuern, der einen Satz in ein öffentliches Forum schreiben kann.

Nomas eigene Empfehlungen an Entwickler machen die Prioritäten klar: Niemals nutzerkontrollierte Inhalte als vertrauenswürdige Anweisungen behandeln, einschränken, was ein Agent öffentlich posten darf, und – an erster Stelle – Berechtigungen auf das Minimum für die jeweilige Aufgabe beschränken. Zwei dieser drei Empfehlungen betreffen nicht das Modell, sondern Data Governance. Datenminimierung auf den Zugriff von KI-Agenten angewendet – jedem Agenten nur Lesezugriff auf die spezifischen Repositories, Dateien oder Datentypen zu geben, die seine Aufgabe erfordert – ist die praktische Umsetzung dieses Governance-Prinzips.

Auch Regulierungsbehörden warten nicht, bis die Branche das Problem selbst löst. Der OWASP-Bericht listet 42 verschiedene regulatorische Vorgaben in 10 Jurisdiktionen auf, die bereits KI-Incident-Response adressieren – einige davon mit Meldefristen von Stunden, nicht Quartalen. Ein Unternehmen, das am Tag eines Vorfalls nicht beantworten kann, „was konnte dieser Agent erreichen?“, wird diese Antwort nicht schnell genug für die Aufsicht liefern – geschweige denn für Kunden. Ein dokumentierter Incident-Response-Plan, der explizit auch KI-Agenten-Exfiltrationsszenarien abdeckt – inklusive Runbooks für das von GitLost demonstrierte Szenario „Agent postet vertrauliche Daten öffentlich“ – macht aus hektischem Krisenmanagement eine eingeübte, zeitlich begrenzte Reaktion.

Was die Lücke tatsächlich schließt: Gescopte, kontrollierte KI-Agenten-Zugriffe

Hören Sie auf zu fragen, ob Ihr Modell schlau genug ist, bösartige Anweisungen zu erkennen. Die entscheidende Frage ist: Was könnte dieser Agent im Falle einer Übernahme tatsächlich erreichen?

Die Antwort erfordert vier konkrete Kontrollen, nicht ein vages Bekenntnis zu „KI-Governance“.

• Zugriff pro Aufgabe, nicht pro Identität scopen. Ein Agent, der ein einzelnes Issue triagiert, braucht keinen dauerhaften Zugriff auf alle privaten Repositories der Organisation. Role-based– und Attribute-based Access Control-Richtlinien, die jede Anfrage anhand von Klassifizierung, Sensitivität und Kontext bewerten – statt einmalig breite Berechtigungen zu vergeben –, begrenzen das Schadensausmaß auf das, was diese eine Aufgabe tatsächlich erfordert. Das ist das gleiche Least-Privilege-Prinzip, das seit zwei Jahrzehnten für menschliche Accounts gilt, jetzt endlich auf Identitäten angewendet, die sie zahlenmäßig längst übertreffen.
• Anmeldedaten vom Reasoning-Layer isolieren. Die Tokens, mit denen ein Agent agiert, sollten in einem Keychain oder Vault abgelegt werden, den das Sprachmodell selbst nie sieht. Kiteworks hat seinen Secure MCP Server genau nach diesem Prinzip gebaut: OAuth-Zugangsdaten werden im Credential Store des Betriebssystems gespeichert und sind im Kontext des LLM nie verfügbar – ein kompromittierter Agent kann also selbst im Erfolgsfall keine Schlüssel extrahieren, die über die aktuelle Session hinausreichen.
• Die Datenebene unabhängig von den Absichtserklärungen des Agenten steuern. Die vom Agenten behauptete Absicht ist keine Sicherheitskontrolle – sie ist ein Vorschlag, den der Agent selbst generiert hat. Kiteworks Compliant AI erzwingt RBAC und ABAC-Entscheidungen auf Content-Ebene für jede KI-Anfrage, in Echtzeit, unabhängig davon, was der Agent selbst für zulässig hält. Das CISO Dashboard zeigt alle KI-Datenzugriffe in Echtzeit, sodass Sicherheitsteams das nötige Verhaltenstransparenz erhalten, um anomale Agentenaktivitäten zu erkennen, bevor eine Exfiltration abgeschlossen ist.
• Davon ausgehen, dass der Exfiltrationskanal jedes legitime Werkzeug ist, das der Agent bereits hat – und entsprechend prüfen. GitLost erforderte keine neue Fähigkeit. Es nutzte das Kommentieren – eine Funktion, die der Agent ohnehin haben sollte. Vollständige, manipulationssichere Audit Trails aller Dateien, die der Agent berührt hat, und aller seiner Ausgaben machen aus einem Vorfall eine fünfminütige forensische Recherche – und sie sind der Unterschied zwischen Raten und Nachweisen. Werden diese Logs in Echtzeit an eine SIEM-Plattform übergeben, erhalten Sicherheitsteams die Korrelation, um mehrstufige Exfiltrationsmuster zu erkennen, die in einzelnen Audit Logs nicht sichtbar wären.

Nichts davon verhindert, dass Prompt Injection überhaupt passiert. Das kann heute kein Produkt am Markt zuverlässig. Entscheidend ist, ob eine Injection zum Datenschutzverstoß wird – nicht, ob das Modell hereingelegt wurde, sondern ob der Agent, der darauf hereinfiel, Zugriff auf etwas Wertvolles hatte.

Was Sie am Montagmorgen tun sollten

Hören Sie auf zu diskutieren, welcher KI-Anbieter die besseren Schutzmaßnahmen hat. Beginnen Sie damit, zu prüfen, worauf Ihre bestehenden Agenten tatsächlich zugreifen können.

Erstellen Sie eine Berechtigungsliste für jeden KI-Agenten oder automatisierten Workflow mit Zugriff auf Ihre Repositories, Dateispeicher oder Zero Trust Data Exchange-Umgebung. Schreiben Sie für jeden auf, was der Agent tun soll, und vergleichen Sie das mit dem, worauf er tatsächlich Zugriff hat. Wo diese beiden Listen nicht übereinstimmen, wartet ein GitLost auf Sie.

Schließen Sie die Lücke dann auf der Zugriffsebene, nicht auf der Prompt-Ebene. Berechtigungen auf die Aufgabe beschränken. Anmeldedaten vor dem Modell abschirmen. Jede KI-gesteuerte Datenanfrage durch eine Policy Enforcement führen, die sich nicht für die behauptete Absicht des Agenten interessiert. Alles so protokollieren, als würde ein Auditor danach fragen – denn irgendwann wird das passieren.

Die Unternehmen, die vom nächsten GitLost-Vorfall getroffen werden, sind diejenigen, die immer noch darüber streiten, welches Modell sicherer ist – statt zu fragen, worauf ihre Agenten nie hätten zugreifen dürfen.

Erfahren Sie mehr darüber, wie Sie KI-Agenten-Datenzugriffe steuern, bevor der nächste GitLost-Vorfall Ihr Unternehmen trifft – vereinbaren Sie jetzt eine individuelle Demo.

Weitere Ressourcen

• Blogbeitrag
  Zero‑Trust-Strategien für bezahlbaren KI-Datenschutz
• Blogbeitrag
  Wie 77 % der Unternehmen bei KI-Datensicherheit versagen
• eBook
  KI-Governance-Lücke: Warum 91 % kleiner Unternehmen 2025 russisches Roulette mit Datensicherheit spielen
• Blogbeitrag
  Es gibt kein „–dangerously-skip-permissions“ für Ihre Daten
• Blogbeitrag
  Regulierungsbehörden fragen nicht mehr, ob Sie eine KI-Policy haben. Sie wollen Beweise, dass sie funktioniert.