Prompt Injection im Team: Issues, READMEs und Tool-Ausgaben

Ein Coding-Agent liest den ganzen Tag Text, den Ihr Team nicht geschrieben hat: Issues von Externen, Kommentare in Pull Requests, die Dokumentation von Bibliotheken, Webseiten, Ausgaben von Tools. Für den Agenten ist das alles derselbe Strom aus Tokens. Genau darin liegt das Problem, das unter dem Namen Prompt Injection bekannt ist. Steht in einem dieser Texte eine Anweisung, kann der Agent sie ausführen, als käme sie von Ihnen.

Für Entwicklerteams ist das keine theoretische Frage mehr, sobald Agenten Werkzeuge haben: Dateien lesen, Befehle ausführen, Pull Requests anlegen.

Wo fremder Text in Agenten-Sessions landet

Gefährlich sind nicht die Prompts, die Ihr Team selbst schreibt, sondern Inhalte, die der Agent unterwegs einsammelt. Im Entwickleralltag sind das vor allem:

Issues und Kommentare in öffentlichen oder für Externe offenen Repositories.
READMEs und Dokumentation von Abhängigkeiten, die ein Agent liest, um eine Bibliothek zu verstehen.
Webseiten, die der Agent für Recherche oder Fehlersuche abruft.
Ausgaben von Tools und MCP-Servern, etwa Ticketinhalte, Logs oder Suchergebnisse.
Fremde Repositories, die geklont und mit einem Agenten untersucht werden.

Der Entwickler und Autor Simon Willison bringt den Kern so auf den Punkt: Sprachmodelle folgen Anweisungen in Inhalten, und sie können nicht zuverlässig unterscheiden, woher eine Anweisung stammt. Man kann sie anweisen, eingeschleuste Befehle zu ignorieren, verlassen kann man sich darauf aber nicht. Und weil die Modelle nicht deterministisch arbeiten, kann ein Schutz, der heute greift, morgen versagen.

Das Muster: drei Fähigkeiten, die zusammen gefährlich werden

Willison beschreibt eine Kombination, die er als „lethal trifecta” bezeichnet. Ein Agent wird angreifbar, sobald er gleichzeitig:

Zugriff auf private Daten hat, etwa auf nicht öffentlichen Code, Secrets oder interne Tickets,
nicht vertrauenswürdigen Inhalten ausgesetzt ist und
nach außen kommunizieren kann, über eine HTTP-Anfrage, einen Link, ein Bild oder einen öffentlichen Pull Request.

Hat ein Agent alle drei, kann ein Angreifer ihn dazu bringen, Daten einzusammeln und hinauszuschicken. Anbieter schließen solche Lücken in ihren eigenen Produkten meist, indem sie den Ausleitungsweg sperren. Kombiniert ein Team aber selbst Werkzeuge, etwa mehrere MCP-Server, kann der Anbieter das nicht für Sie lösen. Guardrail-Produkte, die eine Erkennungsquote von 95 Prozent versprechen, hält Willison für ungenügend: In der Anwendungssicherheit sei das eine glatte Fehlnote.

Ein konkretes Beispiel: das präparierte Issue

Wie das in der Praxis aussieht, hat Invariant Labs am offiziellen GitHub-MCP-Server demonstriert. Die Ausgangslage: Ein Nutzer hat ein öffentliches und ein privates Repository, und sein Agent ist über MCP mit seinem GitHub-Konto verbunden. Ein Angreifer legt im öffentlichen Repository ein Issue mit versteckten Anweisungen an.

Bittet der Nutzer seinen Agenten nun ganz harmlos, sich die offenen Issues anzusehen, liest der Agent das präparierte Issue, holt daraufhin Informationen aus privaten Repositories und veröffentlicht sie in einem Pull Request im öffentlichen Repository. Der Client fragte zwar standardmäßig vor jedem Tool-Aufruf nach. Viele Nutzer stellen aber auf „Always Allow” und schauen dann nicht mehr hin.

Wichtig ist die Einordnung der Forscher: Es handelte sich nicht um einen Fehler im Code des MCP-Servers, sondern um ein Architekturproblem. Es betrifft jeden Agenten, der diesen Server nutzt, unabhängig vom Modell.

Was im Team konkret hilft

Einen vollständigen technischen Schutz gibt es nach heutigem Stand nicht. Teams können aber verhindern, dass alle drei Fähigkeiten gleichzeitig in einer Session zusammenkommen, und dafür sorgen, dass folgenreiche Aktionen nicht unbemerkt passieren. Daraus lassen sich Teamregeln ableiten, die sich an der Sicherheitsdokumentation von Claude Code orientieren:

Netzwerkzugriff als Teamentscheidung: Befehle, die nach außen kommunizieren, gibt Claude Code standardmäßig nicht automatisch frei. Ob und wo das gelockert wird, entscheidet das Team gemeinsam und nicht jede Person für sich.
Automatisierung gesondert betrachten: Läuft ein Agent ohne Rückfragen, etwa in CI, fallen die interaktiven Bestätigungen weg. Solche Läufe brauchen eine eigene, im Team abgestimmte Freigabe, welche Inhalte sie lesen und wohin sie schreiben dürfen.
Keine Pauschalfreigaben: Das GitHub-Beispiel zeigt, was „immer erlauben” bewirken kann. Freigaben für Tools, die nach außen schreiben, gehören ins Team-Review, nicht in individuelle Bequemlichkeit.
Fremdes getrennt halten: Die Dokumentation rät, nicht vertrauenswürdige Inhalte nicht direkt an den Agenten weiterzureichen, Änderungen an kritischen Dateien zu prüfen und bei Arbeit mit externen Webdiensten isolierte Umgebungen zu nutzen.
MCP-Server über einen Freigabeprozess: Anthropic empfiehlt eigene Server oder solche von vertrauenswürdigen Anbietern. Welche Server im Team erlaubt sind, sollte eine kurze, gepflegte Liste im Repository festhalten.

Die technische Umsetzung der Berechtigungen ist Konfigurationsarbeit. Die Grundsatzentscheidung, welche Sessions welche der drei Fähigkeiten haben dürfen und wer das freigibt, ist dagegen eine Teamfrage.

Was das für Ihr Entwicklerteam bedeutet

Prompt Injection lässt sich nicht wegprompten. Wirksam sind Regeln, die festlegen, wo ein Agent fremde Inhalte liest, was er in derselben Session darf und wann ein Mensch bestätigt. Eine Session, die externe Issues sichtet, braucht keinen Zugriff auf private Repositories und kein Recht, öffentlich zu schreiben. Diese Trennung muss im Team verabredet und in geteilten Einstellungen festgehalten sein, wie im Beitrag Claude Code im Team beschrieben. Im Review lohnt der Blick darauf, ob eine Änderung auf einen fremden Anstoß zurückgeht; die Review-Checkliste für KI-generierte Pull Requests hilft dabei. Welche Fragen IT-Security vor einem Training klären sollte, steht auf der Seite Sicherheit.

Das Risiko verschwindet nicht, aber es wird beherrschbar, wenn das Team die gefährliche Kombination kennt und gezielt vermeidet.

Sie möchten Injection-Szenarien mit Ihrem Team an den eigenen Repositories und Tools durchspielen und daraus Regeln ableiten? Inhouse-Training anfragen.