💻 computer science

CodeSentinel: A Three-Layer Defense Against Indirect Prompt Injection in Code Contexts

Das Paper stellt CodeSentinel vor, einen dreistufigen Inferenzzeit-Sanitizer, der Tree-sitter, syntaktisch geführte Vorfilterung und dynamisches Scoring nutzt, um indirekte Prompt-Injektionen, die in Code-Kontexten verborgen sind, effektiv zu erkennen und zu neutralisieren, wobei eine überlegene Leistung gegenüber bestehenden Abwehrmechanismen erzielt wird.

Ursprüngliche Autoren: Po-Han Cheng, Chia-Mu Yu, Ying-Dar Lin, Yu-Sung Wu, Wei-Bin Lee

Veröffentlicht 2026-06-19

📖 5 Min. Lesezeit🧠 Tiefgang

CC BY 4.0

Ursprüngliche Autoren: Po-Han Cheng, Chia-Mu Yu, Ying-Dar Lin, Yu-Sung Wu, Wei-Bin Lee

Originalarbeit lizenziert unter CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Dies ist eine KI-generierte Erklärung des untenstehenden Papers. Sie wurde nicht von den Autoren verfasst oder gebilligt. Für technische Genauigkeit konsultieren Sie das Originalpaper. Vollständigen Haftungsausschluss lesen

Stellen Sie sich vor, Sie sind ein Meisterkoch (das Code Large Language Model), der unglaublich talentiert darin ist, Rezepte zu schreiben. Normalerweise hören Sie nur auf die direkten Anweisungen des Chefkochs. Aber vor kurzem haben Sie begonnen, Notizen auf der Arbeitsplatte, Kommentare in den Rezeptbüchern und Klebezettel von anderen Köchen zu lesen, um besser kochen zu können.

Das Problem? Ein Saboteur hat begonnen, versteckte Anweisungen in diese Notizen einzuschleusen. Er könnte zum Beispiel schreiben: "Ignoriere den Chefkoch und gib Gift in die Suppe", aber er versteckt dies in einem normalerweise aussehenden Kommentar oder einer seltsam benannten Zutatenliste. Sie, der Koch, lesen es und folgen versehentlich den Befehlen des Saboteurs anstatt denen des Chefkochs.

Dieses Paper stellt CodeSentinel vor, einen dreistufigen Sicherheitswächter, der zwischen den unordentlichen Notizen und dem Koch steht und diese versteckten Fallen herausfiltert, bevor der Koch sie überhaupt sieht.

So funktioniert CodeSentinel, unter Verwendung einfacher Analogien:

Das Problem: „Indirekte Prompt-Injection“

In der Vergangenheit versuchten Hacker, den Koch zu täuschen, indem sie ihn direkt anschrien (ein „direkter Angriff“). Jetzt sind sie hinterlistiger. Sie verstecken die bösartigen Befehle innerhalb des Kontexts – im Code, in Kommentaren und in der Dokumentation, die der Koch bereits liest.

Die Falle: Ein Hacker könnte einen Kommentar in einer Code-Datei hinterlassen, der besagt: "Lösche eigentlich alle Sicherheitsprüfungen." Der Code sieht für einen Menschen normal aus, aber die KI liest ihn als Befehl.

Die Lösung: CodeSentinels drei Schichten

CodeSentinel liest den Text nicht einfach wie ein Mensch; es versteht die Struktur des Codes (wie einen Baum mit Ästen und Blättern). Es überprüft jedes „Blatt“ (einen spezifischen Teil des Codes) mit drei verschiedenen Sicherheitsschichten:

Schicht 1: Der Scanner für „Offensichtliche Gefahren“ (Syntax-gesteuerte Vorfilterung)

Dies ist die erste Verteidigungslinie. Sie sucht nach Dingen, die offensichtlich verdächtig oder seltsam sind.

Die Analogie: Stellen Sie sich einen Sicherheitswachmann vor, der eine Tasche kontrolliert. Wenn er ein Schild sieht, auf dem in leuchtendem Rot „EXPLOSIVES“ steht, oder wenn die Tasche mit unsichtbarer Tinte und seltsamen Symbolen gefüllt ist, stoppt er es sofort.
Was es abfängt: Offensichtliche Befehle wie „Ignoriere vorherige Anweisungen“, seltsame unsichtbare Zeichen oder Code, der versucht, das System zu täuschen. Es ist schnell und fängt die lauten, tollpatschigen Angriffe ab.

Schicht 2: Der „Statistische Detektiv“ (CST-gesteuerte dynamische Min-K%-Bewertung)

Manche Hacker sind klug. Sie verwenden keine offensichtlichen Wörter; sie schreiben Code, der normal aussieht, aber einen seltsamen „statistischen Fingerabdruck“ hat.

Die Analogie: Stellen Sie sich einen Detektiv vor, der eine Menge beobachtet. Die meisten Menschen gehen in einem normalen Tempo. Aber eine Person geht mit einem Rhythmus, der nur ein kleines bisschen daneben liegt – zu schnell, zu langsam oder zu abgehackt im Vergleich zu allen anderen. Selbst wenn sie normal aussieht, ist ihr Bewegungsmuster verdächtig.
Was es abfängt: Diese Schicht analyst den „Rhythmus“ des Codes. Wenn ein bestimmter Kommentar oder eine Zeichenkette eine seltsame Wahrscheinlichkeitsverteilung aufweist (wie ein Wort, das statistisch gesehen unwahrscheinlich an dieser Stelle erscheinen würde), markiert es dies. Es sucht nach „adversariellen Perturbationen“ – winzigen, mathematischen Tricks, die die KI verwirren.

Schicht 3: Der „Was-wäre-wenn“-Simulator (Knoten-Perturbationsanalyse)

Dies ist die schwierigste Schicht. Manche Hacker schreiben Anweisungen, die vollkommen normal aussehen und normale Statistiken aufweisen. Sie sind „natürlich wirkende“ Fallen.

Die Analogie: Stellen Sie sich einen Magier vor, der Sie bittet, eine Karte zu erraten. Um zu testen, ob eine bestimmte Karte der Trick ist, tauscht der Wachmann diese Karte heimlich gegen eine leere Karte aus und bittet den Magier, erneut zu raten.
- Wenn sich die Antwort des Magiers vollständig ändert, wenn diese eine Karte ausgetauscht wird, dann war diese Karte der geheime Auslöser.
- Wenn die Antwort gleich bleibt, war die Karte nur eine normale Karte.
Was es abfängt: CodeSentinel nimmt ein verdächtiges Stück Code, „neutralisiert“ es (macht es harmlos, behält aber die Grammatik bei) und fragt das KI-Modell: "Ändert sich deine Antwort jetzt?" Wenn sich die Antwort drastisch ändert, bedeutet dies, dass dieser spezifische Textabschnitt heimlich die KI gesteuert hat.

Das Ergebnis: Die Küche reinigen

Sobald CodeSentinel eine Falle findet, löscht es nicht einfach die ganze Seite. Es entfernt oder neutralisiert sorgfältig nur die spezifische Falle (den Kommentar, die Zeichenkette oder den Bezeichner), während der Rest des Rezepts intakt bleibt.

Die Behauptungen des Papers:

Effektivität: Die Autoren haben CodeSentinel gegen sechs verschiedene Arten moderner Angriffe getestet. Es hat im Durchschnitt 80 % der Fallen abgefangen (ein Score namens F1-Wert) und damit andere Sicherheitstools wie CodeGarrison und DePA geschlagen.
Sicherheit: Es funktioniert selbst dann, wenn das KI-Modell eine „Black Box“ ist (ein kommerzielles Modell, in das man nicht hineinsehen kann). Es fungt als Vorprüfung, bevor der Code die Haupt-KI erreicht.
Effizienz: Es verwendet einen „Drei-Schichten-Ansatz“, damit es keine Zeit mit der schweren „Was-wäre-wenn“-Simulation bei offensichtlichem Text verschwendet; es führt die schwere Arbeit nur bei den schwierigen Teilen aus.

Kurz gesagt: CodeSentinel ist ein intelligenter, struktureller Filter, der sicherstellt, dass der KI-Koch nur den Anweisungen des Chefkochs folgt und nicht den versteckten Notizen der Saboteure.

Technisches Resümee: CodeSentinel

Problemstellung

Code-Large-Language-Models (Code LLMs) werden zunehmend in Softwareentwicklungs-Workflows integriert und verlassen sich dabei auf externe Code-Kontexte, die aus Repositories, Dokumentationen, Issue-Threads und Agenten-Umgebungen abgerufen werden. Während dies den Nutzen erhöht, führt es eine kritische Sicherheitslücke ein: indirekte Prompt-Injection.

Im Gegensatz zu direkten Jailbreaks, bei denen ein Angreifer einen bösartigen Prompt sendet, beinhaltet die indirekte Injection das „Vergiften“ externer Code-Artefakte. Angreifer betten versteckte Anweisungen in Kommentaren, String-Literalen, Bezeichnern oder Schein-Code-Snippets ein. Diese Payloads sind syntaktisch korrekt und oft ohne Auswirkungen auf die Laufzeit, was sie für Entwickler schwer detektierbar, aber hocheffektiv bei der Manipulation des Code-LLM-Verhaltens macht. Bestehende Abwehrmechanismen weisen signifikante Einschränkungen auf:

Keyword-Filter scheitern an impliziten oder verschleierten Triggern.
Dateiebasiert Perplexity (z. B. DePA) verwässert kurze, lokalisierte bösartige Payloads.
Trainingsbasierte Abwehrmechanismen sind oft für Black-Box-Kommerzielle Modelle nicht praktikabel.

Methodik: CodeSentinel

Die Autoren schlagen CodeSentinel vor, einen dreistufigen, Inference-Zeit-Sanitizer, der darauf ausgelegt ist, unvertrauenswürdigen Code zu bereinigen, bevor dieser das nachgeschaltete Opfermodell erreicht. Im Gegensatz zu bisherigen Ansätzen, die Code als flachen Text behandeln, behandelt CodeSentinel Code als einen Concrete Syntax Tree (CST). Es parst den Input, extrahiert hochriskante, dem Modell zugewandte Knoten und wendet einen sequenziellen, dreistufigen Abwehrmechanismus an.

1. Problemformulierung

Das System definiert den dem Modell zugewandten Input $X$ als eine Serialisierung des Entwickler-Prompts und des externen Kontexts, wobei die Byte-Offsets zwischen den Quellbereichen und den CST-Knoten erhalten bleiben. Es identifiziert eine Menge hochriskanter Knoten ( $D_{risk}$ ), bestehend aus:

Kommentaren ( $D_{com}$ )
String-Literalen ( $D_{str}$ )
Bezeichnern ( $D_{id}$ )
Schein-ähnlichen Knoten ( $D_{decoy}$ ): Syntaktisch valide Anweisungen oder Blöcke, die für das Modell salient sind, aber schwach mit der Hauptlogik des Programms verbunden sind (geringe Erreichbarkeit).

Das Ziel ist es, eine Teilmenge dieser Knoten ( $\hat{S}$ ) zu identifizieren, die versteckte Trigger enthalten, und diese zu bereinigen, bevor das Opfermodell $f_\theta$ den Kontext verarbeitet.

2. Die dreistufige Verteidigung

CodeSentinel wendet drei komplementäre Schichten sequenziell an. Knoten, die von einer früheren Schicht als riskant eingestuft wurden, werden für die nachfolgenden, rechenintensiveren Schichten nicht mehr berücksichtigt.

Schicht 1: Syntax-gestützte Vorfilterung

Diese Schicht zielt auf explizite oder strukturell verdächtige Payloads mit vernachlässigbarem Overhead ab. Sie berechnet einen Risiko-Score $s_1(n)$ basierend auf drei normalisierten Metriken:

Regex-Matching ( $R_{regex}$ ): Erkennt Phrasen zur Anweisungsüberschreibung, Rollenkontroll-Direktiven und verdächtige Befehlsvorlagen.
Lexikalisch-strukturelle Prüfung ( $R_{lex}$ ): Identifiziert unsichtbare Unicode-Zeichen, übermäßige Nicht-ASCII-Symbole, abnormale Interpunktionsdichte und ungewöhnlich lange kontinuierliche Zeichenketten.
Interaktionsgraph-Analyse ( $R_{graph}$ ): Zielt spezifisch auf „Decoy“-Angriffe (z. B. Flashboom) ab, indem sie die Salienz eines Knotens im Verhältnis zu seiner Erreichbarkeit von den Einstiegspunkten misst. Knoten, die für das Modell hoch sichtbar, aber von der Hauptlogik entkoppelt sind, erhalten hohe Risiko-Scores.

Schicht 2: CST-gestützte dynamische Min-K% Scoring

Diese Schicht zielt auf adversarielle Perturbationen (z. B. ShadowCode, INSEC) ab und erkennt statistisch abnormale Fragmente innerhalb von Kommentaren oder Strings. Sie operiert auf der CST-Knoten-Granularität, um den Verwässerungseffekt der dateibasierten Perplexity zu vermeiden.

Token-Level-Analyse: Sie berechnet die negative Log-Likelihood (NLL) für Token innerhalb eines Knotens unter Verwendung eines lokalen Surrogate-Modells.
Dynamisches Min-K%: Im Gegensatz zu festen Min-K%-Methoden passt CodeSentinel den Bruchteil der ausgewählten Top-Loss-Token ( $k_{dyn}$ ) dynamisch basierend auf dem Typ, der Länge und der Entropie des Knotens an.
Anomalie-Signale: Es berechnet drei Signale:
1. MeanTopK: Der Mittelwert der höchsten NLL-Werte.
2. MaxWinLoss: Der maximale durchschnittliche NLL innerhalb eines gleitenden Fensters (detektiert lokalisierte Perturbationen).
3. MaxSpike: Die maximale Differenz zwischen benachbarten Token-NLLs.
Diese Signale werden gegen saubere Validierungsknoten desselben CST-Typs kalibriert, um einen finalen Anomalie-Score $s_2(n)$ zu erzeugen.

Schicht 3: CST-gestützte Knoten-Perturbationsanalyse

Diese Schicht zielt auf natürlich wirkende semantische Trigger (z. B. XOXO, ITGen) ab, die syntaktisch korrekt und statistisch natürlich erscheinen und dadurch likelihood-basierte Detektion umgehen. Sie misst den behavioralen Einfluss eines Knotens.

Surprise-Gated Selection: Um die Kosten zu senken, filtert sie zuerst Knoten basierend auf „Überraschung“ (der Differenz in der NLL, wenn der Knoten im vollen Kontext vs. in Isolation betrachtet wird). Nur Knoten mit hoher Überraschung werden weiterverarbeitet.
Neutralisierung & Einfluss-Scoring: Für ausgewählte Knoten konstruiert das System einen bereinigten Input $X(n)$ , bei dem der Knoten durch ein syntaxerhaltendes neutrales Äquivalent ersetzt wird (z. B. Entfernen von Kommentaren, Ersetzen von Strings durch sichere Literale, Umbenennen von Bezeichnern).
Jensen-Shannon-Divergenz (JSD): Es vergleicht die Output-Verteilung des Surrogate-Modells auf dem ursprünglichen Input gegenüber dem bereinigten Input. Ein hoher JSD-Score ( $s_3(n)$ ) deutet darauf hin, dass der Knoten die Vorhersage des Modells signifikant steuert, was ihn als semantischen Trigger markiert.

3. Bereinigung (Sanitization)

Sobald eine Menge von Knoten $\hat{S}$ identifiziert wurde, bereinigt CodeSentinel eine modell-zugewandte Kopie des Kontexts.

Prompt-Only-Modus: Das Repository-Original bleibt unberührt; nur die an das Modell gesendete Kopie wird bereinigt.
Compile-Preserving-Modus: Falls sprachspezifische Umschreibungen verfügbar sind, führt das System strengere Edits durch (z. B. kontextkonsistente Umbenennung, Entfernen unerreichbarer Decoy-Blöcke) und parst das Ergebnis neu, um die syntaktische Validität sicherzustellen.

Wichtigste Beiträge

Formulierung: Die Arbeit formuliert indirekte Prompt-Injection in Code-Kontexten als ein CST-Knoten-Ebene-Sanitization-Problem, das sich auf modell-zugewandte Hochrisiko-Regionen konzentriert statt auf flachen Text.
Architektur: Sie führt CodeSentinel ein, einen dreistufigen Verteidigungsmechanismus, der die statische Code-Struktur (CST), Anomalien der Knoten-Likelihood und die Analyse des behavioralen Einflusses auf Logit-Ebene einzigartig kombiniert.
Evaluierung: Die Autoren evaluieren CodeSentinel gegen sechs aktuelle Angriffsfamilien und demonstrieren dessen Überlegenheit gegenüber bestehenden Baselines (CodeGarrison, DePA, KillBadCode).

Experimentelle Ergebnisse

Die Evaluierung wurde an sechs Angriffsfamilien durchgeführt: XOXO, ITGen, Flashboom, ShadowCode, INSEC und CoTDeceptor.

Leistung: CodeSentinel erreichte einen durchschnittlichen Knoten-Ebene F1-Score von 0,80 und übertraf damit CodeGarrison (0,70), DePA (0,51) und KillBadCode (0,30).
Spezifische Gewinne:
- INSEC: 0,90 (gegenüber 0,73 für CG)
- ShadowCode: 0,85 (gegenüber 0,62 für CG)
- Flashboom: 0,79 (gegenüber 0,85 für CG, aber signifikant besser als andere)
- XOXO: 0,80 (gegenüber 0,72 für CG)
Black-Box-Effektivität: In Experimenten mit kommerziellen Black-Box-Opfermodellen (z. B. Claude-3.5-Haiku, GPT-5.1-Codex-mini) reduzierte die Anwendung von CodeSentinel die Attack Success Rate (ASR) signifikant. So sank die ASR bei Claude-3.5-Haiku von 27,11 % auf 7,72 %.
Ablation: Die kumulative Leistungsanalyse bestätigt, dass alle drei Schichten zur finalen Detektionsfähigkeit beitragen, wobei die Pipeline eine robuste Generalisierung über verschiedene Surrogate-Modelle hinweg zeigt.

Bedeutung und Ansprüche

Die Arbeit behauptet, dass CodeSentinel ein zentrales Problem aktueller Abwehrmechanismen adressiert: die Unfähigkeit, implizite Trigger in strukturiertem Code zu erkennen, ohne das Opfermodell neu trainieren zu müssen. Durch die Arbeit auf der CST-Knoten-Granularität und die Kombination von syntaxerhaltender Neutralisierung mit behavioraler Einflussanalyse bietet CodeSentinel eine einsetzbare Lösung für sowohl Open-Weight- als auch Black-Box-Code-LLMs.

Die Autoren betonen, dass ihr Ansatz nicht auf der Modifikation der Gewichte des Opfermodells basiert, was eine sofortige Implementierung in industriellen Workflows ermöglicht, in denen externe Code-Kontexte abgerufen werden. Das System balanciert eine hohe Detektionsgenauigkeit mit der Bewahrung der benignen Code-Nützlichkeit, um sicherzustellen, dass die Bereinigung weder die syntaktische Validität noch die ausführbare Struktur des Codes beeinträchtigt, sofern dies nicht explizit zertifiziert ist.