Quellcode Prompt Injection

Was ist Quellcode Prompt Injection?

Quellcode Prompt Injection ist indirekte Prompt Injection über Repository-Material, das ein Coding-Assistent oder Agent liest, durchsucht, indexiert, zusammenfasst oder in den Modellkontext aufnimmt. Beeinflussende Sprache kann in Kommentaren, Docstrings, README-Dateien, Konfiguration, Test-Fixtures, Beispielen, generierten Dateien, Issues, Pull Requests oder einer ausdrücklich unterstützten Repository-Anweisungsdatei stehen.

Das Primitive ist semantische Beeinflussung, nicht ausführbarer Code. Eine von Beitragenden kontrollierte Textpassage kann Interpretation, Plan oder vorgeschlagenen Patch verändern, obwohl jede Datei korrekt geparst wird und kein schädliches Programm läuft. Eine Sicherheitsauswirkung erfordert zusätzlich erreichbare Daten oder Fähigkeiten und eine fehlende, zu weite oder versagende Anwendungskontrolle.

Umfang und verwandte Angriffsklassen

Ein kompromittiertes Repository, eine Abhängigkeit oder Paketbeschreibung kann Inhalt zustellen, ist aber nicht selbst das Prompt-Injection-Primitive. Dieser Artikel beginnt dort, wo Repository- oder Aufgabenmaterial modellsichtbar wird und den Coding-Workflow beeinflussen kann.

Repository- und Coding-Agent-Pipeline

Produkte setzen diesen Pfad unterschiedlich zusammen. Manche prüfen nur offene Dateien, andere durchsuchen einen lokalen Checkout oder fragen einen entfernten Index ab; manche verbinden Repository-Dateien mit Issue- oder Pull-Request-Kontext. Vertrauenswürdige Prozessoren können nicht vertrauenswürdigen Text zuverlässig transportieren. Ihre betriebliche Vertrauenswürdigkeit erhöht nicht die Autorität ihrer Ausgabe.

Inhaltsflächen im Repository

Quelltext ist standardmäßig Dateninhalt

Code, Kommentare, Dokumentation, Testdaten und Konfiguration sind Evidenz über das Repository. Autorenschaft, Speicherort, erfolgreiche Kompilierung, Signatur oder Ablage in einem internen Repository machen ihre natürlichsprachlichen Aussagen nicht zu autoritativen Anweisungen für ein AI-System.

Auch der Text der Nutzeraufgabe ist Eingabe und keine Anwendungsautorität. Die Anwendung definiert Ziel und erlaubte Fähigkeiten; deterministische Kontrollen entscheiden über Ressourcen und Auswirkungen. Weder Nutzerformulierung noch Repository-Text dürfen diese Grenze erweitern.

Ausgewiesene Repository-Anweisungen als eigene Autoritätsklasse

Einige Produkte unterstützen bewusst Repository-Anweisungsmechanismen. Für GitHub Copilot dokumentiert GitHub .github/copilot-instructions.md, pfadspezifische Dateien unter .github/instructions/**/*.instructions.md und Agent-Anweisungsdateien wie AGENTS.md. Unterstützung, Kombination und Präzedenz unterscheiden sich je Copilot-Funktion und Oberfläche. Solche Dateien können nur dort höhere Workflow-Anweisungsautorität tragen, wo diese konkrete Produktoberfläche sie auswertet.

Diese Autorität bleibt begrenzt. Sie steht nie über System- oder Anwendungspolitik und autorisiert weder Datenzugriff noch Nebenwirkungen. Provenienz, Pfad, Geltungsbereich, produktspezifische Präzedenz und Schreibrechte bilden eine eigene Sicherheitsgrenze. Unterstützung und Kombination variieren je Produkt und Oberfläche und müssen geprüft statt verallgemeinert werden.

Branch-, Ref-, Commit- und Worktree-Zustand

Ein Repository-Name identifiziert nicht das Material, das ein Agent sah. Branches, Tags und Pull-Request-Refs können auf unterschiedliche Commits zeigen; ein lokaler Worktree kann gestagte, ungestagte oder unversionierte Änderungen enthalten; Submodule können auf andere Zustände verweisen. Eine Prüfung muss aufgelösten Commit und Arbeitszustand festhalten.

Inhalt aus nicht vertrauenswürdigen Forks oder Pull Requests darf nicht stillschweigend den Integritäts- oder Provenienzstatus eines freigegebenen oder fixierten Basiszustands erben. Gewöhnlicher Quelltext bleibt auf beiden Seiten Dateninhalt. Wo ausgewiesene Anweisungsdateien unterstützt werden, muss das System ausdrücklich festlegen, ob die wirksamen Anweisungen aus dem freigegebenen oder fixierten Basiszustand, der vorgeschlagenen Änderung oder beiden stammen, und diese Entscheidung für Policy und Review sichtbar machen.

Suche, Indexierung und Kontextauswahl

Coding-Systeme wählen Kontext häufig über Dateinamensuche, Symbolgraphen, lexikalische oder semantische Indizes, den Editorzustand und modellgesteuerte Folgesuchen. Relevanz bestimmt Erreichbarkeit, nicht Vertrauen. Ein Treffer kann hochrelevant und dennoch von Beitragenden kontrolliertes Aufgabenmaterial sein.

Die Auswahl kann iterativ sein: Eine aufgenommene Passage kann beeinflussen, welches Symbol, welche Datei oder welches Verzeichnis das Modell als Nächstes untersucht. Deshalb sollten alle Queries und Treffermengen protokolliert, durchsuchbare Bereiche begrenzt und Autoritätslabels jedes Ergebnisses erhalten werden. Bei geschützten Repositories oder Pfaden sollten Indexierung und Retrieval die jeweils geltenden Zugriffsrechte der auslösenden Identität oder einen enger begrenzten delegierten Umfang durchsetzen.

Was tatsächlich modellsichtbar wird

Provenienz und abgeleitete Repository-Artefakte

Jede modellsichtbare Passage sollte nach Möglichkeit Repository-Identität, Owner, Branch oder Ref, aufgelöste Commit-SHA, Dateipfad, Blob- oder Content-Hash, Zeilen- oder Passagenkennung, Retrieval-Query, Indexgeneration und Worktree-Status behalten. Issue-, Pull-Request- und Aufgabenkontext benötigen eigene Provenienz zu Autor, Ereignis und Berechtigung.

Zusammenfassungen, Symbolindizes, Embeddings, Caches und Memory sind abgeleitete Artefakte. Sie brauchen Lineage zu ihren Quellpassagen und Zugriffslabels. Das Entfernen oder Korrigieren einer Repository-Datei beseitigt alte Indexgenerationen, Zusammenfassungen oder Memory nicht automatisch; die Reaktion erfordert ausdrückliche Invalidierung und geprüften Neuaufbau unter Beweissicherung.

Voraussetzungen und Erreichbarkeit

Eine realistische Prüfung beginnt mit Inhalten, die das Team berechtigt kontrolliert: eine Fixture auf einem Test-Branch, ein synthetischer Fork, ein Test-Issue oder eine Abhängigkeits-Fixture in einem isolierten Projekt. Der Inhalt muss dann unter plausibler Aufgabe, Branch-, Dateiauswahl- und Indexkonfiguration erreichbar werden.

Schreibzugriff allein genügt nicht. Der relevante Ref muss ausgecheckt oder indexiert, der Dateityp berücksichtigt, die Passage ausgewählt und nicht abgeschnitten und der entstehende Kontext modellwirksam werden. Eine Sicherheitsauswirkung verlangt zusätzlich eine erreichbare Fähigkeit und eine versagende deterministische Kontrolle.

Offensive Perspektive auf die Repository-Aufnahme

Beauftragte Red Teams sollten kontrollierbare Inhalte realistischen Eintrittspunkten zuordnen und jede Barriere einzeln messen. Entscheidend sind die Identität mit Änderungsrecht, der aufgelöste Ref, die Auswahl durch Retrieval, der Erhalt von Autoritätslabels und die nach einer Beeinflussung tatsächlich vorhandene Fähigkeit.

Ziel ist nicht die Optimierung von Formulierungen, sondern das Auffinden unsicherer Komposition: nicht vertrauenswürdiges Repository-Material erreicht ein anweisungssensitives Modell, ein beeinflusster Vorschlag erreicht übermäßige Tools oder Daten, und Anwendungspolitik dämmt ihn nicht ein. Wiederverwendbare Prompts, schädlicher Code, Verschleierung, Persistenztechniken und Exploit-Abläufe bleiben daher außen vor.

Erfolgskette der Quellcode Prompt Injection

Nach der Beeinflussung verzweigt die Kette. Ein rein lesender Assistent erzeugt vielleicht nur Antwort oder Vorschlag. Ein anderes System kann getrennt begrenzte Dateischreibvorgänge, Shell- oder Paket-Tools, Netzwerkzugriffe, Commits, Pushes, Pull Requests, CI-Auslösung oder Merge anbieten. Keine Fähigkeit ist universell, jede bildet eine eigene Schranke.

Modellbeeinflussung ist keine Sicherheitsauswirkung. Ende-zu-Ende-Auswirkung erfordert einen vollständigen Fähigkeitspfad, eine fehlende oder versagende Policy-Entscheidung und eine reale sicherheitsrelevante Wirkung. Berichte nennen die tiefste beobachtete Schranke, statt spätere Effekte zu unterstellen.

Konkurrierende Randbedingungen

Offensive Review-Fragen

Beispielszenario: begrenzte Validierungsänderung

Der Test nutzt synthetische Daten, begrenzte Rechte und umkehrbare Wirkungen. Beeinflussung wird als Modellbefund dokumentiert; der verweigerte Fähigkeitspfad belegt Eindämmung.

Fähigkeiten, Auswirkungen und Autorisierungsgrenzen

Eine Freigabe muss an exakten unveränderlichen Diff, Ref, Aktion und Ziel gebunden sein. Ändert sich ein Parameter oder Repository-Zustand, wird neu autorisiert. Repository-Anweisungen und Modellausgabe bleiben Vorschläge an diese Kontrollebene und sind niemals Autorisierungseingaben.

Erkennung und Telemetrie

Nützliche Signale sind Plan Drift, Source-Authority Mismatch, unerwartete Refs oder unversionierte Dateien, ausgeweitete Diffs, neue Pfad- oder Zielanforderungen und Abweichungen zwischen freigegebener und ausgeführter Aktion. Telemetrie belegt die Abfolge, ohne interne Modellkausalität zu behaupten.

Prävention und sichere Architektur

1. 01
   Autorität klassifizieren

   Quelltext als Daten behandeln und unterstützte Repository-Anweisungen als eigene, unterhalb der Anwendungspolitik begrenzte Klasse führen.

2. 02
   Anweisungsquellen schützen

   Änderungsrechte an ausgewiesenen Anweisungsdateien begrenzen und Geltungsbereich sowie wirksame Präzedenz sichtbar machen.

3. 03
   Passagenprovenienz erhalten

   Repository, Ref, Commit, Pfad, Blob-Hash, Zeilenbereich, Query und Indexversion in Kontext und Logs tragen.

4. 04
   Vorgesehenen Basiszustand auflösen

   Branch und Ref bei Bedarf pinnen oder prüfen und Fork-, PR- und lokale Worktree-Inhalte isolieren, ohne Repository-Integrität mit Anweisungsautorität gleichzusetzen.

5. 05
   Kontext minimieren

   Nur aufgabenrelevante Dateien und Passagen unter den Rechten der auslösenden Identität abrufen.

6. 06
   Ausführung isolieren

   Workspace oder Container ohne ambient secrets und sensible lokale Dateien verwenden.

7. 07
   Deterministisch autorisieren

   Datei-, Pfad-, Tool-, Shell-, Paket- und Netzwerkregeln einschließlich Egress-Allowlist außerhalb des Modells erzwingen.

8. 08
   Wirkungsreiche Änderungen stufen

   Vorschlag und Review vor Mutation verlangen und Write-, Commit-, Push-, PR- und Merge-Rechte trennen.

9. 09
   Freigaben binden

   Exakten Diff, Ref, Aktion und Ziel freigeben und bei Zustandsänderung erneut prüfen.

10. 10
    Nachgelagert validieren

    Branch Protection, Code Review, CI und Security Scans als Zusatzprüfung nutzen, nicht als Prompt-Injection-Prävention.

Der Abwehrbereich ordnet diese Kontrollen in die übergreifende Architektur für Provenienz, geringste Rechte, Informationsfluss, Aktionskontrolle und Wiederherstellung ein.

Kontrollierte Sicherheitstests

Verwenden Sie synthetische Repositories, Identitäten, Secrets und Ziele, isolieren Sie die Ausführung, begrenzen Sie Rechte und halten Sie jede Wirkung umkehrbar. Variieren Sie Inhaltsklasse, Ref, Worktree-Zustand, Retrieval-Methode, Unterstützung von Anweisungsdateien und Fähigkeiten. Jede Metrik braucht einen Nenner.

Die Werte werden nicht kombiniert. Hohe Beeinflussung ohne Policy-Umgehung ist ein anderes Ergebnis als geringe Erreichbarkeit bei ungeprüfter Autorisierung.

Incident Response

Häufige Missverständnisse

Standards und Forschungskontext

OWASP LLM01:2026 klassifiziert indirekte Injection über externe Quellen. NIST definiert indirekte Prompt Injection als Prompt Injection mittels Resource Control; der separate Begriff Resource Control beschreibt die Kontrolle externer Ressourcen, die ein generatives AI-System zur Inferenzzeit verarbeitet. Das definiert den Mechanismus, nicht die Folgeauswirkung.

Microsoft behandelt Prompts, Dokumente, abgerufene Chunks, Tool-Ergebnisse und Memory-Writes als nicht vertrauenswürdig und empfiehlt Provenienz, berechtigungsbewusste Indexierung sowie Validierung bei jedem Lese- und Schreibvorgang. GitHub dokumentiert konkrete Custom-Instruction-Mechanismen und Schutzmaßnahmen für eigene Copilot-Oberflächen. Diese Produktverhalten sind Beispiele, keine universellen Berechtigungs- oder Präzedenzregeln.

Greshake et al. berichtet die praktische Umsetzbarkeit indirekter Prompt Injection gegen reale LLM-integrierte Systeme, darunter Code-Completion-Engines. Die Arbeit stützt das Bedrohungsmodell; diese Seite gibt keine Angriffstexte oder Verfahren wieder.

Häufige Fragen