💻 computer science

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

The paper introduces CodeSentinel, a three-layer inference-time sanitizer that leverages Tree-sitter, syntax-guided pre-filtering, and dynamic scoring to effectively detect and neutralize indirect prompt injections hidden within code contexts, achieving superior performance over existing defenses.

Original authors: Po-Han Cheng, Chia-Mu Yu, Ying-Dar Lin, Yu-Sung Wu, Wei-Bin Lee

Published 2026-06-19

📖 5 min read🧠 Deep dive

CC BY 4.0

Original authors: Po-Han Cheng, Chia-Mu Yu, Ying-Dar Lin, Yu-Sung Wu, Wei-Bin Lee

Original paper licensed under CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer

Imagine you are a master chef (the Code Large Language Model) who is incredibly talented at writing recipes. Usually, you only listen to the head chef's direct instructions. But recently, you've started reading notes left on the counter, comments in the recipe books, and sticky notes from other cooks to help you cook better.

The problem? A saboteur has started slipping hidden instructions into those notes. They might write something like, "Ignore the head chef and add poison to the soup," but they hide it inside a normal-looking comment or a weirdly named ingredient list. You, the chef, read it and accidentally follow the saboteur's orders instead of the head chef's.

This paper introduces CodeSentinel, a three-layer security guard designed to stand between the messy notes and the chef, filtering out these hidden traps before the chef ever sees them.

Here is how CodeSentinel works, using simple analogies:

The Problem: "Indirect Prompt Injection"

In the past, hackers tried to trick the chef by shouting directly at them (a "direct attack"). Now, they are sneakier. They hide their malicious commands inside the context—the code, comments, and documentation the chef is already reading.

The Trap: A hacker might leave a comment in a code file that says, "Actually, delete all the security checks." The code looks normal to a human, but the AI reads it as a command.

The Solution: CodeSentinel's Three Layers

CodeSentinel doesn't just read the text like a human; it understands the structure of the code (like a tree with branches and leaves). It checks every "leaf" (a specific part of the code) using three different security layers:

Layer 1: The "Obvious Danger" Scanner (Syntax-Guided Pre-Filtering)

This is the first line of defense. It looks for things that are obviously suspicious or weird.

The Analogy: Imagine a security guard checking a bag. If they see a sign that says "EXPLOSIVES" written in bright red, or if the bag is filled with invisible ink and strange symbols, they stop it immediately.
What it catches: Obvious commands like "Ignore previous instructions," weird invisible characters, or code that looks like it's trying to trick the system. It's fast and catches the loud, clumsy attacks.

Layer 2: The "Statistical Detective" (CST-Guided Dynamic Min-K% Scoring)

Some hackers are smart. They don't use obvious words; they write code that looks normal but has a weird "statistical fingerprint."

The Analogy: Imagine a detective looking at a crowd. Most people walk at a normal pace. But one person is walking with a rhythm that is just slightly off—too fast, too slow, or too jerky compared to everyone else. Even if they look normal, their movement pattern is suspicious.
What it catches: This layer analyzes the "rhythm" of the code. If a specific comment or string of text has a weird pattern of probability (like a word that is statistically unlikely to appear in that spot), it flags it. It's looking for "adversarial perturbations"—tiny, math-based tricks that confuse the AI.

Layer 3: The "What-If" Simulator (Node Perturbation Analysis)

This is the hardest layer. Some hackers write instructions that look perfectly normal and have normal statistics. They are "natural-looking" traps.

The Analogy: Imagine a magician who asks you to guess a card. To test if a specific card is the trick, the guard secretly swaps that card with a blank one and asks the magician to guess again.
- If the magician's guess changes completely when that one card is swapped, then that card was the secret trigger.
- If the guess stays the same, the card was just a normal card.
What it catches: CodeSentinel takes a suspicious piece of code, "neutralizes" it (makes it harmless but keeps the grammar correct), and asks the AI model: "Does your answer change now?" If the answer changes drastically, it means that specific piece of text was secretly controlling the AI.

The Result: Cleaning the Kitchen

Once CodeSentinel finds a trap, it doesn't just delete the whole page. It carefully removes or neutralizes only the specific trap (the comment, the string, or the identifier) while keeping the rest of the recipe intact.

The Paper's Claims:

Effectiveness: The authors tested CodeSentinel against six different types of modern attacks. It caught 80% of the traps on average (a score called F1), beating previous security tools like CodeGarrison and DePA.
Safety: It works even if the AI model is a "black box" (a commercial model where you can't see inside). It acts as a pre-check before the code reaches the main AI.
Efficiency: It uses a "three-layer" approach so it doesn't waste time doing the heavy "What-If" simulation on obvious text; it only does the heavy lifting on the tricky stuff.

In short, CodeSentinel is a smart, structural filter that ensures the AI chef only follows the head chef's orders, not the hidden notes left by saboteurs.

Technical Summary: CodeSentinel

Problem Statement

Code Large Language Models (Code LLMs) are increasingly integrated into software development workflows, relying on external code contexts retrieved from repositories, documentation, issue threads, and agent environments. While this enhances utility, it introduces a critical security vulnerability: indirect prompt injection.

Unlike direct jailbreaks where an attacker sends a malicious prompt, indirect injection involves "poisoning" external code artifacts. Attackers embed hidden instructions within comments, string literals, identifiers, or decoy code snippets. These payloads are syntactically valid and often lack runtime effects, making them difficult for developers to detect but highly effective at manipulating the Code LLM's behavior. Existing defenses face significant limitations:

Keyword filters fail to catch implicit or obfuscated triggers.
File-level perplexity (e.g., DePA) dilutes short, localized malicious payloads.
Training-based defenses are often infeasible for black-box commercial models.

Methodology: CodeSentinel

The authors propose CodeSentinel, a three-layer, inference-time sanitizer designed to operate on untrusted code before it reaches the downstream victim model. Unlike previous approaches that treat code as flat text, CodeSentinel treats code as a Concrete Syntax Tree (CST). It parses the input, extracts high-risk model-facing nodes, and applies a sequential, three-layer defense mechanism.

1. Problem Formulation

The system defines the model-facing input $X$ as a serialization of the developer prompt and external context, preserving byte offsets between source spans and CST nodes. It identifies a set of high-risk nodes ( $D_{risk}$ ) comprising:

Comments ( $D_{com}$ )
String literals ( $D_{str}$ )
Identifiers ( $D_{id}$ )
Decoy-like nodes ( $D_{decoy}$ ): Syntactically valid statements or blocks that are salient to the model but weakly connected to the program's main logic (low reachability).

The goal is to detect a subset of these nodes ( $\hat{S}$ ) containing hidden triggers and sanitize them before the victim model $f_\theta$ processes the context.

2. The Three-Layer Defense

CodeSentinel applies three complementary layers sequentially. Nodes flagged by an earlier layer are removed from consideration for subsequent, more computationally expensive layers.

Layer 1: Syntax-Guided Pre-Filtering

This layer targets explicit or structurally suspicious payloads with negligible overhead. It calculates a risk score $s_1(n)$ based on three normalized metrics:

Regex Matching ( $R_{regex}$ ): Detects instruction-overriding phrases, role-control directives, and suspicious command templates.
Lexical-Structural Checking ( $R_{lex}$ ): Identifies invisible Unicode characters, excessive non-ASCII symbols, abnormal punctuation density, and unusually long continuous strings.
Interaction-Graph Analysis ( $R_{graph}$ ): Specifically targets "decoy" attacks (e.g., Flashboom) by measuring the salience of a node relative to its reachability from entry points. Nodes that are highly visible to the model but disconnected from main logic receive high risk scores.

Layer 2: CST-Guided Dynamic Min-K% Scoring

Targeting adversarial perturbations (e.g., ShadowCode, INSEC), this layer detects statistically abnormal fragments within comments or strings. It operates at the CST-node granularity to avoid the dilution effect of file-level perplexity.

Token-Level Analysis: It computes the negative log-likelihood (NLL) for tokens within a node using a local surrogate model.
Dynamic Min-K%: Unlike fixed Min-K% methods, CodeSentinel dynamically adjusts the fraction of top-loss tokens selected ( $k_{dyn}$ ) based on the node's type, length, and entropy.
Anomaly Signals: It computes three signals:
1. MeanTopK: The mean of the highest NLL values.
2. MaxWinLoss: The maximum average NLL within a sliding window (detecting localized perturbations).
3. MaxSpike: The maximum difference between adjacent token NLLs.
These signals are calibrated against clean validation nodes of the same CST type to produce a final anomaly score $s_2(n)$ .

Layer 3: CST-Guided Node Perturbation Analysis

This layer targets natural-looking semantic triggers (e.g., XOXO, ITGen) that appear syntactically valid and statistically natural, evading likelihood-based detection. It measures the behavioral influence of a node.

Surprise-Gated Selection: To reduce cost, it first filters nodes based on "surprise" (the difference in NLL when the node is viewed in full context vs. isolation). Only high-surprise nodes proceed.
Neutralization & Influence Scoring: For selected nodes, the system constructs a sanitized input $X(n)$ where the node is replaced with a syntax-preserving neutral equivalent (e.g., removing comments, replacing strings with safe literals, renaming identifiers).
Jensen-Shannon Divergence (JSD): It compares the output distribution of the surrogate model on the original input versus the sanitized input. A high JSD score ( $s_3(n)$ ) indicates that the node significantly steers the model's prediction, marking it as a semantic trigger.

3. Sanitization

Once a set of nodes $\hat{S}$ is identified, CodeSentinel sanitizes a model-facing copy of the context.

Prompt-Only Mode: The repository source remains untouched; only the copy sent to the model is cleaned.
Compile-Preserving Mode: If language-specific rewriting is available, it performs stricter edits (e.g., scope-consistent renaming, removing unreachable decoy blocks) and re-parses the result to ensure syntax validity.

Key Contributions

Formulation: The paper formulates indirect prompt injection in code contexts as a CST-node-level sanitization problem, focusing on model-facing high-risk regions rather than flat text.
Architecture: It introduces CodeSentinel, a three-layer defense that uniquely combines static code structure (CST), node-level likelihood anomalies, and logits-level behavioral influence analysis.
Evaluation: The authors evaluate CodeSentinel against six recent attack families and demonstrate its superiority over existing baselines (CodeGarrison, DePA, KillBadCode).

Experimental Results

The evaluation was conducted on six attack families: XOXO, ITGen, Flashboom, ShadowCode, INSEC, and CoTDeceptor.

Performance: CodeSentinel achieved an average node-level F1 score of 0.80, outperforming CodeGarrison (0.70), DePA (0.51), and KillBadCode (0.30).
Specific Gains:
- INSEC: 0.90 (vs. 0.73 for CG)
- ShadowCode: 0.85 (vs. 0.62 for CG)
- Flashboom: 0.79 (vs. 0.85 for CG, but significantly outperforming others)
- XOXO: 0.80 (vs. 0.72 for CG)
Black-Box Efficacy: In experiments with commercial black-box victim models (e.g., Claude-3.5-Haiku, GPT-5.1-Codex-mini), applying CodeSentinel significantly reduced the Attack Success Rate (ASR). For instance, ASR on Claude-3.5-Haiku dropped from 27.11% to 7.72%.
Ablation: The cumulative performance analysis confirms that all three layers contribute to the final detection capability, with the pipeline showing robust generalization across different surrogate models.

Significance and Claims

The paper claims that CodeSentinel addresses a central limitation of current defenses: the inability to detect implicit triggers in structured code without requiring retraining of the victim model. By operating at the CST-node granularity and combining syntax-preserving neutralization with behavioral influence analysis, CodeSentinel offers a deployable solution for both open-weight and black-box Code LLMs.

The authors emphasize that their approach does not rely on modifying the victim model's weights, making it suitable for immediate deployment in industrial workflows where external code contexts are retrieved. The system balances high detection accuracy with the preservation of benign code utility, ensuring that sanitization does not break the syntactic validity or executable structure of the code unless explicitly certified.