GitHub scannt KI-Agenten auf Prompt Injection: Was die neue Sicherheitsprüfung leistet

GitHub startet KI-Sicherheitsprüfung für Agenten

Am 28. Oktober 2026 hat GitHub eine öffentliche Vorschau für das Scannen von KI-Anwendungen angekündigt. Das neue Verfahren untersucht Pull Requests auf riskante Datenflüsse in Anwendungen mit Sprachmodellen und autonomen Agenten. Im Mittelpunkt steht die Frage, ob fremde Inhalte das Verhalten eines Modells beeinflussen können, das wiederum auf Werkzeuge, Daten oder Geschäftssysteme zugreift. Für Entwicklungsteams wird damit eine Sicherheitsklasse sichtbar, die klassische Codeprüfungen häufig nicht ausreichend erfassen.

Die Ankündigung ist vor allem für Unternehmen relevant, die Dokumentenassistenten, Support-Bots, Recherche-Agenten oder automatisierte Backoffice-Prozesse entwickeln. Solche Systeme verbinden Sprachmodelle mit echten Berechtigungen. Ein Fehler betrifft dann nicht nur die Qualität einer Antwort, sondern möglicherweise Dateien, Kundendaten oder Aktionen in angeschlossenen Anwendungen. Die neue Prüfung ist ein zusätzlicher Kontrollpunkt im Entwicklungsprozess, keine Garantie für sichere KI-Systeme.

Was ist indirekte Prompt Injection?

Bei einer indirekten Prompt Injection versteckt ein Angreifer Anweisungen in Inhalten, die ein KI-System eigentlich nur als Daten verarbeiten soll. Das können Webseiten, PDFs, Repository-Dateien, Support-Tickets oder API-Antworten sein. Liest ein Agent diese Informationen und behandelt darin enthaltene Befehle wie vertrauenswürdige Arbeitsanweisungen, kann er vom ursprünglichen Auftrag abweichen. Der Angriff erfolgt somit nicht zwingend über die direkte Nutzereingabe.

Ein Beispiel: Ein interner Recherche-Agent soll öffentlich zugängliche Produktinformationen zusammenfassen. Auf einer manipulierten Webseite findet er zusätzlich die Aufforderung, interne Dokumente an eine externe Adresse zu senden. Kritisch wird es, wenn der Agent sowohl diese Seite lesen als auch auf interne Dateien und Netzwerkfunktionen zugreifen darf. Das Problem ist die überschrittene Vertrauensgrenze zwischen fremdem Inhalt und ausführbarer Handlung.

Was die neue Vorschau tatsächlich erkennt

GitHubs Ankündigung nennt drei Risikofelder: indirekte Prompt Injection, Offenlegung sensibler Informationen und übermäßige Handlungsmacht von Agenten. Die aktuelle technische Dokumentation grenzt den tatsächlichen Umfang der öffentlichen Vorschau jedoch enger ein: Zunächst erkennt der neue Detektor ausschließlich indirekte Prompt-Injection-Schwachstellen in KI-Agenten. Weitere Risikokategorien sind damit noch nicht als vollständig verfügbare Erkennung zu verstehen.

Das ist eine wichtige Unterscheidung für Security-Teams. Eine Marketingüberschrift ersetzt keine genaue Prüfung der Produktdokumentation. Wer die Funktion einführt, sollte daher nicht annehmen, dass automatisch sämtliche Datenabflüsse, Berechtigungsfehler oder Agentenmissbräuche gefunden werden. Für diese Themen bleiben Architekturprüfungen, Zugriffstests, Protokollierung und gezielte Sicherheitstests notwendig.

Wie die Prüfung im Pull Request arbeitet

Der Detektor untersucht Pull Requests bei ihrer Erstellung und nach neuen Commits. Er analysiert Codepfade und Datenflüsse, bei denen nicht vertrauenswürdige Inhalte an ein Modell gelangen, das mit Werkzeugen oder Unternehmensressourcen verbunden ist. Anders als klassische CodeQL-Abfragen nutzt die Funktion einen sprachmodellbasierten Ansatz und ist laut GitHub nicht auf bestimmte Programmiersprachen oder Frameworks beschränkt.

Die Ergebnisse erscheinen als Kommentare direkt am Pull Request. Entwickler erhalten Hinweise auf verdächtige Stellen und Vorschläge zur Abhilfe. Solche Befunde sind ausdrücklich beratend: Sie verhindern einen Merge nicht automatisch. Die Vorschau untersucht außerdem weder den vollständigen Repository-Bestand noch Pull Requests aus Forks oder von Dependabot. Wer nur auf die neuen Kommentare achtet, übersieht möglicherweise Risiken in bereits produktivem Code.

Drei GitHub-Scanner, drei unterschiedliche Aufgaben

GitHub unterscheidet inzwischen mehrere Prüfverfahren. CodeQL analysiert bekannte Klassen klassischer Softwareschwachstellen. AI Scan für Pull Requests ergänzt diese Prüfung bei allgemeinen Sicherheitsproblemen in ausgewählten Sprachen und Frameworks, die CodeQL nicht abdeckt. Das neue Scannen für KI-Anwendungen konzentriert sich dagegen auf agentenspezifische Risiken wie indirekte Prompt Injection. Die drei Verfahren sind nicht austauschbar.

Parallel hat GitHub am 28. Oktober AI Scan für ganze Repositories als weitere öffentliche Vorschau vorgestellt. Diese Variante lässt sich auf dem aktuellen Commit des Standardbranches manuell starten und schreibt Befunde in den regulären Code-Scanning-Backlog. Sie sucht allgemeine Sicherheitslücken, auch außerhalb des Pull-Request-Diffs. Sie darf nicht mit dem speziellen Agenten-Detektor verwechselt werden, der derzeit ausschließlich Pull Requests betrachtet.

Warum Agenten ein anderes Bedrohungsmodell brauchen

Bei gewöhnlichen Webanwendungen sind Eingabevalidierung, Autorisierung und sichere Ausgabeverarbeitung vertraute Schutzmaßnahmen. KI-Agenten ergänzen eine weitere Ebene: Sie interpretieren natürliche Sprache und können daraus Aktionen ableiten. Eine Anweisung in einer externen Quelle kann deshalb zur vermeintlichen Arbeitsanweisung werden. Besonders riskant sind Agenten, die E-Mails versenden, Dateien verändern, Datenbanken abfragen oder externe APIs ohne zusätzliche Freigabe bedienen.

Die OWASP-Initiative für generative KI beschreibt Prompt Injection als zentrales Risiko und dokumentiert auch reale Angriffsmuster. Daraus folgt nicht, dass jeder gefundene verdächtige Text tatsächlich ausnutzbar ist. Entscheidend sind Kontext, verfügbare Werkzeuge, Berechtigungen und Kontrollmechanismen. Ein Sicherheitsbefund muss deshalb anhand des konkreten Datenflusses geprüft werden: Welche Quelle ist unzuverlässig, welche Aktion wäre möglich und welche Grenze fehlt?

Praktische Schutzmaßnahmen vor dem ersten Scan

Teams sollten zunächst erfassen, welche Agenten überhaupt externe Inhalte verarbeiten und welche Tools sie ausführen dürfen. Für jedes Tool sind minimale Berechtigungen sinnvoll: Ein Leseassistent benötigt normalerweise keinen Schreibzugriff auf Kundendaten. Sensible Aktionen wie Versand, Löschung, Zahlung oder Berechtigungsänderung sollten eine zusätzliche, vom Modell unabhängige Bestätigung verlangen. Auch Ausgehende Netzwerkverbindungen lassen sich auf notwendige Ziele beschränken.

Ebenso wichtig ist die klare Trennung von Systemanweisungen, Nutzerauftrag und fremdem Material. Inhalte aus Webseiten oder Dokumenten dürfen nicht allein aufgrund ihrer Formulierung Autorität erhalten. Ein Filter für auffällige Texte kann helfen, ersetzt aber keine Berechtigungsgrenzen. Protokolle sollten nachvollziehbar machen, welche Quelle gelesen, welches Werkzeug aufgerufen und welche Freigabe erteilt wurde, ohne dabei unnötig sensible Daten zu speichern.

So führen Teams die Funktion kontrolliert ein

Nach GitHubs Dokumentation ist die neue Prüfung auf Enterprise-, Organisations- und Repository-Ebene zunächst deaktiviert. Eine Enterprise-Richtlinie muss KI-gestützte Scans erlauben; anschließend aktiviert die Organisation den Schalter für das Scannen von KI-Anwendungen. Bereits aktiviertes AI Scan für allgemeine Pull-Request-Schwachstellen schaltet diese Funktion nicht automatisch ein. Repository-Administratoren können für einzelne Repositories abwählen.

Für einen Pilotbetrieb eignet sich ein überschaubares Repository mit einem realen Agenten-Workflow. Das Team kann neue Pull Requests beobachten, Befunde klassifizieren und nachvollziehen, ob vorgeschlagene Korrekturen die Vertrauensgrenze tatsächlich verbessern. Sinnvolle Kennzahlen sind bestätigte Probleme, Fehlalarme, Zeit bis zur Behebung und wiederkehrende Fehlermuster. Erst danach sollte die Organisation über einen breiteren Rollout entscheiden.

Lizenzen, Kosten und technische Grenzen

Das Scannen von KI-Anwendungen befindet sich auf github.com in einer öffentlichen Vorschau und setzt GitHub Advanced Security voraus. Nach der Dokumentation verbraucht es zusätzliche AI Credits, auch bei berechtigten öffentlichen Repositories. GitHub Enterprise Server unterstützt die neue Funktion derzeit nicht. Vor der Aktivierung sollten Verantwortliche deshalb Lizenzlage, Budget und mögliche Auswirkungen auf Entwicklungsabläufe prüfen.

Die Repository-Variante von AI Scan besitzt andere Bedingungen: Für öffentliche Repositories persönlicher Konten ist sie verfügbar, für deren private Repositories nicht; bei Organisationen gelten zusätzliche Produktvoraussetzungen. Ein Copilot-Abonnement ist für diese Repository-Scans nicht erforderlich. Gerade weil mehrere Funktionen ähnlich heißen, sollten Kosten und Berechtigungen für jede Variante einzeln dokumentiert werden. Ein pauschales Versprechen kostenloser KI-Sicherheitsprüfung wäre irreführend.

Was Entwickler bei einem Alarm prüfen sollten

Ein Hinweis auf Prompt Injection ist ein Ausgangspunkt für eine Untersuchung, kein automatisches Urteil. Zuerst sollte das Team die unzuverlässige Quelle identifizieren und prüfen, wie deren Inhalt in den Modellkontext gelangt. Danach folgt die Frage, welche Tools das Modell ansprechen kann und ob deren Aufrufe serverseitig autorisiert werden. Wichtig ist außerdem, ob eine Angreiferanweisung tatsächlich eine sicherheitsrelevante Aktion auslösen könnte.

Bei einer Korrektur sollte nicht nur der auffällige Prompt umformuliert werden. Nachhaltiger sind engere Tool-Rechte, explizite Freigaben und getrennte Ausführungskontexte. Anschließend empfiehlt sich ein reproduzierbarer Test mit harmlosen Angriffsmustern, der nachweist, dass fremde Dokumente keine unerlaubten Aktionen auslösen. Sicherheitsverantwortliche sollten bestätigte Fehlalarme ebenso dokumentieren wie echte Schwachstellen, damit die Prüfung mit der Zeit nützlicher wird.

Was die Neuerung für kleine Webteams bedeutet

Nicht jedes Webprojekt benötigt einen komplexen KI-Agenten. Wer lediglich einen Chatbot ohne Systemzugriffe betreibt, hat ein anderes Risikoprofil als ein Agent, der CRM-Daten verändert oder Support-E-Mails verschickt. Gerade kleine Teams sollten daher zuerst den tatsächlichen Handlungsspielraum ihrer KI-Funktionen verstehen. Eine einfache Berechtigungsmatrix und klare Grenzen zwischen Daten und Anweisungen können mehr bewirken als ein unkoordiniert eingeschalteter Scanner.

Für PHP-, JavaScript- oder Python-Projekte ist die wichtigste Botschaft unabhängig vom konkreten Produkt: Sobald Sprachmodelle mit Dateien, Datenbanken und APIs arbeiten, gehört die Prüfung ihrer Vertrauensgrenzen in den regulären Review-Prozess. GitHubs neue Vorschau kann dabei helfen, bestimmte riskante Muster frühzeitig sichtbar zu machen. Die Verantwortung für sichere Architektur, Tests und Freigaben bleibt jedoch beim Entwicklungsteam.

Fazit: Nützlicher Kontrollpunkt, kein Sicherheitssiegel

Die Ankündigungen vom 28. Oktober zeigen, dass sich Code-Sicherheit stärker auf KI-Anwendungen und agentische Workflows ausrichtet. GitHub ergänzt klassische Prüfungen um einen Detektor für indirekte Prompt Injection und erweitert zugleich KI-basierte Scans auf komplette Repositories. Beide Entwicklungen sind praktisch relevant, erfüllen aber unterschiedliche Aufgaben und haben unterschiedliche Voraussetzungen.

Wer die neuen Funktionen einsetzen möchte, sollte mit einem begrenzten Pilotprojekt starten, die dokumentierten Vorschaugrenzen beachten und jeden Befund fachlich bewerten. Der entscheidende Fortschritt ist nicht, dass ein Modell anderen Modellcode überprüft. Wertvoll wird die Technik erst dann, wenn sie konkrete Vertrauensbrüche aufdeckt und Entwickler daraus überprüfbare Schutzmaßnahmen ableiten.