Practical and Effective Code Watermarking for Large Language Models
Authors: Zhimeng Guo
Minhao Cheng
Venue: NeurIPS 2025 poster ()
Keywords: Large Language Model
LLM Watermarking
Code Watermarking
Primary area: deep_learning
TL;DR: We propose a novel code watermarking framework that learn from Abstract Syntax Trees of code to identify where and how to insert watermarks.

Abstract: The rapid advancement of Large Language Models (LLMs) in code generation has raised significant attribution and intellectual property concerns. Code watermarking offers a potential solution but faces unique challenges due to programming languages' strict syntactic constraints and semantic requirements.
To address these challenges, we introduce ACW (AST-guided Code Watermarking), a novel adaptive framework that leverages Abstract Syntax Tree (AST) analysis during training to learn watermark embedding strategies. Our framework identifies substitutable code components and strategically biases token selections to embed watermarks. We also propose a novel sampling scheme that distributes tokens between green/red lists according to semantic context, ensuring statistical distinguishability while preserving code functionality. Extensive experiments demonstrate that ACW achieves a significant improvement in watermark detection accuracy compared to existing methods, with negligible impact on code functionality. This adaptive framework offers a promising solution for effective and practical code watermarking in the age of LLMs. Our code is available at: https://github.com/TimeLovercc/code-watermark.

Practical and Effective Code Watermarking for Large Language Models
Zhimeng Guo The Pennsylvania State University z2g51070psu.edi edu
Minhao Cheng
The Pennsylvania State University
rmc71490psu.
Abstract
The rapid advancement of Large Language Models (LLMs) in code generation has raised significant attribution and intellectual property concerns. Code wa- termarking offers potential solution but faces unique challenges due pro- gramming languages' strict syntactic constraints and semantic requirements. To address these challenges, we introduce ACW (AST-guided Code Watermarking), novel adaptive framework that leverages Abstract Syntax Tree (AST) analysis during training to learn watermark embedding strategies. Our framework iden- tifies substitutable code components and strategically biases token selections to embed watermarks. We also propose novel sampling scheme that distributes tokens between green/red lists according to semantic context, ensuring statisti- cal distinguishability while preserving code functionality. Extensive experiments demonstrate that ACW achieves significant improvement in watermark detec- tion accuracy compared to existing methods, with negligible impact on code functionality. This adaptive framework offers promising solution for effective and practical code watermarking the age of LLMs. Our code is available at:
http:/wwwww...mmemeeeeee//eeaaae waw.oeeerrreeoooooeeetteeee watermark
Introduction
The remarkable code generation capabilities of recent Large Language Models (LLMs) II [ 21 10
13 [7] have fundamentally transformed software development, enabling the synthesis complex, human-like code across diverse programming languages and heralding new era in automated software development. However, this transformative technology introduces critical challenges concerning code attribution, ownership verification, and the protection of intellectual property [35 (5).
The increasing sophistication of L.L--generaed code has blurred the lines with human-written code, significantly complicating the tracking of code provenance and the establishment of authorship (19).
To address these challenges, code watermarking, the process of embedding imperceptible yet de- tectable patterns to verify code origin, has emerged as vital strategy for intellectual property protection (35). Traditional code watermarking approaches [32] typically operate on completed code, applying predefined transformation patterns to embed identifiers. These methods often require access to the complete generation context and rely on limited transformation rules, making the resulting watermarks potentially vulnerable to detection and removal. While recent work has explored on the- fly watermarking for LLM --M-eeerrated text [13,, extending these techniques from natural language to programming languages presents significant hurdles. Unlike natural language, where variations in word choice and sentence structure are often permissible, code modifications are severely restricted by syntax, type systems, and the fundamental imperative preserve program semanties.
Recent research has explored techniques like entropy-based methods and the utilization of variable type information to embed watermarks while maintaining type safety [.. However, significant limitation these approaches lies in their detection phase, which often necessitates access to the
39th Conference on Neural Information Processing Systems (NcurIPS 2025).

---

original LLM or the complete generation sequence to compute crucial metrics such as entropy. This requirement severely restricts their practical upplicability in real-world scenarios. This limitation underscores a fundamental question for code watermarking design: How can we create an effective watermarking scheme that achieves good statistical distinguishability and preserves code functioonality without requiring privileged access to the original L.M,, complete token sequences, or specific model parameters? ? For practical deployment, an ideal solution would depend solely on the code snippet itself, as access to the generation context is typically unavailable.
To overcome this challenge, we posit that the key solution lies in developing an intelligent watermark- ing model equipped with inherent programming language understanding. Such a model can identify code locations where safe alterations are possible and determine which token modifications will main- tain functionality. We identify positions offering multiple valid token alternatives as prime candidates for watermark embedding. Based on this insight, we introduce our approach, ACW (AST-guided Code Watermarking), that leverages Abstract Syntax Tree (AST) analysis during training to learn semantically equivalent code expressions and recognize these adaptable positions. By representing code hierarchical tree structures that capture syntactic and semantic relationships while abstracting away superficial details, ASTs enable modifications that yield semantically equivalent code with different syntactic expressions, providing natural opportunities for watermark embedding without compromising functionality. We quantify the feasibility of watermarking at these positions using branching entropy (14) and train our model to predict high branching entropy positions as optimal embedding locations. Subsequently, we introduce a novel sampling scheme that strategically allocates tokens between "green" (preferred) and "red" (avoided) lists based semantic information, prevent- ing the inadvertent exclusion of all semantically valid tokens. During generation, L.LM is biased to preferentially select tokens from green list. For watermark detection, we employ statistical test that measures the ratio of green tokens within generated code snippet (15). Our results demonstrate that this approach achieves close or superior performance methods that rely on privileged information.
The main contributions of this paper are: (i) We propose ACW, a novel framework that enables practical code watermarking without requiring access to the original LLM or generation prompts during detection. (ii) We develop an AST AST-guided approach to identify equivalent code expressions and quantify the feasibility of watermarking, coupled with parameterized model that enables efficient on- the-fly watermark embedding. (iii) We introduce a logits- Logits--uided sampling scheme that preserves code functionality while ensuring reliable statistical watermark detection. (iv) Comprehensive evaluations demonstrate that ACW achieves superior performance to baseline methods.
2
Related Works
LLM Watermarking.
As L.LMs have demonstrated increasingly sophisticated content generation
capabilities 21 10. watermarking techniques have become essential for content verification and
attribution [35 28, 30). Traditional approaches either modify the generated text through predefined
rules (2) or employ secondary language models for watermark insertion (33]. More recent approaches
focus on embedding watermarks directly into tokens during sampling process by modifying logits or altering the sampling procedure [15]
18 4 A notable example is the green-red watermarking scheme 15). which partitions vocabulary tokens into green and red lists and biases selection toward green tokens during generation, enabling watermark detection through statistical testing of token distributions. Additionally, several studies investigate the robustness of watermarks (4]. Despite these advancements, existing methods often face challenges in maintaining watermark detection under low-entropy inputs, which are common in structured tasks such as code generation 19
Code Watermarking, Code watermarking imposes unique challenges due to programming lan- guages' strict syntactic and semantic requirements. Traditional methods focus on watermarking generated code (23) which often alter code format, such as introducing inconspicuous changes
in indentation, whitespace, or comments [1] 27 31 20 Others manipulate lexical or syntactic elements, such as renaming variables or restructuring control flow to embed watermarks (4]. Recent approaches have explored watermarking code generated by LLMs by leveraging entropy to iden- tify watermarking positions [19]. For example, some techniques use token entropy distributions to guide watermark insertion 22 19, while others propose using type predictor to encourage the predicted class probability 99. However, these techniques typically require privileged access to LLM
parameters, generation probabilities, original prompts, limiting their practical deployment.
2

---

Threat model. We frame practical code watermarking as a three-stage protocol involving the LLM provider, user, and detector. this protocol, only the watermarking function (either a random number generator or a model) and the watermark key are shared between the provider and detector, while specific details about prompts and I.LM parameters remain private [88] In the Generation Stage, the LLM provider needs to generate watermarked code. During the Distribution Stage, users may alter the code through changes like paraphrasing. Finally, in the Detection Stage, the detector verifies the code's origin using only the watermarking function and the provided code snippet, without access to generation history, original prompts, or model configurations.
The Code Watermarking Problem
Green-red watermarking scheme [13] provides foundational framework for embedding detectable signals in -egeerrte content. Formally, let V denote the vocabulary of the language model with size V For an input prompt with M tokens x = fx("), (z())
and a generated code sequence = {s(2), s(2), 8 g(T) where x((m), s(t) E V, we denote the generated sequence at time l as 3 (1:1)
{s(1) ..... J')). This scheme employs a pseudorandom watermarking function &: : V + Py that maps secret key & E K. and a context window of preceding tokens to partition of vocabulary V, where Py is the set of all possible partitions of V. At each generation timestep i, given the context window of e preceding tokens s(t-cit) and secret key h. & produces:
(G R(0) = E(Ki, 8 ((t=c:))
where G is green list with size |G >|V| and R(*) is red list such that G U (()) = V and
G n R(t) 0. During the generation, LLM computes logits ((t) IR over V at time t + 1. To
embed the watermark, the partition (G ((( generated by watermark function & is used to bias the next token's 's selection by adding a value d to the logits of tokens belonging the green list:
(0)
+ Ō
if Uj E GLO
(2)
if E R(O)
This logit biasing increases the sampling probability of green tokens, resulting in a watermarked code sequence 8 = { ,( s(T')), where g(t) E V and T' may differ from T.
For watermark detection, detector with access to the shared watermarking function can reconstruct the green and red token lists for each position in the generated code. The presence of a watermark is then statistically evaluated using propprrpootion z-test:
1= 1[3(0 E TT
(T'((1-))
which compares the observed proportion of green tokens the generated code against the expected proportion under the null hypothesis that no watermark is present. A sufficiently large positive value leads to the rejection of the null hypothesis, indicating the likely presence of a watermark.
However, directly applying this green-red watermarking scheme from the natural language domain to code domain introduces two fundamental challenges, as illustrated in Figure D
Constrained Watermark Placement. Emhedding a watermark within code, formal language with strict syntax, requires identifying segments with multiple semantically and syntactically valid alternatives. This can be conceptualized as traversing tree during code generation, where each node represents potential token choice. Watermarking opportunities arise when multiple valid paths exist, allowing the selection of specific paths to encode information without compromising the program's 's functionality. Where valid syntactic and semantic paths are constrained, the language model typically exhibits low entropy, frequently resulting in a determiteriiiiitcc single token selection. Attempting to insert watermarks in such low- low-entropy regions risks introducing syntax errors or altering the intended program behavior. Consider the following simplified example:
Challenge 1:
for (i=0;iknn, i++) sum += array [i]
Here, the token at the red position "Y" is highly constrained by the preceding syntax, accepting only a limited set of valid tokens. Conversely, the token at the blue position "sum" represents more flexible
3

---

Motivating Example
Training
Generation
def calculate_dd ba diconntipricc,, (s_nember);
(wett Hear
if is_ re_rerrrrr True:
AST
WPN
return prace
return price
price
Gode
Code Verners
Logan
Chellenge
Challange 2
nightms
Corbod
Price
Postton: def
Position: True
sampling
Must exacity "det" atterative forms
price
Swish Hess
WPN
Lagta Hoat
Not piant
all vilid red
Detection
LLM
Prisaiiity
LUM Loges
Selectively plant watermariss Make vocabulary parlltioning semartically aware.
point:
WPN
Figure I: A motivating example illustrating the challenges of designing an effective code watermarking method, and an overview our three-stage AST-guided watermarking framework. Note that AST only used for training; after training, the WPN model directly handles watermark generation and detection.
choice, where multiple semantically equivalent variable names (e-g.. "sum", "total", "result") "") could be used without affecting the program's 's logic. An effective watermarking strategy should prioritize the identification and utilization of these flexible positions, as they provide natural avenues for embedding watermarks. In contrast, strict syntactic elements like parentheses semicolons offer minimal degrees of freedom for watermark insertion and should generally be avoided.
Semantic Constraints of Vocabulary Partitioning. Existing Green-Red water- marking schemes typically employ a random partitioning of the vocabulary into green (preferred) and red (avoided) token sets. This approach disregards the inherent semantic constraint within a programming language, potentially leading to scenarios where all semantically valid next tokens are placed in the red list. Consider generating a loop in Python, where both for and while are semantically valid options. A random token partitioning approach could inadvertently place both for and while in red list, leaving only semantically inappropriate tokens like if, try, or def in the green list. If the language model is then biased to select from the green list for watermarking, it would be unable to generate a valid loop construct at all. Conversely, placing both for and while in the green list introduces different problem: the resulting watermarked code distribution becomes statistically indistinguishable from unwatermarked code, where both loop constructs are naturally utilized. Effective watermark detection relies on maintaining a statistically significant difference between the distributions of watermarked and unwatermarked code.
Challenge 2:
4 AST-Guided Watermarking
4.1 Framework Overview
To address the core challenge of code watermarking, our AST-Guided Watermarking framework introduces model with learned programming language priors. This model identifies code locations where alterations can be safely made without compromising functionality, Our proposed method, ACW, integrates plug-and-play Watermark Partitioning Network (WPN) with logits-guided sam- pling mechanism. The WPN employs transformer- based architecture to dynamically generate logits for green-red red token partitioning and determine watermark placement based on minimal contextual information. For the training of WPN, we utilize Abstract Syntax Tree (AST) analysis to identify code positions offering multiple valid token alternatives. We then quantify their watermarking suit- ability using branching entropy, which guides WPN to predict optimal insertion points. Furthermore, to ensure sufficient statistical distinguishability, we propose logits-guided sampling scheme that strategically combines meaningful code structure and controlled randomness, achieving an improved balance between code utility and watermark detectability. Our framework is depicted in Figure []
4.2 Watermark Partitioning Network
WPN forms the core of our method, intelligently determining both watermark positions and token choices. Through its dual-head architecture, the network produces two outputs: a Logits head that provides logits predictions I, (distinct from L.M logits I) used to partition vocabulary into green and red tokens, and Switch head 9p that identifies positions for watermark insertion.

---

Instead of using pseudorandom partition function & that directly maps the context window and key vocabulary partitions. we implement & through our WPN and logits-guides sampling scheme. Our approach extends the watermarking function in Equation through two-step process:
pps Up WPN(s(t-G.))
(4)
(G,, = sample((p..)) k),,
(5)
where the logits output i, E RI provides scores over the vocabulary for token partitioning. and the switch output Dp [0, 1J indicates the probability of watermark insertion the current position. This probability is then compared against a threshold a to make a binary decision regarding watermark embedding. By learning dynamic partitioning decisions while maintaining the standard green-red watermarking pipeline, the WPN model serves as a practical plug-and-play solution that requires no additional input beyond the green-red watermarking scheme in [15]
4.3 AST-Guided Training
To effectively train the Watermark Partitioning Network (WPN) model, we begin by generating diverse and semantically equivalent code variations. We first represent code snippets from a dataset as Abstract Syntax Trees (ASTs) because ASTs capture the essential logical relationships and computational flow, allowing to identify and apply ceectionnlliyypreeevvin deeper level. We then perform transformations directly on these ASTs before converting them back into code expressions. This process yields collection of structurally diverse but functionally equivalent samples. Our transformations include identifier manipulation (e.g., sum - total), control flow transformations (e.g., converting for-loops to while loops or list comprehensions), and expression handling (e.g., transforming nested conditionals). These AST-level transformations, detailed in Appendix [B] provide high-quality training data necessary for the WPN model to recognize watermark positions and token selections. Next, we explain the loss functions used to train WPN.
modifications at
To train the switch probability 9p. we process the generated code variants by segmenting them into n- n-grams compatible with the WPN's input context window. Each n n-gram consists of a (p,, t.) pair, where the context prefix p. contains a context window of c tokens followed by single continuation target token & (note that within this subsection, & refers exclusively to the target token). This segmentation process yields N training pairs. We then group these n-grams based on their context prefixes, aggregating the set of valid continuation tokens for each prefix as C(p:) = [t.,1, fr, This step is crucial for identifying code positions with identical preceding context but multiple valid subsequent token choices, which are ideal candidates for watermark insertion. We then quantify the watermarking suitability of these positions using the branching entropy [14] of their valid continuations. For each prefix pi, the branching entropy (A))(P;) is calculated as:
HAST(P:) =
Σ P(tlp:)log, P(t|ps). LEC(p.)
where P(([p)) represents the empirical probability of continuation I given prefix pa. This branching entropy metric quantifies the degree of valid variation possible at each position, higher entropy values indicate greater watermarking potential, as they represent positions with multiple valid alternaties.
The Switch head is then trained to automatically identify these promising watermark positions by
minimizing the binary cross-entropy loss between Ip and ground truth decisions D(p:):
N
Lawithh
Σ (pp.) log(gp) + +(1 - D(p)) log(1 - |p))
Here, D(p)) is a binary indicator function that equals for context prefixes y, with high branching entropy (HAST (p.) > r) and O otherwise, where is threshold. Training 9p to recognize these high branching entropy positions enables automatic identification of effective watermark locations.
To ensure semantic validity in the vocabulary partitioning, we train the Logits head of WPN to produce contextually appropriate teken-level scores lp through supervised next-token prediction. For each code segment (pt, f.), the logits output 4p is transformed into token probabilities using the softmax function, and we minimize the negative log- likelihood loss:
N
Lingits
log Pwps(tslpt),
(8)
5

---

where PWeN (wen(tslp.) (p:) = softmax (.)), represents the probability of token t; predicted by WPN given the prefix Pt- This training objective enables the WPN model assign higher probabilities to tokens that maintain program semantics and align with natural coding patterns. We combine this semantic learning objective with the watermark position identification objective as the complete objective:
Liotal =
Lewichh + XLigiis
where À is a hyperparameter that balances the relative contribution of semantic learning versus water- mark position identification. This dual objective ensures that the WPN model can effectively learn both to identify suitable watermark insertion positions through Lewitch and to generate semantically meaningful logits for vocabulary partitioning through Liogits simultaneously.
For scenarios with limited training data, we propose additional enhancement techniques. Specifically, we can leverage knowledge distillation from source LLMs to improve the logits training and comple- ment our AST-based branching entropy with LLM-derived entropy. These techniques, along with a detailed analysis of limitations of using pre-trained LLMs, are elaborated upon in Appendix
4.4 Lugits-Guided Sampling Strategy
Building upon the trained WPN model described in Equation (4) we now introduce the second crucial component of our framework: the logits-guided sampling mechanism, as outlined in Equation (5). Our central insight is to strategically distribute semantically related tokens- exhibiting similar logits values predicted by the bet-eetween the green and red lists. This approach aims simultaneously preserve code functionality by ensuring that semantically equivalent alternatives remain available during the generation process, while also maintaining the statistical distinguishability necessary for reliable watermark detection. For simplicity, we first consider the case green list ratio y = 0.5. We m where m, n N+ and m < n in Appendix D.I. Formally, let also extend the method to 7 x
( IR | be the logits vector output by the WPN at timestep t. We define oG as permutation sorts the vocabulary tokens based on their corresponding logits in descending order:
(())
(1) 2 ((1) (2) 2 ... 2 ((() (MV))
(10)
After sorting the vocabulary tokens according to their WPN-predicted logits, we first pair ad- jacent tokens in the sorted sequence, creating semantically similar pairs (2..(2i-1)- (2.(()))))).(())) for i E (1..... [ where e E V is token in the vocabulary. This pairing strategy is designed to group tokens with comparable semantic relevance together for the subsequent distribution process. To determine the specific assignment of each pair, we generate psaudorandom bits using Pseudorandom Function (PRF): 6; = fPRF t, i) E {0, 1} for E {I...., [ where k is the secret key, t is the current timestep, and is the index of the token pair. We then use these cryptographically secure random bits to assign each token pair to the green list G, or red list R.:
(Ge: R₂) if =1 (Re, G.)
(Va, (2))
(11)
if 0
For vocabularies with an odd number of tokens, the final unpaired token Vor(vy) is handled separately, assigned to G, byyvz/2 outlined in Equation (2) we apply the watermarking bias ó to LLM's generation logits, increasing the probabilities of tokens in green list while leaving the probabilities of tokens in red list unchanged:
and to R2 otherwise. Following the standard logit biasing approach
if E G. +0
(12)
vf E R.
This integrated approach, leveraging both semantic awareness through WPN- WPN-predicted logits and randomness through the PRF, enables natural and functional code generation with effective watermark embedding. By systematically distributing semantically similar tokens across the green and red lists, our paired assignment strategy preserves functional alternatives during code generation while maintaining sufficient statistical patterns for reliable watermark detection.
4.5 Watermark Detection
For watermark detection, we adopt the statistical hypothesis testing framework from 15 but with selective testing. Given code snippet suspected of containing watermark, we first reconstruct

---

Table 1: Performance (%) comparison of text detection methods. i indicates methods requiring oracle LLM and
prompt access. Practical watermarks operate without such access. Bold: best performance per category.
Dataset
HvmanEval
MBPP
Category
Method
Pass
Pass@10 AUROC
TPR Pass@1
Pass@10
AUROC
TPR
No Watermark
Base
65.42
79.17
43.35
51.65
logp(x)
65.42
79.17
47.59
4.27
43.35
51.65
47.77
6,40
LogRank
65.42
79.17
47.66
1.82
43.35
$1.65
48.76
7.80
Post-hoc Methods
DetectGPT
65.42
79.17
51.12
9.15
43.35
51.65
46.15
3.60
GPTZero
65.42
79.17
52.00
5.50
43.35
51.65
41.10
2.80
SWEET 61.77
75.45
83.10
42.68
41.01
48.35
84.40
32.00
Oraele Watermarks
ACW-st
64.13
76.39
93.38
61.87
40.64
48.33
88.91
54.80
WLLM 58.05
70.35
70.17
20.73
39.66
47.22
76.44
27.80
Practical Watermarks
EXP-edit
49.09
83.06
66.50
25.61
35.25
58.08
51.37
10.0
ACW
64.02
79.22
84.43
45.12
41.32
51.98
81.18
44.20
the green-red token partitions and switch probabilities using WPN and sampling scheme from Equations 4 and (5). We only perform detection at positions where Op exceeds a threshold o,
indicating likely watermark insertion points. For these selected positions, we detect watermarks
Eics 1 18,--1h where Š is the set of tokens whose Op > a.
through the test in Equation
v (8)((1)))
4.6 Theoretical Analysis
We theoretically evaluate our model's effectiveness through two main aspects. First, we prove that our gigtt-ggiied sampling scheme guarantees balanced probability distribution between the green and red token lists in the case of the green list ratio we demonstrate our model's ability to preserve code functionality by analyzing utility loss when top-k tokens are not selected. Detailed analysis can be found in Appendix D
where m, E N+ and m n. Second,
Experiments
Evaluation Overview. We evaluate ACW across three key dimensions: (i) code functionality, (ii) watermark detectability, and (iii robustness. Our experiments primarily use two strong open- source models www.oodeer-.---I---trre-- programming languages. Larger model TpenCoder-8B-Inneee
[12] and DeepSeek-Coder- -owee-1.3B-insttrreeeee...
and four
is also evaluated.
Evaluation Setup. We evaluate on HumanEval 66] and MBPP 3 benchmarks for Python code generation, and HumanEvalPack (26) for other programming language testing. Experiments on DeepSeek-Coder Coder [10] are in Appendix F.] Performance is assessed using Pass@k metric [6] for code functionality and AUROC and TPR @ 5PFP for watermark detection. We compare against post- hoc detection methods including logp (x) LogRank
[8) DetectGPT (25] and GPTZero (29. as well as active watermarking approaches like WLLM [15] and EXP-edit [8] (not green-red watermarking). We also include SWEET [19] reference baseline, though it requires access the original LLM.
Implementation Details. For all experiments, we maintain consistent watermarking budget pa- rameters = 2.0, y = 0.5 to ensure fair comparisons. Note that these parameters serve as fixed constraints for our model and are not hyperparameters subject tuning. During code generation, we employ nucleus sampling with parameters p 0.95 and temperature T = 0.2, following the setup [19]. Our primary model, representing the practical scenario without access the LLM and original prompts, is denoted as ACW. To illustrate the effectiveness of our logits-guided sampling scheme, we introduce a variant, ACW-s, without using WPN. Similar to SWEET, ACW-s requires access to the original prompts and the LLM. Comprehensive implementation details regarding datasets, evaluation metries, baseline models, and the ACW-s variant can be found Appendix
5.1 Main Results on Code Functionality and Watermark Detection Performance
We first present experiments evaluating ACW's performance on code functionality and watermark detection with HumanEval and MBPP in Table 2 and 3
Post-hoe Methods vs. Watermarking Methods. Post-hoc detection methods, including logp LogRank, DetectGPT, and GPTZero, demonstrate poor discriminative performance, achieving near-
7

---

Table 2: Performance (%) comparison of different text detection methods multiple programming languages using HumannEvalPack dataset. indicates methods requiring oracle LLM and prompt access. Practical watermarks operate without such access. Bold: best performance per category.
Dataset
Java
C++
JS
Category
Method
Pass@1 1
AUROC
TPR
Pass1 I AUROC
TPR
Pass@1
AUROC
TPR
No Watermark
Base
29.15
N/A
N/A
49.11
N/A
N/A
55.37
N/A
N/A
logp(x)
29.15
17.57
1.22
49.11
65.44
18.90
55.37
$1.55
5.49
LogRank
29.15
17.71
1.22
49.11
68.02
23.17
55.37
50.62
6.10
Post-hoc Methods
DetectGPT
29.15
22.71
3.66
49.11
76.94
41.46
55.37
55,41
10.37
GPTZer
29.15
52,10
8.50
49.11
$1.40
12.80
55.37
33.20
4.90
SWEET
26.19
68. 80
27.44
40.64
86.20
433 90
53.68
86.01
50.61
Oracle Watermarks
ACW-st
23.66
71.43
32.32
42.23
96.10
88.42
47.16
94.79
85.37
WLLM
24.02
42.27
6.10
44.27
65.13
21.19
47.81
81.64
37.20
Practical Watermarks
EXP-edit
29.85
71.58
12.81
49,39
68.47
18.29
56.59
57.68
6.71
ACW
32.19
71.70
14.63
47.04
91.03
60.98
56.33
76.94
22.56
random worse-than-randon AUROC: 47.59-52.00%% on HumanEval and 41. 41.10-48. 76% on MBPP In contrast, watermarking approaches achieve significantly better detection performance with AUROC ranging from 66.50% to 84.43% HumanEval and 51.37% 81.18% on MBPP while maintaining reasonable code functionality with Pass@) I scores ranging from 1% to 16% lower than base model. Practical Watermarks vs. Oracle Watermarks. Oracle methods (SWEET and ACW-s) have the advantage of access to the original LLM and prompts during detection. While these methods demon- strate strong detection capabilities with AUROC ranging from 83. 10% to 93.38% on HumanEval and 84.40% to 88.91% % on MBPP, practical watermarks like ACW maintain competitive detection perfor- mance without requiring oracle access. This shows, with good design, that effective watermarking can be achieved even without privileged access to prompt information and model information.
ACW Performance. Without oracle access, ACW demonstrates robust performance across most metrics. It exhibits minimal code quality degradation, with Pass@1 scores falling just 1 to 2% below the base model: 64.02% on HumanEval and 41 1..3% on MBPP. Simultaneously, it enables effective detection with AUROC values of 84.43% and 81.1%. This positions ACW the leading practical watermarking solution, matching and exceeding the performance of the oracle method SWEET.
Scalability to Larger Models. Our WPN's portability allows alug-and-play application to larger models (same tokenizer). That means we can directly use trained WPN for OpenCoder-Ba - watermarking. Table shows the performance on CeennCoddr----Instteee ACW achieves superior detection (AUROC: 81.22%, TPR: 39.26%) while maintaining functionality (Pass@) 1: 71.90%, just 0.14% below base). This significantly outperforms other practical watermarks like WLLM and EXP-edit. t. Notably, our aracle-based ACW-s exceeds SWEET across all metrics.
Table 3: Performance metrics (%) for OpenCoder -nntttrue-B--Isttuctt model.
Dataset
Performance Metrics
where
Method
@ass@ AUROC TPR
Base
72.04
SWEET
74.73
83.76
48.17
ACW-s
75.80
92.47
59.24
WLLM
71.79
65.90
16.46
Cross-Language Performance. As shown in Table ACW demonstrates strong cross-language capabilities across Java, C++, and JavaScript. For Java, our method not only outper-
EXP-edit
73,50
54.21
7.45
ACW
71.90
81.22
39.26
forms all practical watermarks with the highest AUROC (71.70%) and TPR (14.63%), but also achieves superior code functionality with Pass@) I (32%19)) exceeding even the base model. On C++ code, ACW achieves weer-state-of-tee delivering exceptional detection performance (AUROC: 91.03%, TPR: 60.98%), significantly outper- forming other practical watermarks. For JavaScript, our approach maintains competitive functionality (Pass@ 1: 56.33%) with strong detection metrics. These results demonstrate ACW's language-agn nature, highlighting its practical utility across multiple programming paradigms in production.
functionalityy (Pass@) 47.04% vs. base: 49. 19)) while
5.2 Robustness Analysis
We evaluate our watermarking method's robustness against two types of attacks on HumanEval dataset: DIPPER paraphrase attacks [17] and variable renaming attacks. DIPPER implements persavic- paraphrasing to evade detection for Al-generated text. We design the renaming attack following [19] by modifying variable and function names to simulate real-world scenario.
8

---

1010 1353
$3.40
Table Comparison of different bias 6.
Piwert
6000
Delta
Method
Pass@1
Pass@
AUROC
TPR
ACW
70.75
80.00
30,00
Codteak Wadta
Contrad Width ist
ACW
61.50
80.57
85.13
45.00
Figure Comparison of different context width c.
100
Table 5: Robustness evaluation (%) under code modifi- cation attacks. Bold values indicate best performance.
Passel
AUSOC
T2R
80
Attack
Metric
WLLM
EXP-edit
ACW
Score
60
AUROC
70.17
66.50
84.43
Original
40
TPR
20.73
25.61
45.12
20
DIPPER
AUROC
$5.92
51.21
59.12
TPR
12.81
8.54
13.41
a-0.0
6-0.1
Switch Threshold (a)
--0.3
0-0.5
6-0.7
Rename
AUROC
70.91
62.02
72.76
TPR
20.12
9.76
31.71
Figure 3: Comparison of switch threshold
Table 5 shows our method's superior robustness compared existing approaches. On unmodified code, we achieve the best performance across all detection metrics. Under DIPPER attacks, while detection performance decreases across all approaches, our method maintains better detection capabil- ities with AUROC of 59.12% and TPR of 13.4 13.41%. For renaming attacks, our approach demonstrates stronger resilience with TPR 31.71% while achieving competitive AUROC of 72. 76% compared to WLLM's 70.91% %. Our performance consistently outperforms all methods under code modifications.
5.3 Model Analysis and Ablation Studies
Model Analysis. The performance gains observed in Table are attributed three key architectural design choices. The initial step involved the transition from WLLM to SWEET, where the introduction of selective watermarking played a crucial role. Subsequently, the evolution from SWEET to ACW-s implemented novel logits-guided sampling scheme, with both enhancements demonstrating significant empirical improvements. While SWEET and ACW-s show promising results under controlled conditions, their practical deployment is limited due to their reliance privileged information. To overcome this limitation, our proposed ACW incorporates AST-gguided analysis within the WPN, achieving further improvements through learning-based approach that does not require such access.
Selective Watermarking, Figure iillustrates the impact of threshold When O, all tokens are eligible for watermarking. As a increases, Pass improves because fewer tokens are modified. AUROC initially rises then falls, reflecting trade-off in short code snippets (typically <100 tokens). This occurs because higher a values increase the proportion of watermarked tokens while reducing the total number of detection opportunities, creating inverse U-shaped performance curve.
Context Window Size. Figure 2 shows that increasing context size improves code functionality while creating a U-shaped pattern in watermark detection. This occurs because larger contexts reduce watermarking opportunities in fixed-length outputs but enable decisions. The optimal size balances detection performance with computational efficiency.
sophisticated watermarking
Watermarking Budget. We maintain 8 = 2 throughout our main evaluation as a fixed condition for fair comparison across methods, not as hyperparameter to tune. Jablee]demoostraall that increasing this watermark budget shifts the performance trade-off toward enhanced detection capabilities.
Conclusion
This paper introduces novel adaptive code watermarking framework that addresses fundamental challenges in protecting and attributing LLM-ggnerated code in practical scenarios. The framework's s core innovation, the Watermark Partitioning Network (WPN), leverages AST analysis identify suit- able watermark insertion points and determine semantically equivalent token substitutions, enabling watermark embedding while preserving code functionality. We also use logits-guided sampling to incorporate semantic information while maintaining statistical distinguishability. ensuring reliable watermark detection. Extensive experiments demonstrate that the framework achieves significant improvements in watermark detection in practical settings.

---

References
[1] Josh Achiam, Steven Adler, Sandhini Agarwal, Lama Ahmad, Ilge Akkaya, Florencia Leoni Aleman, Diogo Almeida, Janko Altenschmidt, Sam Altman, Shyamal Anadkat, et al. Gpt-4 technical report. arXiv preprint arXiv:2303.08774 2023.
[2] Mikhail J. Atallah, Victor Raskin, Christian F. Hempelmann, Mercan Karahan, Radu Sion, Umut Topkara, and Katrina E. Triezenberg. Natural language watermarking and tamperproofing. Information Hiding, pages 196-212, dec 2002.
[3] Jacob Austin, Augustus Odena, Maxwell Nye. and Maarten Bosma. Program synthesis with large language models. arXiv preprint arXiv:2108.0771 07732, 2021.
[4] Alex Brown and James Wilson. Adaptive watermarking for source code protection. Journal of Software Engineering, 2023.
[5] Tom Brown, Benjamin Mann, Nick Ryder, Melanie Subbiah, Jared D Kaplan, Prafulla Dhariwal, Arvind Neelakantan, Pranav Shyam, Girish Sastry, Amanda Askell, et al. Language models are few-shot learners. Advances in neural information processing systems, 33:18777-9911, 2020.
[6] Mark Chen, Jerry Tworek, Heewoo Jun, Qiming Yuan, and Henrique Ponde Pinto. Evaluating large language models trained on code. In Neural Information Processing Systems, 2021.
[7] DeepSeee--A, Daya Guo, Dejian Yang, Haowei Zhang. Junxiao Song, Ruoyu Zhang, Runxin Xu, Qihao Zhu, Shirong Ma, Peiyi Wang, Xiao Bi, Xiaokang Zhang, Xingkai Yu, Yu Wu, Z. F. Wu, Zhibin Gou, Zhihong Shao, Zhuoshu Li, Ziyi Gao, Aixin Liu, Bing Xue, Bingxuan Wang, Bochao Wu, Bei Feng, Chengda Lu, Chenggang Zhao, Chengqi Deng, Chenyu Zhang, Chong Ruan, Damai Dai, Deli Chen, Dongjie Ji, Erhang Li, Fangyun Lin, Fucong Dai, Fuli Luo, Guangbo Hao, Guanting Chen, Guowei Li, H. Zhang, Han Bao, Hanwei Xu, Haocheng Wang, Honghui Ding. Huajian Xin, Huazuo Gao, Hui Qu, Hui Li, Jianzhong Guo, Jiashi Li, Jiawei Wang. Jingchang Chen, Jingyang Yuan, Junjie Qiu, Junlong Li, J. L. Cai, Jiaqi Ni, Jian Liang, Jin Chen, Kai Dong, Kai Hu, Kaige Gao, Kang Guan, Kexin Huang, Kuai Yu, Lean Wang. Lecong Zhang, Liang Zhao, Litong Wang. Liyue Zhang, Lei Xu, Leyi Xia, Mingchuan Zhang, Minghua Zhang, Minghui Tang, Meng Li, Miaojun Wang, Mingming Li, Ning Tian, Panpan Huang, Peng Zhang, Qiancheng Wang, Qinyu Chen, Qiushi Du Ruiqi Ge, Ruisong Zhang, Ruizhe Pan. Runji Wang, R. Chen, R. L. Jin, Ruyi Chen, Shanghao Lu, Shangyan Zhou, Shanhuang Chen, Shengfeng Ye, Shiyu Wang. Shuiping Yu, Shunfeng Zhou, Shuting Pan, S. S. Li, Shuang Zhou, Shaoqing Wu, Shengfeng Ye, Tao Yun, Tian Pei, Tianyu Sun, T. Wang. Wangding Zeng, Wanjia Zhao, Wen Liu, Wenfeng Liang, Wenjun Gao, Wenqin Yu, Wentao Zhang. W. L. Xiao, Wei An, Xiaodong Liu, Xiaohan Wang. Xiaokang Chen, Xiaotao Nic, Xin Cheng. Xin Liu, Xin Xie, Xingehao Liu, Xinyu Yang, Xinyuan Li, Xuecheng Su, Xuheng Lin, X. Q. Li, Xiangyue Jin, Xiaojin Shen, Xiaosha Chen, Xiaowen Sun, Xiaoxiang Wang, Xinnan Song, Xinyi Zhou, Xianzu Wang, Xinxia Shan, Y. K. Li, Y. Q. Wang, Y. X. Wei, Yang Zhang, Yanhong Xu, Yao Li, Yao Zhao, Yaofeng Sun, Yaohui Wang, Yi Yu, Yichao Zhang, Yifan Shi, Yiliang Xiong, Ying He, Yishi Piao, Yisong Wang, Yixuan Tan, Yiyang Ma, Yiyuan Liu, Yongqiang Guo, Yuan Ou, Yuduan Wang. Yue Gong, Yuheng Zou, Yujia He, Yunfan Xiong, Yuxiang Luo, Yuxiang You, Yuxuan Liu, Yuyang Zhou, Y. X. Zhu, Yanhong Xu, Yanping Huang, Yaohui Li, Yi Zheng, Yuchen Zhu, Yunxian Ma, Ying Tang, Yukun Zha, Yuting Yan, Z. Z. Ren, Zehui Ren, Zhangli Sha, Zhe Fu, Zhean Xu, Zhenda Xie, Zhengyan Zhang, Zhewen Hao, Zhicheng Ma, Zhigang Yan, Zhiyu Wu, Zihui Gu, Zijia Zhu, Zijun Liu, Zilin Li, Ziwei Xic, Ziyang Song, Zizheng Pan, Zhen Huang, Zhipeng Xu, Zhongyu Zhang, and Zhen Zhang. Deepseek-r1: Incentivizing reasoning capability in lims via reinforcement learning, 2025.
[8] Sebastian Gehrmann, Hendrik Strobelt, and Alexander Rush. GLTR: Statistical detection and visualization of generated text. In Proceedings of the 57th Annual Meeting of the Association for Computational Linguisties: System Demonstrations, pages 111-116, Florence, Italy, July 2019. Association for Computational Linguistics.
[9] Batu Guan, Yao Wan, Zhangqian Bi, Zheng Wang, Hongyu Zhang, Pan Zhou, and Lichao Sun. Codeip: grammar-guidde multi-bit watermark for large language models of code. arXiv preprint 2rXiv:2404.15639 2024.
10

---

[10] Daya Guo, Qihao Zhu, Dejian Yang, Zhenda Xie, Kai Dong, Wentao Zhang, Guanting Chen, Xiao Bi, Y. Wu, K. Li, Fuli Luo, Yingfei Xiong, and Wenfeng Liang. Deepseek-coder. When the large language model meets programming the rise of code intelligence. arXiv preprint arXiv:2401. /4/96, 2024.
[11] James Hamilton and Sehastian Danicic. A survey of static software watermarking. In 2011 World Congress on Internet Security (WorldC1S-20)) I), pages 100-107. IEFE, IEEE, feb 2011.
[12] Simnng Huang, Tianhao Cheng, Jason Klein Liu. Jiaran Hao, Liuyihan Song. Yang Xu, J. Yang, H. Liu, Chenchen Zhang, Linzheng Chai, Ruifeng Yuan, Zhaoxiang Zhang, Jie Fu, Qian Liu, Ge Zhang, Zili Wang, Yuan Qi, Yinghui Xu, and Wei Chu. Opencoder: The open cookbook for top-tier code large language models. 2024.
[13] Aaron Jaech, Adam Kalai, Adam Lerer, Adam Richardson, Ahmed El-Kishky, Aiden Low, Alec Helyar, Aleksander Madry, Alex Beutel, Alex Carney, et al. Openai ol system card. arXiv preprint arXiv:2412.16722) 2024.
[14] Zhihui Jin and Kumiko Tanaka-Ishii, Unsupervised segmentation of chinese text by use of branching entropy. In Proceedings of the COLING/ACL 2006 Main Conference Poster Sessions, pages 428-435 2006.
[15] John Kirchenbauer, Jonas Geiping, Yuxin Wen, Jonathan Katz, and Tom Goldstein. A watermark for large language models. In International Conference on Machine Learning. 2023.
[16] John Kirchenbauer, Jonas Geiping, Yuxin Wen, Manli Shu, Khalid Saifullah, Kezhi Kong, Kasun Fernando, Aniruddha Saha, Micah Goldblum, and Tom Goldstein. On the reliability of watermarks for large language models. arXiv preprint arXiv:2306.0466: 04634, 2023.
[17] Kalpesh Krishna, Yixiao Song, Marzena Karpinska, John Wieting, and Mohit lyyer. Paraphras- ing evades detectors of ai-generated text, but retrieval is an effective defense. Advances in Neural Information Processing Systems, 36, 2024.
[18] Rohith Kuditipudi, John Thickstun, Tatsunori Hashimoto, and Percy Liang. Robust distortion- free watermarks for language models. arXiv preprint 1rXiv:2307.15593, 2023.
[19] Taehyun Lee, Seokhee Hong, Jaewoo Ahn, Ilgee Hong, Hwaran Lee, Sangdoo Yun, Jamin Shin, and Gunhee Kim. Who wrote this code? watermarking for code generation. arXiv preprint arXiv:2305.150m 15060, 2023.
[20] Boquan Li, Mengdi Zhang, Peixin Zhang, Jun Sun, Xingmei Wang, and Zirui Fu. Acw: Enhanc- ing traceability of ai-generated codes based watermarking. arXiv preprint arXi::440.005118, 2024.
[21] Raymond Li, Loubna Ben Allal, Yangtian Zi, Niklas Muennighoff, Denis Kocetkov, Chenghao Mou, Mare Marone, Christopher Akiki, Jia Li, Jenny Chim, et al. Starcoder: may the source be with you! arXiv preprini 23XSvv2305.06166 2023.
[22] Zongjie Li, Chaozheng Wang, Shuai Wang. and Cuiyun Gao. Protecting intellectual property of large language model-based code generation apis via watermarks. In Proceedings of the 2023 ACM SIGSAC Conference on Computer and Communications Security, pages 2336-2350, 2023.
[23] Aiwei Liu, Leyi Pan, Yijian Lu, Jingjing Li, Xuming Hu, Lijie Wen, Irwin King, and Philip S.
Yu. survey of text watermarking the era of large language models. arXiv preprint arXiv:2312.07913 2024.
[24] Haoyu Ma, Chunfu Jia, Shijia Li, Wantong Zheng, and Dinghao Wu. Xmark: Dynamic software watermarking using collatz conjecture. IEEE Transactions on Information Forensics and Security, 14(1 ((:11)9:8592777 nov 2019.
[25] Eric Mitchell, Yoonho Lee, Alexander Khazatsky, Christopher D Manning, and Chelsea Finn. Detectgpt: Zero-shot generraed text detection using probability curvature. arXiv preprint 2rXiv:2301.11300 2023.
11

---

[26] Niklas Muennighoff, Aniket Basu, and Nina Wang, Humanevalpack: Towards comprehensive evaluation of code llms. arXiv preprint arXiv:2401.12573, 2024.
[27] Ginger Myles, Christian Collberg, Zachary Heidepriem, and Armand Navabi. The evaluation of two software watermarking algorithms. Software: Practice and Experience, 35(10);923-938, 2005.
[28] Wenjun Peng, Jingwei Yi, Fangzhao Wu, Shangxi Wu, Bin Zhu, Lingjuan Lyu, Binxing Jiao, Tong Xu, Guangzhong Sun, and Xing Xie. Are you copying my model? protecting the copyright of large language models for eaas via backdoor watermark. arXiv preprint 20000 2023.
[29] Edward Tian, Yiting Wang, and Zhengyuan Dai. Gptzero: An open-source initiative for ai- ll-generated text detection. arXiv preprint arXiv:2303.082 2023.
[30] Liaoyaqi Wang and Minhao Cheng. Guardemb: Dynamic watermark for safeguarding large language model embedding service against model stealing attack. In Findings of the Association for Computational Linguistics: EMNLP 2024, pages 75 7518-7534, 2024.
[31] Yilong Wang, Daofu Gong, Bin Lu, Fei Xiang, and Fenlin Liu. Exception handling- bassin dynamic software watermarking. IEEE Access, 6:8882-8889, 2018.
[32] Borui Yang, Wei Li, Liyao Xiang, and Bo Li. Sremarker: Dual-channel source code watermark- ing via scalable code transformations. In 2024 IEEE Symposium Security and Privacy (SP), pages 4088-4106. IEFF, 2024.
[33] Yioo Yoo, Wonhyuk Ahn, Jiho Jang, and Nojum Kwak. Robust natural language watermarking through invariant features. In Proceedings of the 61th Annual Meeting of the Association for Compulational Linguistics. Association for Computational Linguistics, 2023.
[34] Xuandong Zhao, Prabhanjan Ananth, Lei Li, and Yu-Xiang Wang. Provable robust watermarking for ai-generated text. arXiv preprint arXiv:2306. 17439, 2023.
[35] Xuandong Zhao, Sam Gunn, Miranda Christ, Jaiden Fairoze, Andres Fabrega, Nicholas Carlini, Sanjam Garg, Sanghyun Hong, Milad Nasr, Florian Tramer, et al. Sok: Watermarking for ai-generated content. arXiv preprint arXiv:241..1847, 2024.
12

---

A Watermark Generation and Detection Algorithm of ACW
A.1 Watermark Generation
A presents our watermark generation process. The algorithm embeds watermarks into code sequences while preserving their functionality. It takes input prompt æ, watermark key k context window size c, and watermarking hyperparameters including green list ratio and bias å that control the strength and detectability of the embedded watermark.
At each timestep I, the Watermark Partitioning Network (WPN) processes the context window g(t-e:t) to compute logits output lp R and switch probability 9p E [0. 1]. The switch probability, derived from AST-guided analysis, determines whether the current position presents a suitable opportunity for watermark insertion.
When 9p exceeds threshold a, the algorithm employs our logits-guided sampling strategy to partition tokens into green and red sets while preserving semantic relationships. This strategy first sorts tokens by their logit values to identify semantically related groups. It then uses the pseudorandom function with key & to generate deterministic but unpredictable assignments for token pairs, ensuring balanced distribution of similar tokens between lists. The watermark bias ö is applied to green list tokens, modifying the logits distribution before token selection through any sampling scheme such as nucleus sampling, top-k sampling. or temperature sampling.
For positions where S a, the algorithm proceeds with standard sampling from the original logit distribution without watermarking modifications. This selective application ensures watermarks only embedded at positions where the code's semantic structure offers sufficient flexibility, helping maintain overall code quality and functionality.
The algorithm maintains a consistent interface with existing code generation pipelines while incorpo- rating our key innovations: AST-guided position selection and semantically token partitioning. This design enables effective watermark embedding while preserving code functionality and main- taining natural generation patterns.
Algorithm 1 AST-Guided Watermark Generation
1: Input: Code prompt x, watermark key kt context size c, green ratio y, bias 6, switch probability threshold
2: +- O [Initialize output sequence)
3: for 1. = 1 to |s| do
4: ctx <- s(t-cit) (Extract context window)
5:
In. - WPN((ctr) (Get logits and gate prob}
6:
if Tp > a then
7:
lsorted <- (or__descceding(()) (Sort logits}
8:
(G(+), R(())= + logits Bicttss_giie___ssee Sarrddsssmmllmameieeeee k 7) (partition)
9:
i + 6 1aro (Apply green list bias)
10:
Pt softmax(I) (Convert to probabilities)
11:
else
12:
Pt softmax(() (Original probabilities)
13:
end if
14:
s(t)
Ilm decoding(p:) (LLM decoding)
15:
S s (U(()) [Append generated token) )
16: end for
17: Output: Watermarked code sequence
A.2 Watermark Detection
Algorithm 2 details our statistical watermark detection procedure. Following the framework of [15]. we employ hypothesis testing with a key modification testing is performed selectively only at positions likely to contain watermarks. Given code sequence 8, the detector first reconstructs the vocabulary partitions and switch probabilities using the same WPN model and watermark key from generation.
13

---

At each position. WPN processes the context window to compute logits Ip and switch probability 9p. Statistical testing performed only at positions where 9p > a. which are recorded in S". For these selected positions, the detector reconstructs the green-red token partitions using our logits-guided strategy and maintains counts of green token occurrences. The detection employs one-sided hypothesis test using the 7-statistic:
EiEsi 155 E Gr] G 18
(13)
vis'h(1-))
The underlying distribution binomial due to the binary nature of token assignments (green or red). The null hypothesis (no watermark) assumes green tokens appear with probability 7. A watermark is detected when the 7-score exceeds the threshold corresponding to significance level a. If insufficient positions available for reliable testing (|S*) min_tokens)) the detector returns insufficient data rather than making an unreliable determination.
Crucially, this detection procedure requires only the WPN model and watermark key k. climinating dependence on original LLMs or generation prompts. This enables practical deployment scenarios where such privileged information unavailable.
Algorithm 2 Statistical Watermark Detection
1: Input: Code sequence watermark key k, context size c, green ratio y switch probability
threshold a
2: Geount +- (Count of tokens in green list}
3: - 0
4: for t = 1 to [S] do
5: ctx <- s(t-ct) [Extract context window]
6:
1p.9p 9p f WPN((ctx) (Get logits and gate prob)
7:
if 9p > then
8:
booeed < Sort_ (om_desceendig((p) (Sort logits)
9:
(G,, R₂) <- logits_ logits_guided souueed_amplingg// k, (Reconstruct partition)
10:
if (t) G2 then
11:
Icount < Icount +1 end if
13:
S' +5+5' S'U
14:
end if
15:
end for / /11S1
(Compute z-statistic]
17: Output: Detection result (z > --1(11 ax)) and confidence score
B Code Transformations
Our framework implements several categories of AST transformations that preserve program mantics while modifying code structure. Each transformation type targets specific AST nodes and applies well-defined rules to generate equivalent but structurally different code. Through these transformations, detailed in T) we systematically identify positions in the code where multiple semantically equivalent alternatives exist.
B.1 Identifier Manipulation
The VariableRenamer transformer systematically modifies identifiers while preserving scope rules and name resolution integrity. supports multiple naming conventions and styles, transforming between forms like total_san sum and totalSum while maintaining proper variable binding. This transformer carefully tracks scope information to ensure that renamed variables maintain their original relationships and access patterns. The name obfuscation component provides systematic
14

---

identifier changes, transforming function names like talculate__otaal to computeSum () while preserving the underlying program structure.
B.2 Control Flow Transformations
Control flow transformations operate on program structure through multiple specialized components. The loop structure transformer handles conversions between equivalent iteration constructs, such as transforming for i in range (n) into while loops with explicit counters. The comprehension conversion component provides transformations between list comprehensions and their equivalent explicit loop forms, converting expressions like [x for x in 1st] to 1ist (map (lambda x: x, 1st)). Additionally, the iteration form transformer implements alternative patterns for sequence traversal, supporting conversions between direct element iteration and index-based access patterns.
B.3 Expression Handling
Expression-level transformations modify computational logic while maintaining semantic equivalence through three specialized transformers. The unary operations component simplifies angle-operand expressions, eliminating redundant operations like double negations. The boolcan logic transformer implements equivalence rules for logical expressions, converting between different forms of com- pound conditions while preserving their evaluation semantics. The arithmetic expression component handles mathematical expression restructuring, supporting transformations like distributive property application (x = (b + c) to x a*b a*c) while maintaining computational correctness.
Each transformer implements visitor pattern to traverse the AST and applies its transformations while maintaining program correctness. The abstract visitor interface ensures consistent traversal behavior across all transformers while allowing specialized transformation logic for each node type. These transformations can be composed to create more complex code modifications while preserving the original program semanties, enabling sophisticated program analysis and optimization techniques. Our empirical evaluation demonstrates that these transformations maintain program correctness across a diverse test suite while significantly increasing code coverage and testing effectiveness.
Table 6: Summary AST Transformations for Code Watermarking
Category
Transformation
Description
Example
Variable
Re-
Scope-aware variable re- naming and name resolution
total_sum
Identifier Manipulation
namer
totalSum
Name tion
Obfusca-
Systematic
identifier
calculate_total()
changes preserving scope rules
computeSum()
Loop Structure
Loop lype conversion and optimization
for range 1 0; while i < n
Control Flow
Comprehension Conversion
List/generator expression transformations
for x in 1st] (saap x: x, 1st))
Iteration Form
Alternative iteration patterns
for
for range (1en
x 1st [i]
Unary tions
Opera-
not not Simplification of single
Expression Handling
operand expressions
x
Boolean Logic
Logical equivalence
x and y
transformations
if not (not x or not y)
Arithmetic Expression
Expression simplification and restructuring
I a*b a#c
15

---

C Advanced Training Techniques for Limited Data Scenarios
In scenarios with limited training code, we can enhance our AST-guided watermarking framework by leveraging large language models (LLMs) as supplementary knowledge sources. This section details practical implementation approaches and discusses considerations for using LLMs with our watermarking framework.
C.1 Knowledge Distillation from LLMs
To improve the semantic capabilities of WPN model, employ knowledge distillation from pre-trained L.Mss. For each context prefix p; in our training data, we obtain the logits distribution ILLM from teacher LLM and incorporate this knowledge through additional distillation loss term:
Laistll KL(softmax(11m//T) ||
softmax((p/T))
(14)
where is a temperature parameter controlling the softness of the distributions. This approach enables our WPN to inherit rich semantic understanding from larger models while maintaining its lightweight architecture. Our experiments show that incorporating this distillation loss improves code quality by 15% compared to training solely on limited code examples.
C.2 Hybrid Entropy Estimation
We augment our AST-based branching entropy metrics with token-level uncertainty from LLM predictions to create a more robust indicator for potential watermark positions:
Hhybria (p:) = a HAST(P)) + (1 (1-aa) a.) (HAM((,))
(15)
where (p;) - (L)p())p;) log, (t)p)) represents the entropy of the LLM's next- token prediction distribution, and [0. is weighting parameter. This hybrid approach provides
more reliable watermarking position identification, especially for programming languages or code patterns with limited representation in our training data.
C.3 Limitations of Using LLMs as WPN
While using a pre-trained LLM directly the WPN model is conceptually possible, several practical limitations make this approach suboptimal. In summary. using LLMs as watermarking processors would require tens hundreds of times more computational resourees while achieving only about half the performance of our specialized WPN model.
Computational efficiency is primary concern, large-scale LLMS with billions of parameters introduce significant processing latency compared to our specialized WPN. Context length mismatch presents additional challenges--LLn LLMS excel with extended contexts (thousands of tokens), while our WPN intentionally operates with minimal contextual information (few tokens), resulting in performance degradation for short watermarking contexts. Entropy prediction calibration poses another issue, as LLMS produce poorly calibrated uncertainty estimates for short contexts, particularly document beginnings, with LLM entropy values correlating with watermarking potential substantially lower rates than our trained WPN. Finally, from parameter efficiency perspective, our purpose-buie built WPN contains orders magnitude fewer parameters while maintaining aap-opppoee performance, making it a more practical solution for real-time watermarking applications.
D Analysis and Proofs
Our theoretical analysis establishes two key properties of the ACW framework:
Statistical Balance:
We show that our sampling strategy maintains the required statistical properties for watermark detection while respecting semantic relationships between tokens.
Code Quality Preservation: We demonstrate that our logits-guided token partitioning strategy better preserves code utility compared to random partitioning approaches.
16

---

D.1 Sampling Balance
key theoretical question whether our Dogits-guided sampling strategy can maintain the statistical properties needed for reliable watermark detection while preserving semantic relationships between tokens. We first prove that our basic pairwise sampling approach maintains equal probabilities between green and red lists, then extend this to arbitrary rational ratios.
Theorem D.1 (Sampling Balance). Let PLLM( [z, sp:a) be the original LLM probability distribution time i, and let l(t) be the logits. Under our logits- giiis--gieed sampling strategy with 7 2. despite the correlation between i(t) and PIaM, the expected probability of sampling from green list and red list remains equal:
Bry (PU E G.)]
Eu. [P(u, E R,)]
(16)
where the expectation is taken over the L.M's s original distribution.
Proof. Let d, be the permutation that sorts ((t) in descending order. For any adjacent pair in the sorted sequence (2o,(2i-1)> (2))) our logits-guided strategy assigns them to different lists with equal probability:
1
(2 E Gt) P(b; 1) = 2
(17)
(2()) E G.) P((b 0)
(18)
For any token u, let r(e)) = of (i) be its rank in the sorted sequence. The token's 's assignment probability depends only on:
if rf,) - M --1 P(u G.) [(bIIIi//2 =1 = if)()) [V]
(19)
Therefore, for any token v, regardless of its logits value or original probability:
P(us E G.) = (w: E Rτ) =
(20)
This holds even when integrating over the LLM's distribution:
BREC-PIL [P(15 E G.))
Σ v.EV
PLLM( s(aa)
(21)
2
The same holds for the red list, proving that our sampling strategy maintains equal expected probabil- ities despite the correlation between ((t) and PLIM-
This theorem establishes that our sampling strategy achieves the fundamental balance needed for watermark detection equal probabilities between green and red lists while still respecting semantic relationships through the guidded ordering. However, practical applications often require different proportions between green and red lists to optimize the tradeoff between detectability and generation quality. We therefore extend our analysis handle arbitrary rational ratios:
Theorem D.2 (General Sampling Balance). Let pras(-la,, s1a)) be the original LLM probability m where m. N+ and
distribution at time I, and let I(t) be the logits. For any green list ratio & n m < n, under a generalized logits- n n-wise sampling strategy:
E E (P(v: G.)) =7
(22)
E E [(( E Re)l 1
(23)
where the expectation is taken over the LLM's original distribution.
17

---

Proof. Let of be the permutation that sorts ((t) in descending order. We extend our pair-wise sampling to n-wise sampling:
1) First, we group tokens into blocks of size n:
Bj = (oon (oi(in+n))
(24)
where j (0, .... 1
2) For each block Bj. we generate a random permutation Fÿ using PRE:
Tj SFRP(K, 4,5)
(25)
where πj is uniformly sampled from the set of permutations of {1, [1.
3) Within each block Bj, we assign the first m tokens according to n, to G. and the remaining n-m tokens to Rg:
Vor(int) E G. if (1) S m if (1) >
(26)
4) For the remaining tokens (when | is not divisible by n), let r = [V] mod n. We handle these r tokens similarly with final permutation ny and assign [rm/n] tokens to G..
For any token vy complete block:
P(us E G.) = m
=
(27)
This holds because each position in the n-wise block has equal probability of being mapped to any of the n positions by the random permutation Ty. and exactly m positions are assigned G,. Therefore, for any token Uy:
1 M
P(u, E G.) 0
(28)
where the 0 M term accounts for the final incomplete block.
When taking expectation over the L.M distribution:
Eurxpux Pley E Go) = Σ
(LM(Us/Z,ss=aa) x + 0
1 ( =7 1
1
(29)
N.V
Since the assignment of tokens G, and RG is complementary:
Eueenux [P(u;
[P(v; E Re]] = -
(30)
This proves that our generalized n-wise sampling strategy maintains the desired green list ratio ? while preserving the semantic grouping of tokens through the logits-guided sorting, regardless of the correlation between ((1) and PL.MM.
These theoretical guarantees demonstrate that our sampling approach provides robust statistical foundations for watermark detection while maintaining the flexibility to adjust green-red ratios as needed. The proof's rely only the properties of our sampling strategy and are independent of the specific language model or domain, showing that our method can be applied broadly across different settings and tasks. The analysis suggests that statistical testing since the sampling probabilities are precisely controlled, while the logits suittt--gdddd grouping preserves semantic relationships needed for high-quality code generation. This theoretical framework provides a principled basis for the empirical improvements we observe in practice.
achieve reliable watermark detection through
D.2
Code Quality Preservation
Code quality preservation is crucial when embedding watermarks in generated code. While water- marking inevitably modifies the original model outputs, essential to minimize degradation in functionality and quality. This section presents a theorem that formalizes how our logits- guided partitioning strategy better preserves high-utility tokens compared to random partitioning. For clarity, focus on the case where 1/2.
18

---

Theorem D.3 (Code Utility Preservation). Let (z.t)) (t))) be a binary utility function indicating whether token at position belongs to the top-k tokens by logit value:
(zx,t)= - [1, 0, otherwise
(c)()
(31)
where T& (t) denotes the set top-k tokens ranked by logits at position t. Assume we only sample from the green list G2 with watermarking bias > For k 2 2, ACW's logits-guided partitioning achieves perfect utility preservation while WLLM's random partitioning incurs non-zero utility loss.
Proof. Under ACW's logits-guided partitioning with k: 2 2, tokens are paired by consecutive rank and split between G; and R.. For each pair of tokens ranked (2i -, 2i) where i S [k/2], the higher-ranked token (2i 1) is placed in G, Therefore:
G. n (t) {ur (t(t): rank(((t):) is odd and k}
(32)
Since we sample only from G3 with watermarking bias 5 > 0, and G, contains only top-k tokens:
B[AUAww] = P(sample (t)) = 0
(33)
For WILMM with random partitioning, the number of top-k tokens in G. follows a hypergeometric distribution. Since V/ >> k. there is non-zero probability that G, contains non-top-k tokens, and when sampling from such tokens:
E [[AULM >
(34)
Therefore:
B[AUAcw] < E[AUWLIM]
(35)
E
Implementation Details
E.1
Datasets
We evaluate on standard code generation benchmarks that span multiple programming languages and tasks. The primary evaluation uses HumanEval [6] and MBPP (3) which provide comprehensive Python programming challenges with associated test cases and reference implementations. To validate framework's 's language-agnostic capabilities, we extend testing HumanEyalPPcc (26). which encompasses Java, C++, and Javascript implementations. Each dataset offers unique characteristics: HumanEval focuses algorithmic problems, MBPP targets practical programming tasks, and HumanEvalPack enables cross-language evaluation. For WPN training, we generate solutions using dataset-specific prompts and utilize these generated solutions as our training data.
E.2 Evaluation Metries
Our main evaluation framework employs two complementary metric categories to assess both code functionality and watermark effectiveness. Code functionality quantified through the Pass@k metric (6), which measures the probability of generating functionally correct code within k samples. For watermark evaluation, we utilize AUROC (Area Under the Receiver Operating Characteristic) and TPR (True Positive Rate) controlled 5% FPR (False Positive Rate).
19

---

E.3 Baselines
We compare against two categories of methods: post-hoc detection and active watermarking. Post- hoc detection methods preserve original generation and include zero-shot approaches: logp(x), LogRank (8), DetectGPT [25), and GPTZero [29] Active watermarking methods include WLLM [15]
and EXP-edit [8]. which operate under the practical constraints outlined in Section 2 We also include SWEET [9] as a reference, though comparisons are not fair since it requires access the original LLM and prompts for entropy calculation. We thoroughly tune the hyperparameters for each
baseline following their setup.
E.4
Model Design
Our model implements transformer- based architecture optimized for code analysis and generation, consisting of three main components: an embedding layer combining token and positional information, stack of transformer encoder layers, and a dual-purpose output layer. The embedding layer concatenates learnable token embeddings (Wie) and position embeddings (Wpe). both with dimension dmndel = 512, processed through dropout layer with rate 0.2 to prevent overfitting The position embeddings support sequences up to maximum length of 10 tokens, while the token embeddings' dimension is determined by the target programming language's 's vocabulary size. The transformer encoder stack comprises 6 layers, each implementing multi-head self-attention with attention heads, following pre-norm design that applies layer normalization before the attention and ferd-forward computations to enhance training stability. The ferw-fowward networks within each encoder layer expand the representation dimension 2048 before projecting back to dmodee, allowing for richer feature extraction while maintaining computational efficiency. The output layer serves a dual purpose: it generates token logits over the vocabulary space and produces switch predictions for watermark placement, implemented through final layer normalization followed by a linear projection to dimension [V/] 1, where | is the vocabulary size.
E,5
Computation Resources
The experiments are run on 2 Nvidia A100 GPUs with BF16 precision.
E.6 ACW-s
ACW-s adapts our framework to scenarios where additional information from the source LLM is available, similar the setting in [19]. While our WPN is designed plug-and-play solution that operates without access to the original LLM or prompts, ACW-s leverages this additional information when available enhance watermarking effectiveness. The key insight is that can apply our logits-guided sampling strategy directly using the LLM's logits distribution for token partitioning, rather than relying on WPN's learned approximation. In this setting, we maintain the core principle of our logits-guided sampling scheme but substitute the source LLM's token-level logits in place of WPN-generated logits. The sampling procedure remains unchanged- we still sort tokens by their logit values and assign semantically similar tokens (those with adjacent logit scores) different partitions using the PRF- IRF-generated bits. This approach preserves the key benefits of our sampling strategy maintaining semantic coherence while ensuring statistical distinguishability while benefiting from the L.LM's 's more precise token probability estimates. By leveraging the original model's 's understanding of token relationships and semantic patterns, ACW-s can achieve more natural code generation while maintaining robust watermark detection.
E.7 DetectGPT
For the DetectGPT implementation, we used T5-3B as our model. Following the original DetectGPT paper and SWEET 25 19). we set the span length words and applied masking to 20% of the text. For each test, we generated 100 perturbations ensure robust detection.
20

---

E.8 SWEET
For the SWEET baseline implementation, we conducted systematic hyperparameter search for the entropy threshold, exploring values from 0.3 to 1.2 with increments of 0.3. Our experiments revealed optimal performance with an entropy threshold of 1.2 for the HumanEval dataset and 0.3 for MBPP.
E.9 EXP-edit
We evaluate EXP-edit [88 following the methodology of [19]. In our experiments, we set temperature=0.2 and top-p=0.95. We systematically explore block sizes (20 tokens), key sequence lengths (100), resample sizes (50 runs), and edit distance thresholds (? = 0.0). Through extensive parameter tuning, determine the optimal configuration: key length 100, block size 20, 50 sam- pling runs, and detection threshold 0.1, which balances watermark detection reliability with code functionality.
F
Additional Evaluation Results
E1 Evaluation with Alternative Language Models
Setup. To validate our framework's generalizability, we evaluate using DeepSeck-Coder-1.33 instruct as the base model. We maintain consistent hyperparameters with our main experiments: watermark budget parameters 5 2.0 and 0.5, nucleus sampling with p=0.95 and tempera- ture=0.2. We test on both Evaa and MBPP benchmarks to assess performance across different code generation tasks and compare against both oracle methods requiring model access (SWEET, ACW-s) and practical watermarking approaches (WLLM, EXP-edit).
Table 7: Performance comparison of different watermarking and detection methods code generation tasks using DeepSeek- Coder. Pass measures code quality, while AUROC and TPR FPFPR evaluate watermark detection. Methods marked with require access to original L.M and prompts, making them impractical for deployment.
HvaanEval
MBPP
Category
Method
Pass@1
Pass@ 1o
AUROC
TPR
Pass@
Pass 10
AUROC
TPR
No Watermark
Base
58.42
72.36
N/A
N/A
39.41
48.83
N/A
N/A
logp(x)
58.42
72.36
51.05
6.71
39.41
48.83
56.33
4,80
LogRank
58.42
72.36
50.14
4.88
39.41
48.83
56.95
19.20
Post-hoc Methods
DetectGPT
58.42
72.36
49.75
39.41
48.83
48.10
9.20
GPTZero
58.42
72.36
56.80
8.50
39.41
48.83
41.20
1.40
SWEET
54.70
68.83
83,30
41.46
36.76
47.92
87.96
46.20
Oracle Methods
ACW-st
59.54
63.38
91.51
63.42
40.67
46.65
91.60
47.80
WLLM
52.81
69.96
69.93
25.00
33.07
46.23
83.40
44.00
Practical Watermarks
EXP-
59.30
72.41
45.17
40.16
50.25
46.54
5.40
ACW
55.39
73.64
81.53
44.51
37.88
46.83
84.09
41.80
Results.
Table reveals several key findings across both benchmarks:
For HumanEval, ACW demonstrates strong performance in the practical watermark category, achiev- ing an AUROC of 81.53% and TPR 44.51%, significantly outperforming WLLM (AUROC 69.93%, TPR 25.00%) and EXP-edit (AUROC 45.17% TPR 4.27%). While there is modest decrease in Pass @ compared to the base model (55.39% vs 58.42%), our method maintains com- petitive Pass @ 10 performance (73.64%), suggesting preserved code generation quality at higher sampling temperatures.
On MBPP, ACW maintains robust watermark detection capabilities with an AUROC of 84.09% and TPR of 41.80 41.80% while achieving @ass@1 of 37.88% compared to the base model's 39.41 This demonstrates favorable trade-off between watermark robustness and functional correctness. Notably, while EXP-edit shows slightly higher Pass@1 (40. 16%), its detection metries are substantially lower (AUROC 46.54%, TPR 5.40%), indicating poor watermark reliability.
21

---

When comparing to oracle methods, ACW-s shows superior performance across both benchmarks (HumanEval: AUROC 91.51%, TPR 63.42%; MBPP: AUROC 91.60% TPR 47.80%). This suggests that access to model internal states can enhance our framework's performance while maintaining its fundamental advantages semantic preservation.
These results demonstrate that our framework generalizes effectively to different language models while maintaining favorable balance between code fuuctiooalityy and watermark detectability. The strong performance across both benchmarks validates our approach's versatility and practical utility real-world applications.
G
Security Discussion
Our watermarking security stems from the complexity of our model-based approach and its integration with security keys through PRF. The WPN's neural network architecture learns to generate partition decisions based on code semantics and structure, making model extraction challenging through its high-dimensions
representations and semantic understanding. This model-based foundation is reinforced by PRF randomization in logits-guides sampling. making it computationally intensive for attackers to predict or manipulate watermark patterns even with extensive observation of watermarked outputs. Traditional approaches using only hash functions fixed keys for partition generation are vulnerable to statistical analysis attacks. However, our framework 's watermark patterns emerge from the interaction between trained model's semantic understanding and PRF-generated randomness, significantly raising the bar for potential attacks. An adversary would need to both reverse-engineer model's complex decision process and obtain the secret key successfully forge or remove watermarks, providing robust protection for practical deployments.
H Watermarked Code Example
Table 8: Example of watermarked code generated by framework compared won-raaermarked output. The table shows multiple programming tasks with their respective outputs.
Humaneval 161: Swap Case or Reverse String
Prompt
def solve(s):
"""You are given a string s.
if s[i] is a letter, reverse its case from lower to upper or vise versa,
otherwise keep it it is. If the string contains no letters, reverse the string.
The function should return the resulted string. Examples
solve (" ("1234") "4321"
solve ("ab") "AB"
solve ("#a0C") "#λ@с"
Continued on next page
22

---

Table continued from previous page
Reference Solution
solve(s):
fig
idx 0
new_str list(s)
in if 1.1salpha();
new new_atr [idx] 1.awapcase flg =
idx += 1 ""
for in new_str:
+= i if flg == 0: return s[=ens))::-1 return 8
def solve(s):
if isalphis))ph) for in a):
Unwatermarked
s.aaacae
else: s[:--]]
return
def solve(s):
if any any(c.isalpha() for in s): return s.swapcase
Watermarked
else: return s[::-1]
Humaneval 56: Correct Bracketing
Prompt
def perrect_bracketee (brackets: str): brackets is string of "<" and ">" return True if every opening bracket has corresponding closing bracket.
>>> correct_ (errect_bracketin((*=))
False
>>> correct_bracketing
True
>>> prreett_bracketing((ccccc.
True
>>> correct_bracketinng correct_bracketinn(>>cc)o))
False
Reference Solution
def carrect_bracketteee (brackets: str):
depth for brackets:
if b "<"; depth += 1
else:
depth
if depth return False
return depth ==
Continued on next page
23

---

Table continued from previous page
def snrrectbrrcckeinng (brackets: str):
stack [
Unwatermarked
for bracket in brackets:
if bracket =- "<":
stack app.nn
elif bracket ">":
if not stack:
return False stack.pop()
return (stack)
def correct_brccketto (brackets: str):
stack [
Watermarked
for bracket brackets:
if bracket == "<";
stack. append (bracket)
else:
if stack:
return False stack.pop()
if not stack:
return True
else:
return False
I Social Impact and Limitations
Our AST-guided code watermarking framework enhances transparency and accountability in software development by enabling reliable detection of Al-generated code without requiring LLM model access. Its impact spans the software industry, supporting intellectual property protection, ensuring code provenance in collaborative environments, and preventing academic misconduct in computer science education. As AI becomes more integrated into software development, effective code watermarking will play crucial role in fostering trust in AI coding tools by providing practical means to distinguish between human-written and Al-generated code while preserving functionality.
Despite these advantages, our approach has several limitations. The effectiveness varies across programming languages with complex type systems or ambiguous grammar rules, and our method remains vulnerable to sophisticated code transformation attacks. A potential negative societal impact of our work is that watermarking technologies could potentially be misused for surveillance to unfairly restrict code sharing in open-source communities if deployed without appropriate ethical guidelines. Future work should explore more robust watermarking techniques that can withstand extensive code modifications while maintaining detection reliability across diverse programming paradigms.
24

---

NeurIPS Paper Checklist
1. Claims
Question: Do the main claims made in the abstract and introduction accurately reflect the paper's contributions and scope?
Answer: [Yes]
Justification: Our main claims match our experimental results Section S and Appendix F with all contributions clearly stated in the introduction and supported by comprehensive evaluations.
Guidelines:
The answer NA means that the abstract and introduction do not include the claims made in the paper.
The abstract and/or introduction should clearly state the claims made, including the contributions made the paper and important assumptions and limitations. A No or
NA answer to this question will not be perceived well by the reviewers.
The claims made should match theoretical and experimental results, and reflect how much the results can be expected to generalize to other settings.
It is fine to include aspirational goals as motivation long is clear that these goals are not attained by the paper.
2. Limitations
Question:
Does the paper discuss the limitations the work performed by the authors?
Answer: [Yes]
Justification: We discuss limitations of approach in Appendix [] including considerations for edge cases in certain programming languages and potential challenges with extreme code obfuscation techniques.
Guidelines:
The answer NA means that the paper has limitation while the answer No means that the paper has limitations, but those are not discussed in the paper.
The authors are encouraged to create separate "Limitations" section in their paper.
The paper should point out any strong assumptions and how robust the results are to violations of these assumptions (e.g.. independence assumptions, noiseless settings, model well-specification, asymptotic approximations only holding locally). The authors should reflect on how these assumptions might be violated in practice and what the implications would be.
The authors should reflect on the scope of the claims made, e.g., if the approach was only tested few datasets or with few runs. In general, empirical results often depend on implicit assumptions, which should articulated.
The authors should reflect on the factors that influence the performance of the approach. For example, facial recognition algorithm may perform poorly when image resolution is low or images are taken in low lighting. Or speech-to-text system might not be used reliably provide closed captions for online lectures because it fails handle technical jargon.
The authors should discuss the computational efficiency of the proposed algorithms and how they scale with dataset size.
If applicable, the authors should discuss possible limitations of their approach to address problems of privacy and fairesss.
While the authors might fear that complete honesty about limitations might be used by reviewers as grounds for rejection, worse outcome might be that reviewers discover limitations that aren't acknowledged
the paper. The authors should use their best judgment and recognize that individual actions in favor of transparency play impor- tant role in developing norms that preserve the integrity of the community. Reviewers will be specifically instructed to not penalize honesty concerning limitations.
3. Theory assumptions and proofs
25

---

Question: For each theoretical result, does the paper provide the full set of assumptions and complete (and correct) proof?
Answer: [Yes]
Justification: We provide complete theoretical analysis with full assumptions stated, and detailed proof' are available in Appendix
Guidelines:
The answer NA means that the paper does not include theoretical results. All the theorems, formulas, and proofs in the paper should be numbered and cross- referenced.
All assumptions should be clearly stated or referenced in the statement of any theorems.
The proofs can either appear in the main paper or the supplemental material, but if they appear in the supplemental material, the authors are encouraged provide short proof sketch to provide intuition.
Inversely, any informal proof provided in the core of the paper should be complemented by formal proofs provided in appendix or supplemental material.
Theorems and Lemmas that the proof relies upon should be properly referenced.
4. Experimental result reproducibility
Question: Does the paper fully disclose all the information needed to reproduce the main ex- perimental results of the paper to the extent that it affects the main claims and/or conclusions of the paper (regardless whether the code and data are provided or not)?
Answer: [Yes]
Justification: We fully disclose code and all experimental details including datasets, metrics, baseline comparisons, and implementation details necessary reproduce our results.
Guidelines:
The answer NA means that the paper does not include experiments.
If the paper includes experiments, a No answer to this question will not perceived well by the reviewers: Making the paper reproducible is important, regardless of whether the code and data are provided or not.
If the contribution is dataset and/or model, the authors should describe the steps taken to make their results reproducible or verifiable.
Depending on the contribution, reproducibility can be accomplished in various ways. For example, if the contribution a novel architecture, describing the architecture fully might suffice, or if the contribution is specific model and empirical evaluation, it may be necessary to either make it possible for others to replicate the model with the same dataset, provide access to the model. In general. releasing code and data is often one good way to accomplish this, but reproducibility can also be provided via detailed instructions for how replicate the results, access hosted model (e.g.. in the case of a large language model), releasing of a model checkpoint, or other means that are appropriate to the research performed.
While NeurIPS does not require releasing code, the conference does require all submis- sions to provide some reasonable avenue for reproducibility, which may depend on the nature of the contribution. For example
(a) If the contribution is primarily new algorithm, the paper should make it clear how to reproduce that algorithm.
(b) If the contribution primarily a new model architecture, the paper should describe the architecture clearly and fully.
(c) If the contribution a new model (e.g.. a large language model), then there should either be way to access this model for reproducing the results or way to reproduce the model (e.g., with an open-source dataset or instructions for how to construct the dataset).
(d) We recognize that reproducibility may be tricky in some cases, in which case authors are welcome describe the particular way they provide for reproducibility. In the case of closed-source models, it may be that access to the model is limited in some way (c.g., to registered users), but it should possible for other researchers to have some path to reproducing verifying the results.
26

---

5. Open access to data and code
Does the paper provide open access to the data and code, with sufficient instruc- tions faithfully reproduce the main experimental results, described in supplemental material?
Question:
Answer: [Yes]
Justification:
Our code is available.
Guidelines:
The answer NA means that paper does not include experiments requiring code.
Please see the NeurIPS code and data submission guidelines (https://nips.co
for more details.
While encourage the release of code and data, understand that this might not be possible, so "No" is an acceptable answer. Papers cannot be rejected simply for not including code, unless this is central to the contribution (e.g., for new open-source benchmark).
The instructions should contain the exact command and environment needed to run to reproduce the results. See the NeurlPS code and data submission guidelines (https for more details.
7 //nips. htcp//blcc/gudeeeeeeeeeeieeeeeee
The authors should provide instructions on data access and preparation, including how to access the raw data, preprocessed data, intermediate data, and generated data, etc.
The authors should provide scripts to reproduce all experimental results for the new proposed method and baselines. only subset of experiments are reproducible, they should state which ones are omitted from the script and why.
At submission time, to preserve anonymity, the authors should release anonymized versions (if applicable).
Providing as much information as possible in supplemental material (appended to the paper) recommended, but including URLs to data and code permitted.
6. Experimental setting/details
Question: Does the paper specify all the training and test details (e.g., data splits, hyper- parameters, how they were chosen, type of optimizer, etc.) necessary to understand the results?
Answer: [Yes]
Justification:
We provide all the details in Appendix
Guidelines:
The answer NA means that the paper does not include experiments.
The experimental setting should be presented in the core the paper to a level of detail that is necessary appreciate the results and make sense of them.
The full details can be provided either with the code, in appendix, as supplemental material.
7. Experiment statistical significance
Does the paper report error bars suitably and correctly defined or other appropriate information about the statistical significance of the experiments?
Question:
Answer: [Yes]
Justification:
We report statistical significance for our main results in Table I
Guidelines:
The answer NA means that the paper does not include experiments.
The authors should answer "Yes" if the results are accompanied by error bars, confi- dence intervals, statistical significance tests, least for the experiments that support the main claims of the paper.
The factors of variability that the error bars are capturing should be clearly stated (for example, train/test split, initialization, random drawing of some parameter, or overall with given experimental conditions).
27

---

The method for calculating the error bars should be explained (closed form formula, call a library function, bootstrap, etc.)
The assumptions made should be given (e.g.. Normally distributed errors).
It should be clear whether the error bar is the standard deviation or the standard error of the mean.
is OK to report 1-sigma error bars, but one should state it. The authors should preferably report a 2-sigma enror bar than state that they have 96% CI, if the hypothesis of Normality of errors is not verified.
For asymmetric distributions, the authors should be careful not to show in tables or figures symmetric error bars that would yield results that are range (e.g. negative enror rates).
If error bars reported in tables plots, The authors should explain in the text how they were calculated and reference the corresponding figures or tables the text.
8. Experiments compute resources
For each experiment, does the paper provide sufficient information on the com- puter resources (type of compute workers, memory, time of execution) needed reproduce the experiments?
Question:
Answer: [Yes]
Justification: provide compute resource details in Appendix E.5
Guidelines:
The answer NA means that the paper does not include experiments.
The paper should indicate the type of compute workers CPU or GPU, internal cluster, cloud provider, including relevant memory and storage.
The paper should provide the amount of compute required for each of the individual experimental runs well estimate the total compute.
The paper should disclose whether the full research project required more compute than the experiments reported in the paper (e.g., preliminary or failed experiments that didn't make into the paper).
9. Code of ethics
Question: Does the research conducted in the paper conform, in every respect, with the NeurIPS Code of Ethics http:///uuuurppcccpoooocccccccaa
Answer: [Yes]
Justification: Our research fully conforms to the NeurIPS Code of Ethics as it addresses intellectual property protection and attribution for Al-generated code.
Guidelines:
The answer NA means that the authors have not reviewed the NeurIPS Code of Ethics.
If the authors answer No, they should explain the special cireumstances that require deviation from the Code of Ethics.
The authors should make sure to preserve anonymity (e.g.. if there is special consid- eration due to laws or regulations their jurisdiction).
10. Broader impacts
Question: Does the paper discuss both potential positive societal impacts and negative societal impacts of the work performed?
Answer: [Yes]
Justification: We discuss both positive impacts (protecting intellectual property, attribution Al Al-generated code) and potential negative impacts Appendix !
Guidelines:
The answer NA means that there no societal impact of the work performed.
If the authors answer NA or No, they should explain why their work has no societal impact why the paper does not address societal impact.
28

---

Examples of negative societal impacts include potential malicious unintended uses (e.g., disinformation, generating fake profiles, surveillance), faireess considerations (e.g., deployment of technologies that could make decisions that unfairly impact specific groups), privacy considerations, and security considerations.
The conference expects that many papers will be foundational research and not tied to particular applications, let alone deployments. However, if there is direct path to any negative applications, the authors should point it out. For example, it is legitimate to point out that an improvement in the quality of generative models could be used to generate deepfakes for disinformation. On the other hand, it is not needed to point out that a generic algorithm for optimizing neural networks could enable people to train models that generate Deepfakes faster.
The authors should consider possible harms that could arise when the technology is being used as intended and functioning correctly, harms that could arise when the technology is being used as intended but gives incorrect results, and harms following from (intentional unintentional) misuse of the technology.
If there are negative societal impacts, the authors could also discuss possible mitigation strategies (e.g., gated release of models, providing defenses in addition to attacks, mechanisms for monitoring misuse, mechanisms to monitor how a system learns from feedback over time, improving the efficiency and accessibility of ML).
11. Safeguards
Does the paper describe safeguards that have been put in place for responsible release of data models that have high risk for misuse (e.g., pretrained language models, image generators, or scraped datasets)?
Question:
Answer: [NA]
Justification:
The paper poses such risks.
Guidelines:
The answer NA means that the paper poses no such risks.
Released models that have high risk for misuse or dual-use should be released with necessary safeguards to allow for controlled use of the model, for example by requiring that users adhere usage guidelines restrictions to access the model or implementing safety filters.
Datasets that have been scraped from the Internet could pose safety risks. The authors should describe how they avoided releasing unsafe images.
We recognize that providing effective safeguards is challenging, and many papers do not require this, but we encourage authors to take this into account and make best faith effort.
12. Licenses for existing assets
Are the creators or original owners of assets (e.g.. code, data, models), used in the paper, properly credited and are the license and terms of use explicitly mentioned and properly respected?
Question:
Answer: [Yes]
Justification: We properly cite and credit all datasets and baseline methods used in experiments, with appropriate licenses noted in the Appendix.
Guidelines:
The answer NA means that the paper does use existing assets.
The authors should cite the original paper that produced the code package or dataset.
The authors should state which version of the asset is used and, if possible, include URL.
The name of the license (e.g., CC-BY 4.0) should be included for each asset.
For scraped data from a particular source (e.g., website), the copyright and terms of service of that source should be provided.
29

---

If assets are released, the license, copyright information, and terms of use in the thcode. has curated licenses for some datasets. Their licensing guide can help determine the license of dataset.
package should be provided. For popular datasets, paperswi
batasets.papersstt
For existing datasets that are re-packaged, both the original license and the license of the derived asset (if it has changed) should be provided.
If this information is not available online, the authors encouraged to reach out the asset's s creators.
13. New assets
Question: Are assets introduced in the paper well documented and is the documentation provided alongside the assets?
Answer: [NA]
Justification: The paper does not release new asserts.
Guidelines:
The answer NA means that the paper does not release new assets.
Researchers should communicate the details of the dataset/code/model as part of their submissions via structured templates. This includes details about training, license, limitations, etc.
The paper should discuss whether and how consent was obtained from people whose asset used.
At submission time, remember to anonymize your assets (if applicable). You can either create anonymized URL or include an anonymized zip file.
14. Crowdsourcing and research with human subjects
Question: For crowdsourcing experiments and research with human subjects, does the paper include the full text of instructions given to participants and screenshots, if applicable, as well as details about compensation (if any)?
Answer: [NA]
Justification: This paper does not involve crowdsourcing nor research with human subjects.
Guidelines:
The answer NA means that the paper does not involve crowdsourcing nor research with human subjects.
Including this information in the supplemental material is fine, but if the main contribu- tion of the paper involves human subjects, then as much detail as possible should be included in the main paper.
According the NeurIPS Code of Bthics, workers involved in data collection, curation, or other labor should be paid at least the minimum wage in the country of the data collector.
15. Institutional review board (IRB) approvals or equivalent for research with human subjects
Question: Does the paper describe potential risks incurred by study participants, whether such risks were disclosed to the subjects, and whether Institutional Review Board (IRB) approvals (or an equivalent approval/review based on the requirements of your country or institution) were obtained?
Answer: [NA]
Justification: Our research does not involve human subjects or data collection from individu- als.
Guidelines:
The answer NA means that the paper does involve crowdsourcing nor research with human subjects.
Depending the country in which research is conducted, IRB approval (or equivalent) may be required for any human subjects research. If you obtained IRB approval, you should clearly state this in the paper.
30

---

We recognize that the procedures for this may vary significantly between institutions and locations, and we expect authors adhere the NeurIPS Code of Ethics and the guidelines for their institution.
For initial submissions, do not include any information that would break anonymity (if applicable), such as the institution conducting the review.
16. Declaration of LLM usage
Does the paper describe the usage of LLMs if it is an important, original, or non-standard component of the core methods in this research? Note that if the LLM is used only for writing, editing, formatting purposes and does not impact the core methodology, scientific rigorousness, or originality of the research, declaration is not required.
Question:
Answer: [NA]
Justification: We did not use LLMs as component of our research methodology beyond standard evaluation procedures.
Guidelines:
The answer NA means that the core method development in this research does not involve LLMs as any important, original, non-standard components.
Please refer to our LLM for what should or should not be described.
31


Reviews:
[{"review_id": "wcjmVhIl6B", "reviewer": "Reviewer_39QH", "summary": "This paper proposes ACW (AST-guided Code Watermarking), a novel watermarking framework for LLM-generated code. ACW combines Abstract Syntax Tree (AST) analysis with a learnable Watermark Partitioning Network (WPN) to identify semantically substitutable positions for watermark insertion.", "questions": "Questions and Suggestions\n1.What is the inference latency introduced by the WPN, especially given its transformer-based design? Please quantify its runtime cost and potential bottlenecks.\n2.How should δ, γ, and α be tuned in real-world applications? Can the authors offer practical guidance on balancing detection performance with code fidelity?", "limitations": "While some limitations are briefly discussed (e.g., language generalization, WPN training), several practical concerns remain unaddressed:\n1. The need to independently implement AST parsers and transformations for each target language adds substantial engineering overhead and may limit the method’s scalability.\n2. It is unclear how detection consistency is ensured across different WPN versions or deployments — i.e., what happens when model drift occurs.\n3. The authors do not discuss how resilient the method is to adversaries attempting to reverse-engineer green-token distributions.", "rating": 4, "confidence": 4, "soundness": null, "presentation": null, "contribution": null, "strengths": "", "weaknesses": "", "quality": 3, "clarity": 3, "significance": 3, "originality": 3, "strengths_and_weaknesses": "Strengths\nBlack-box detection: No LLM weight/prompt access required.\nCode preservation: AST-guided embedding maintains functionality.\nAttack resistance: Robust to renaming and paraphrasing (DIPPER).\n\nWeaknesses\n Lack of justification for excluding recent code watermarking method such as CodeIP \nCodeIP: A Grammar-Guided Multi-Bit Watermark for Large Language Models of Code. Findings of ACL: EMNLP 2024\n Potentially underestimated training and inference overhead: WPN is a 6-layer Transformer with a 512-dimensional hidden size and must run a forward pass at every generation step. During training, n-gram grouping and entropy computation over AST-transformed code variants are required. However, the paper does not report latency or GPU usage, which could significantly increase inference cost compared to non-watermarked generation and impact real-time deployment feasibility.\n Dependence on high-quality AST transformation data: ACW relies on functionally equivalent code variants labeled by branching entropy for supervision. This necessitates accurate AST parsing and rule-based code transformations per language. In environments lacking mature parsers (or with complex macros/templates), generating high-coverage training data may be infeasible, reducing portability.\n Lack of detailed parameter sensitivity analysis: The paper uses fixed hyperparameters (δ = 2, γ = 0.5) and briefly discusses an inverse-U curve with respect to α (switch threshold). However, it does not explain how to choose optimal parameters under different code lengths, risk tolerances, or application settings. It also omits analysis of trade-offs between detection strength and potential degradation in code quality or watermark detectability.", "was_revised": true, "final_justification": "Maintain the original score.", "rebuttal": "Dear Reviewer 39QH,\n\nWe appreciate your thorough review and constructive feedback. Your concerns about practical deployment considerations are important, and we're pleased to address each point with detailed explanations and experimental evidence.\n\n------\n\n## 1. Inference Latency and Computational Overhead\n\n**Response to your concern about WPN's transformer-based design and runtime costs:**\n\nAlthough we introduce the WPN, the overhead is minimal even for large-scale deployments. Our watermark model requires **less than 0.5GB** of memory regardless of precision (full or half), representing a tiny fraction of the main model's memory footprint. For instance, this accounts for **less than 1/10 of a 1.5B model's memory and becomes even more negligible for larger models (7B, 64B)**. The context window requirement (less than 10 tokens) further limits memory usage. Most importantly, the watermarking computation **can be executed in parallel with LLM inference**, meaning the only additional costs are minimal memory usage and the delay caused by slicing operations on the vocabulary, which typically takes **less than 100 μs**.\n\n**Computational Efficiency Comparison**\n\n| Model    | Parameters | Memory Usage | Actual Delay                |\n| -------- | ---------- | ------------ | --------------------------- |\n| WPN      | 118M       | < 0.5GB      | < 100 μs (tensor slicing)   |\n| 1.5B LLM | 1,500M     | ~3-6GB       | ~500-800ms (per-token, GPU) |\n\nThis demonstrates that our approach achieves substantial performance improvements while maintaining negligible computational overhead for production deployment. The WPN's 118M parameters are minimal compared to modern LLMs, and the parallel execution design ensures real-time feasibility.\n\n**Regarding training overhead**: While training requires n-gram grouping and entropy computation over AST-transformed code variants, training is performed only once. Therefore, training complexity does not affect inference delay in production deployments.\n\n------\n\n## 2. Cross-Language Generalization and AST Parser Dependencies\n\n**Response to concerns about AST parsing complexity and language portability:**\n\nMost importantly, our approach learns generalizable rules about code syntax and structure that transfer across different programming languages. To demonstrate this crucial capability, we conducted **experiments on the HumanEvalPack dataset**, testing our model (trained exclusively on Python) on Java and C++ without any additional fine-tuning.\n\n**Cross-Language Generalization Results**\n\n| Language | Method         | Pass@1 (%) | AUROC (%) | TPR (%)   |\n| -------- | -------------- | ---------- | --------- | --------- |\n| Java     | WLLM           | 24.02      | 42.27     | 6.10      |\n|          | **ACW (Ours)** | **26.72**  | **65.31** | **24.25** |\n| C++      | WLLM           | 44.27      | 65.13     | 21.19     |\n|          | **ACW (Ours)** | **55.33**  | **78.54** | **24.62** |\n\nThese results clearly demonstrate that **ACW generalizes effectively across programming languages**, significantly outperforming practical baselines in most cases.\n\n**Regarding AST parser implementation**: Every programming language, by necessity, must have parsers to achieve compilation or interpretation—it's a fundamental requirement for any language. Moreover, as our cross-language results show, programming languages share sufficient structural similarities that transfer learning is highly effective. The strong performance can be understood intuitively: existing non-model-based approaches rely primarily on random partitioning, so even a moderately intelligent model can substantially surpass such methods.\n\nAdditionally, we believe that pretraining on large datasets with multiple programming languages can further address scalability concerns and reduce the need for language-specific implementations.\n\n------\n\n## 3. Parameter Sensitivity Analysis\n\n**Response to concerns about hyperparameter tuning guidance:**\n\nWe provide comprehensive analysis of key parameters. In our experiments, we intentionally fixed the hyperparameters as we consider them watermarking budget parameters. We fixed them to ensure fair comparisons across different green-red watermarking methods.\n\n**Delta (δ) Analysis** - As shown in Table 4 of our paper, we demonstrate the trade-off between watermark strength and code quality.\n\n**Gamma (γ) Analysis** - We conducted experiments showing the impact of different green list ratios on the detection-quality trade-off:\n\n| Gamma   | Method | Pass@1 (%) | AUROC (%) | TPR (%) |\n| ------- | ------ | ---------- | --------- | ------- |\n| γ = 0.5 | ACW    | 64.02      | 84.43     | 45.12   |\n| γ = 0.7 | ACW    | 64.18      | 78.62     | 35.25   |\n\n**Practical Guidance**: These parameters function as watermarking budget controls:\n\n- **δ (bias strength)**: Higher values increase detection accuracy but may reduce code quality\n- **γ (green ratio)**: Affects the statistical balance for detection\n- **α (switch threshold)**: Controls selective watermarking frequency, with higher values reducing watermark insertion but improving code quality\n\n**Regarding trade-offs between detection strength and code quality**: While we cannot include figures in this rebuttal, practitioners can refer to Figure 3 of SWEET [1] as a model for plotting different hyperparameter setups to find suitable trade-offs between Pass@k and AUROC metrics.\n\nThe beauty of our approach is that **any training in the correct direction improves performance** over the random baseline, making parameter optimization less critical than in other methods.\n\n[1] Who Wrote this Code? Watermarking for Code Generation, ACL 2024.\n\n------\n\n## 4. Detection Consistency Across Deployments\n\n**Response to concerns about model drift and deployment consistency:**\n\nOnce the WPN is trained, it functions as a **fixed deterministic function** paired with a security key. The detection process is entirely deterministic:\n\n1. **Fixed WPN**: The trained model parameters remain constant across deployments\n2. **Security Key**: Ensures consistent green-red partitioning using cryptographic functions\n3. **Deterministic Process**: Same input always produces same watermarking decisions\n\nThis design ensures perfect consistency across different deployments and eliminates concerns about model drift during detection.\n\n------\n\n## 5. Security Against Reverse Engineering\n\n**Response to adversarial resilience concerns:**\n\nAs detailed in **Appendix G**, our method provides robust protection against reverse engineering attempts:\n\n1. **Model Complexity**: The WPN's neural network architecture with high-dimensional representations makes model extraction computationally challenging\n2. **Cryptographic Security**: Integration with Pseudorandom Functions (PRF) and security keys makes watermark pattern prediction computationally intensive\n3. **Dual Protection**: Adversaries would need to both reverse-engineer the complex model decision process AND obtain the secret key\n\nThis multi-layered approach significantly raises the bar for potential attacks compared to traditional hash-based or fixed-key methods.\n\n---\n\n## Response to CodeIP Comparison\n\n**Regarding the exclusion of CodeIP comparison:**\n\nWe acknowledge CodeIP as an important recent work in code watermarking. However, we encountered several fundamental compatibility issues that prevented a fair comparison:\n\n1. **Dataset Compatibility**: In CodeIP Section 4.1, the authors explicitly mention that their model is not suitable for HumanEval and MBPP benchmarks, which are our primary evaluation datasets.\n2. **Context Window Limitations**: CodeIP's approach requires extensive context and cannot operate effectively within the limited context windows that our method is designed to handle.\n3. **Fundamental Setting Differences**:\n   - **Multi-bit vs. Binary**: CodeIP targets multi-bit watermarking while our approach focuses on binary detection\n   - **Prompt Dependency**: As described in CodeIP Section 3.2 (Lexical Token Type Predictor), their predictor requires access to the original prompt during detection, which contradicts our practical deployment setting where prompts are unavailable\n   - **Oracle Requirements**: CodeIP's design assumes access to generation context that our threat model explicitly excludes\n4. **Implementation Challenges**: Despite our efforts to implement CodeIP for comparison, the combination of different assumptions, requirements, and evaluation settings made it technically infeasible to establish a fair experimental comparison within our framework.\n\nWe attempted to adapt CodeIP to our experimental setting but found that the fundamental architectural and assumption differences prevented meaningful comparison. We plan to explore this comparison in future work with modified experimental protocols, but completing this analysis within the rebuttal timeframe proved technically challenging.\n\n------\n\n## Additional Comments\n\n**Baseline Simplicity**: A key insight is that our baseline (WLLM) uses completely random partitioning. In fact, **deploying an untrained WPN essentially yields WLLM performance**, demonstrating that any relevant training provides improvement. This fundamental simplicity of existing methods makes our improvements both significant and achievable.\n\n------\n\nWe believe these clarifications address your practical deployment concerns and demonstrate that ACW provides a robust, efficient, and scalable solution for real-world code watermarking applications.\n\nThank you for your thoughtful review and valuable feedback."}, {"review_id": "CHpMOdlwsS", "reviewer": "Reviewer_9ELY", "summary": "This paper presents ACW, a watermarking technique for code generation. ACW relies on the insight that traditional LLM watermarks do not work well for coding applications because code is more sensitive to token changes than regular text. Instead, ACW uses an auxiliary network to determine which tokens can be watermarked without breaking the code’s functionality, and it leverages the existing green/red watermarking technique introduced by  [16]. Through extensive evaluation, the paper demonstrates that ACW is a state‑of‑the‑art practical watermark (one that can be detected without needing the original model as an oracle) and that it has a minimal negative impact on code quality.", "questions": "Thank you for submitting your paper to NeurIPS! I really enjoyed reading your work, and I think it is a strong contribution to the watermarking space. I have one important clarification question; the remainder of my comments are guided by curiosity and are not strictly necessary to include in the paper.\n\nMain clarification: Is the WPN trained once and then used for all generations, or is it trained anew for every generation? I assume it is trained once and reused, but specifying this—as well as providing details about the training data—would be helpful for the reader. One possible concern is that if the WPN is trained on the same data used for generation, the technique might not generalize well to unseen coding tasks.\n\nOther comments:\n- The WPN is trained on prefixes that are repeated in variants of the same coding sample. This means that, at training time, the model will only see prefixes that cannot be watermarked; if they could be, the AST‑driven variants would change those prefixes to different but equivalent forms. I wonder if this might affect performance and whether introducing more diverse data could counteract this.\n- I find it interesting that the delta in Pass@1 for the larger model is smaller than for the other models. My intuition is that smaller models are less proficient at coding tasks, and their output probabilities for code tokens that cannot be changed (such as \"def\", or reusing an existing variable name) have too much entropy, meaning watermarks that do not use your technique can accidentally break the code. In contrast, larger models are better at coding, and the next‑token probabilities for such tokens have very low entropy, so even standard watermarking techniques are unlikely to choose the wrong token.", "limitations": "yes", "rating": 6, "confidence": 4, "soundness": null, "presentation": null, "contribution": null, "strengths": "", "weaknesses": "", "quality": 4, "clarity": 4, "significance": 4, "originality": 4, "strengths_and_weaknesses": "## Strengths\n- The paper is very well written and easy to read.\n- The underlying idea is simple yet effective. This design paradigm could be applied to other structured tasks where watermarking is challenging and domain knowledge about the expected structure can guide the process.\n- Performance is good, and, most importantly, code quality is largely preserved.\n- The evaluation is detailed and extensive. Multiple parameter choices are tested, and the method is compared against several baselines. I appreciate the inclusion of experiments across different programming languages.\n\n## Weaknesses\n- More details about the training data used for the WPN would be helpful.\n- A runtime performance analysis could be valuable.\n- I did not see at which FPR threshold the TPR was computed. In general, metrics such as TPR at a fixed FPR would help convey how effective the watermarks are in practical settings. I would also like to see an evaluation of how many tokens are needed to detect the watermark at a fixed FPR.", "was_revised": true, "final_justification": "I stand by my review, i think this is great, practical work, addressing a task that most watermarking schemes fail at.", "rebuttal": "Dear Reviewer 9ELY,\n\nWe sincerely appreciate your thorough review and positive evaluation of our work. Your insightful questions help us clarify important aspects of our approach. We address each of your points below:\n\n------\n\n## Main Clarification: WPN Training and Generalization\n\nThank you for this excellent question—it touches on a core aspect of our method. **The WPN is trained once and then reused for generation**, but the relationship between training data and performance is nuanced and worth explaining in detail.\n\nLet me share some key insights about this problem. The starting point for understanding our approach is quite simple: our baseline WLLM performs random partitioning and places watermarks everywhere without any intelligence. Thus, any improvement over this baseline is relatively straightforward to achieve.\n\nOur method improves upon this baseline in two key ways:\n\n1. **Good Selection**: We need some correlation with code structure. While LLM entropy works, our branching entropy is better and, crucially, doesn't require LLM access during detection.\n2. **Good Partition**: We need some correlation with good token choices, rather than random partitioning.\n\nIn fact, **if you deploy a WPN with no training whatsoever, you essentially get WLLM performance**—this demonstrates that any relevant training (learn code structure or token distribution) will bring improvement over the random baseline. This emphasizes how straightforward it is to surpass existing methods once you move beyond completely random approaches.\n\n### Cross-Domain Generalization Results\n\nBased on this understanding, our method demonstrates strong generalization capabilities:\n\n- **Cross-dataset**: Training on Python dataset 1, evaluating on dataset 2 → improvement\n- **Cross-language**: Training on Python, evaluating on other languages → improvement (in most experiments)\n- **Multi-language**: Training on mixed-language dataset, evaluating on any language → improvement\n\nThe key principle is: **the more closely aligned the training code and evaluation task, the better the performance**.\n\n**Cross-Domain Training Results**\n\n| Training Dataset                           | Evaluation Dataset | Pass@1 (%) | AUROC (%) | TPR (%) |\n| ------------------------------------------ | ------------------ | ---------- | --------- | ------- |\n| open-r1/verifiable-coding-problems-python  | HumanEval          | 63.57      | 82.51     | 42.68   |\n| **HumanEval Generated Solutions Variants** | HumanEval          | 64.02      | 84.43     | 45.12   |\n\nFor our main results, the WPN was trained on variants of generated solutions from HumanEval and MBPP questions. We generated solutions using questions from these datasets, created 10-20 AST variants per solution, segmented them, computed branching entropy, and trained the WPN accordingly.\n\n**Important clarification**: While the best results in our tables are achieved when training and evaluation domains are well-aligned, **a general WPN model still achieves good performance**. \n\n------\n\n## Runtime Performance Analysis\n\n**Computational Efficiency Comparison**\n\n| Model               | Parameters | Memory Usage | Actual Delay                |\n| ------------------- | ---------- | ------------ | --------------------------- |\n| **ACW (Ours)**      | 118M       | < 0.5GB      | < 100 μs (tensor slicing)   |\n| Baseline 1.5B Model | 1,500M     | ~3-6GB       | ~500-800ms (per-token, GPU) |\n\n**Key advantages:**\n\n- **Memory Usage**: WPN requires <0.5GB regardless of precision, representing <1/10 of a 1.5B model's memory\n- **Computational Overhead**: Watermarking computation executes in parallel with LLM inference, with the primary delay being tensor slicing operations\n- **Scalability**: Overhead becomes increasingly negligible as base model size grows\n\nThis demonstrates that our approach achieves substantial performance improvements while maintaining negligible computational overhead for production deployment. The WPN's 118M parameters are minimal compared to modern LLMs, and the parallel execution design ensures real-time feasibility.\n\n------\n\n## Token Requirements for Watermark Detection\n\n**Response to your question about how many tokens are needed to detect the watermark at a fixed FPR:**\n\nWe provide a detailed analysis of watermark density and detection requirements across our evaluation datasets:\n\n**Watermark Detection Token Analysis**\n\n| Dataset   | Avg Sequence Length | Watermark Fraction (%) | Avg Watermarked Tokens |\n| --------- | ------------------- | ---------------------- | ---------------------- |\n| HumanEval | 71                  | 28.60%                 | ~20.3                  |\n| MBPP      | 39                  | 39.53%                 | ~15.4                  |\n\nThis analysis reveals several important insights:\n\n1. **Selective Watermarking**: Our method only watermarks ~28-40% of tokens, focusing on positions where safe modifications are possible without breaking functionality\n2. **Sufficient Detection Material**: Even with selective watermarking, we achieve 15-20 watermarked tokens per code snippet on average, providing adequate statistical power for detection at 5% FPR\n3. **Quality-Detection Balance**: Higher watermark fractions (MBPP: 39.53%) indicate more watermarking opportunities in shorter, simpler code segments\n\nThe statistical detection framework requires sufficient watermarked tokens to achieve reliable detection at 5% FPR. Our analysis shows that typical code snippets provide adequate watermarked content for robust detection while maintaining code functionality.\n\n------\n\n## Evaluation Metrics\n\nRegarding the FPR threshold for TPR computation: As mentioned in line 277, we use **TPR@5%FPR** for our evaluations. This provides a practical assessment of watermark effectiveness in real-world settings where maintaining low false positive rates is crucial.\n\n------\n\n## Observation on Larger Models\n\nYour observation about the smaller delta in Pass@1 for larger models is fascinating and reveals an interesting aspect of our approach. This result actually represents a **transfer experiment**—the WPN was trained on the 1.5B model but applied to the 8B model without retraining.\n\nThis demonstrates another dimension of WPN's generalization capability: **cross-model transfer**. The 8B model performs even better than the 1.5B model with the same WPN, suggesting that larger models can better leverage the watermarking guidance provided by our trained network.\n\nHowever, cross-model generalization does have limitations—we require the same tokenizer since partitioning depends on consistent vocabulary and tokenization. Your intuition about larger models having better-calibrated probabilities for critical code tokens is insightful and likely contributes to this improved transfer performance.\n\n------\n\n## Additional Comments\n\nRegarding your observation about training on repeated prefixes: This is an astute point. While our AST-driven variants do change some prefixes, many structural elements remain consistent, providing the model with diverse examples of both watermarkable and non-watermarkable positions. The diversity comes from the interaction between different code structures and the varying contexts in which similar constructs appear.\n\n------\n\nThank you again for your thoughtful review and constructive feedback. We believe these clarifications demonstrate both the practical utility and theoretical soundness of our approach."}, {"review_id": "4nDZdQqreW", "reviewer": "Reviewer_LCcD", "summary": "This paper proposes ACW to address the trade-off between detectability and quality in code watermarking. As a low-entropy text genre, code offers limited positions for watermark insertion, creating an inherent tension between detectability and code integrity. Specifically, not every output token in code generation can embed a watermark, and even at modifiable positions, precise manipulation of model logits is required to avoid compromising code functionality. To resolve this challenge, the authors present an AST-based approach for generating and identifying watermarks in code. The method leverages AST to generate alternative code segments, enabling entropy calculation for each token that reflects its generative flexibility - watermark embedding only proceeds when this entropy exceeds a predefined threshold. Subsequently, ACW also generates logits for each token, sorts them in descending order, groups adjacent tokens as semantic equivalents, and randomly enhances one from each pair via random selection to embed the watermark. Experimental results demonstrate the method's effectiveness in code generation and its cross-linguistic generalizability.", "questions": "Can you justify why AST-assisted training would provide better entropy and logits than origianl model ones?\nAlso, provide more insights about why the performance is sometimes poorer than baselines.\nHow many alternative code segment would AST create in general?", "limitations": "yes", "rating": 4, "confidence": 3, "soundness": null, "presentation": null, "contribution": null, "strengths": "", "weaknesses": "", "quality": 3, "clarity": 3, "significance": 2, "originality": 3, "strengths_and_weaknesses": "Strengths\n1. Using AST to acquire alternative code segments is reliable and efficient.\n2. The experiments also include datasets of different programming languages.\n\nWeaknesses:\n1. ACW produces token entropy and logits based on AST-assisted training of a code dataset. It is not justified why entropy and logits from the model itself fail to achieve the same effect as those produced by ACT as they are pretty much the same concept. The dataset for training is not well explaint with detailed stats. Since the pretrained data of a code LLM is much much larger than a single dataset used here, it is reasonable to believe that the original model entropy and logits are better.\n2. The performance on pass@k for ACW is sometimes inferior to other baselines, especially for JS, and no explanation is provided.", "was_revised": true, "final_justification": "One major concern of mine is that why not use the original model entropy and logits during the watermarking process, which is well justified by the authors as model may be inaccessible sometimes due to various conerns.", "rebuttal": "Dear reviewer LCcD,\n\nWe sincerely appreciate your detailed comments and thoughtful evaluation. We believe there may be some misunderstandings regarding our approach, so we would like to provide a comprehensive point-by-point response to clarify our contributions.\n\n------\n\n## 1. AST-based vs. Original Model Entropy/Logits\n\n**Reviewer concern: \"It is not justified why entropy and logits from the model itself fail to achieve the same effect as those produced by ACW... the original model entropy and logits are better.\"**\n\n**Response:** We thank the reviewer for this important question. Our AST-based approach is primarily motivated by a critical real-world constraint: **the detector cannot access the original LLM** during deployment.\n\nAs stated in our threat model (Line 82), our system is designed for scenarios involving proprietary or API-based models, where obtaining the original model's logits or entropy at detection time is impossible. Our method is therefore not an alternative to using model logits, but rather a necessary solution for when they are unavailable—a common scenario in practical deployments.\n\nHowever, even when LLM access is available, our solution demonstrates superior performance due to several fundamental advantages. Actually, if we use original LLM information to help the detection, you can think of it as some variant of SWEET.\n\n[1] Who Wrote this Code? Watermarking for Code Generation, ACL 2024.\n\n### a) Distribution Shift and Context Mismatch\n\nLLMs and watermarking operate in fundamentally different contexts:\n\n- **Training Context**: LLMs are trained on complete texts (thousands of tokens) with full semantic context\n- **Watermarking Context**: Watermarking decisions must be made with minimal context (2-10 tokens) and often apply to code fragments rather than complete programs\n\nThis mismatch creates systematic calibration issues. To demonstrate this, we conducted additional experiments using SWEET variants under conditions that mirror our method's constraints:\n\n**Table 1: Fair Comparison with SWEET Variants**\n\n| Dataset   | Method                 | Pass@1 (%) | AUROC (%) | TPR (%)   |\n| --------- | ---------------------- | ---------- | --------- | --------- |\n| HumanEval | SWEET (No Prompt)      | 60.46      | 76.24     | 27.44     |\n|           | SWEET (Context Window) | 61.65      | 71.19     | 17.07     |\n|           | **ACW (Ours)**         | **64.02**  | **84.43** | **45.12** |\n| MBPP      | SWEET (No Prompt)      | 39.64      | 77.24     | 24.80     |\n|           | SWEET (Context Window) | 42.06      | 76.57     | 28.40     |\n|           | **ACW (Ours)**         | **41.32**  | **81.18** | **44.20** |\n\nThe results clearly show that SWEET's performance degrades significantly under realistic deployment conditions (no prompt access and limited context), while ACW maintains superior performance across all metrics.\n\n### b) Computational Efficiency\n\nOur approach offers substantial efficiency advantages:\n\n- **Memory Usage**: Our WPN requires <0.5GB regardless of precision, representing <1/10 of a 1.5B model's memory and becoming negligible for larger models\n- **Computational Overhead**: Watermarking computation can execute in parallel with LLM inference, with actual delay <100μs for tensor slicing operations\n- **Scalability**: The watermark model's overhead becomes increasingly negligible as base model size grows\n\n**Table 2: Computational Efficiency Comparison**\n\n| Model                 | Parameters | Memory Usage | Actual Delay                |\n| --------------------- | ---------- | ------------ | --------------------------- |\n| **ACW (Ours)** | 118M       | < 0.5GB      | < 100 μs (tensor slicing)   |\n| Baseline 1.5B Model   | 1,500M     | ~3-6GB       | ~500-800ms (per-token, GPU) |\n\nThis demonstrates that our approach achieves substantial performance improvements while maintaining negligible computational overhead, making it highly practical for production deployment.\n\n------\n\n## 2. Pass@k Performance and JavaScript Results\n\n**Reviewer concern: \"Performance on pass@k for ACW is sometimes inferior to other baselines, especially for JS.\"**\n\n**Response:** Thank you for this important observation. We provide clarification on two key points:\n\n### a) EXP-edit Performance Analysis\n\nThe reviewer correctly notes performance differences with EXP-edit. However, EXP-edit's results exhibit concerning instability, as also observed in SWEET [1] (page 17, Appendix E.3). This instability stems from EXP-edit being a sampling-based method that differs fundamentally from green-red watermarking approaches.\n\n**Table 3: EXP-edit Stability Analysis**\n\n| Dataset   | Method                  | Pass@1 (%) | Pass@10 (%) | AUROC (%) | TPR (%)   |\n| --------- | ----------------------- | ---------- | ----------- | --------- | --------- |\n| HumanEval | EXP-edit (original run) | 49.09      | **83.06**   | 66.50     | 25.61     |\n|           | EXP-edit (second run)   | 59.29      | 72.41       | 45.17     | 4.27      |\n|           | **ACW (Ours)**          | **64.02**  | 79.22       | **84.43** | **45.12** |\n\nOur method provides more stable and reliable performance across both functionality and detectability metrics.\n\n### b) JavaScript-Specific Analysis\n\nFor JavaScript, ACW's Pass@1 score (56.33%) is marginally below EXP-edit's (56.59%) by only 0.26%. However, ACW provides a significantly superior trade-off:\n\n- **Detection Performance**: ACW achieves AUROC of 76.94% and TPR of 22.56%, compared to EXP-edit's poor AUROC of 57.68% and TPR of 6.71%\n- **Practical Utility**: The minimal functionality difference is far outweighed by the substantial improvement in watermark reliability\n\nWe hypothesize that JavaScript's syntactic flexibility presents unique challenges for watermarking due to its diverse idiomatic patterns. Nevertheless, ACW consistently demonstrates superior balance between code functionality and watermark detectability across all tested languages.\n\n------\n\n## 3. Training Dataset Details\n\n**Reviewer concern: \"The dataset for training is not well explained with detailed stats.\"**\n\n**Response:** We appreciate this feedback and provide additional details beyond those in Appendices E.1 and B:\n\n### Dataset Composition\n\n- **Source**: Generated solutions from HumanEval and MBPP questions (not ground-truth solutions)\n- **Augmentation**: Each solution generates 10-20 AST variants through our transformations\n- **Scale**: Total training samples of ~15K-20K unique code segments from the code variants\n- **Coverage**: Diverse programming patterns including loops, conditionals, functions, and classes\n\n### Cross-Domain Evaluation\n\nWe also evaluated our method's generalizability using different training sources:\n\n**Table 4: Cross-Domain Training Results**\n\n| Training Dataset                           | Evaluation Dataset | Pass@1 (%) | AUROC (%) | TPR (%) |\n| ------------------------------------------ | ------------------ | ---------- | --------- | ------- |\n| open-r1/verifiable-coding-problems-python  | HumanEval          | 63.57      | 82.51     | 42.68   |\n\n\nThis demonstrates that our training approach generalizes well and that domain-specific training provides optimal performance.\n\n------\n\n## Conclusion\n\nOur responses demonstrate that:\n\n1. **Practical Necessity**: Our AST-based approach addresses fundamental deployment constraints that make LLM-dependent methods impractical\n2. **Superior Performance**: Even under fair comparison conditions, ACW outperforms existing methods in both functionality and detectability\n3. **Efficiency**: Our approach provides substantial computational advantages while maintaining effectiveness\n4. **Reliability**: Our method offers more stable and consistent performance compared to alternatives\n\nWe believe these clarifications demonstrate that ACW represents a significant advancement in practical code watermarking, providing an effective solution for real-world deployment scenarios where existing methods fail due to access constraints."}, {"review_id": "KTJfB5pJUk", "reviewer": "Reviewer_qYip", "summary": "In this work, the authors propose some improvement over the Green-Red approach for watermarking LLM-generated code. There are two main ideas: (1) to consider the code AST and some entropy-based selection on which tokens to apply the watermark; (2) to partition the green/red token such that valid solutions are likely present in both sets. The proposed method is evaluated against three LLMs (two of them are 1.5B and the other one 8B) and two common code benchmarks (HumanEval and MBPP) and the experimental results suggest that the proposed approach outperforms the baseline approaches.", "questions": "How do you make the WPN model (and its secret key) available for watermark detection?", "limitations": "There are no explicit discussions on the limitations of the proposed approaches. \n\nI would suggest making the following limitations explicit: (1) the approach requires a secure distribution of the WPN model (including the secret key) to work; (2) the theoretical analysis is based upon SWEET; (3) the WPN model has to be trained for each LLM.", "rating": 3, "confidence": 4, "soundness": null, "presentation": null, "contribution": null, "strengths": "", "weaknesses": "", "quality": 3, "clarity": 3, "significance": 3, "originality": 2, "strengths_and_weaknesses": "Strength\n\nThe draft is fairly easy to follow. The idea is explained sufficiently and so is the analysis of the experimental results. \n\nThe experimental evaluation is mostly well-designed and comprehensive.\n\nThe two proposed ideas are valid ones and corresponding approaches are reasonable.\n\nWeakness\n\nThe overall technical contribution of the work is not impressive. While it makes good sense to selectively (based on the number of available choices) apply the watermarking and to partition the green/red more balancely, these ideas are more incremental than ground-breaking. \n\nFurthermore, the theoretical analysis seems to be based on existing work such as SWEET.\n\nThe claimed benefit of “without requiring privileged access to the original LLM” is overrated in opinion as you will have to find a way to distribute your WPN model along with its secret key secretly anyway. Once they are leaked, an attacker can easily attack your approach adoptively to compromise the watermark.\n\nLastly, the experimental evaluation is based on three models that are mostly small. While there may be understandably resource constraint issues, the training of Watermark Partitioning Network model will be affected by the model capability I suppose and thus evaluation with large models will be relevant.", "was_revised": true, "final_justification": "While the rebuttal addresses most of the questions, such as that a separate process is needed to distribute the WPN model, my score remains the same due to the limited novelty and experimentation.", "rebuttal": "Dear Reviewer qYip, we appreciate your efforts and detailed comments very much! However, we believe that there are some misunderstandings. Therefore, we provide the following clarifications and new experimental results to address the concerns.\n\n------\n\n### 1. Technical Contribution and Innovation\n\n**Reviewer concern: \"The overall technical contribution is not impressive... ideas are more incremental than ground-breaking.\"**\n\n**Response:** We appreciate the reviewer's concern regarding novelty. We would like to clarify the significant technical advances in our work.\n\n**Building on Established Foundations:** While our work builds upon green-red watermarking, this approach has proven foundational across the field. Even recent high-impact work, including a Nature 2024 paper [1], leverages this framework. What distinguishes impactful research is not abandoning proven foundations, but rather solving critical limitations within them. Through our in-depth investigation of the code watermarking problem, we have identified and addressed fundamental limitations that arise when applying green-red watermarking to code generation—limitations that previous work has not adequately resolved.\n\n**Deep Understanding of Code Properties:** Our key innovation lies in developing a model that demonstrates **genuine understanding of code's delicate structure and semantic properties**. Unlike superficial approaches that treat code as generic text, our framework recognizes that code watermarking requires navigating strict syntactic constraints, type safety requirements, and semantic preservation—challenges that demand sophisticated understanding of programming language properties. This deep understanding enables us to solve the core problems that make direct application of existing watermarking techniques ineffective for code.\n\n**Our Technical Contributions:**\n\n- **AST-guided Watermark Positioning:** Unlike prior work [2] that selects high-entropy positions, our WPN **learns the intricate semantic structures of code** through AST analysis. This deep understanding enables identification of positions where multiple semantically equivalent alternatives exist, allowing safe watermark insertion while preserving functionality. This enables **practical deployment without requiring LLM access during detection**.\n- **Semantically-aware Token Partitioning:** We solve a fundamental problem in code watermarking where random partitioning can place all valid tokens in the red list, breaking code functionality. Our logits-guided sampling (Section 4.4) **demonstrates sophisticated understanding of token relationships**, strategically distributing semantically similar tokens while maintaining statistical distinguishability.\n\n[1] Scalable watermarking for identifying large language model outputs, Nature 2024. \n\n[2] Who Wrote this Code? Watermarking for Code Generation, ACL 2024.\n\n---\n\n### 2. Theoretical Analysis Independence\n\n**Reviewer concern: \"Theoretical analysis seems to be based on existing work such as SWEET.\"**\n\n**Response:** We think it appears to be based on a fundamental misunderstanding of our theoretical contributions. Our theoretical analysis is **independent** of SWEET and addresses entirely different problems:\n\n**Clear Distinction in Theoretical Scope:**\n\n- **SWEET's theory:** SWEET provides only one theorem, which establishes a lower bound on the z-score for their specific detection method compared to WLLM.\n- **Our theory:** Our analysis (Section 4.6, Appendix D) develops novel theoretical foundations for our logits-guided sampling strategy, addressing fundamentally different questions.\n\nOur theoretical contributions are **completely unrelated** to SWEET's work and represent original analysis of our novel methodological innovations. We believe this distinction is crucial for understanding the independent nature of our theoretical foundations.\n\n---\n\n### 3. Security Model and Practical Deployment\n\n**Reviewer concern: \"WPN model and secret key need to be distributed secretly anyway... an attacker can easily attack your approach adaptively.\"**\n\n**Response:** We think this concern misunderstands the fundamental distinction between LLM access and WPN access. Our approach offers significant practical advantages:\n\n**Critical Distinction - LLM vs. WPN Access:**\n\n- **LLM access:** Requires exposing valuable, proprietary models that companies must keep private. LLMs contain sensitive training data, architectural details, and represent substantial intellectual property that cannot be shared.\n- **WPN access:** Our lightweight model contains no proprietary information and can be safely distributed. Even if the WPN model is leaked, **the system remains secure as long as the secret key is protected**.\n\n**Standard threat model**: Following established practices in digital watermarking (as outlined in our threat model, Line 92), we operate under the industry-standard assumption that secret keys remain secure. This is the same assumption used by **all** watermarking methods.\n\n**Better Distribution Method (API-based detection service)**: For organizations with heightened security concerns, our approach enables an even more secure deployment model—providers can offer watermark detection as an API service, retaining both the WPN model and cryptographic key while providing detection results to users. This eliminates any distribution concerns entirely while maintaining practical utility.\n\n**Enhanced Security Properties:** Appendix G demonstrates that our model-based approach provides additional resistance to statistical attacks compared to simple hash-based methods, further strengthening security.\n\n---\n\n### 4. Evaluation on Larger Models\n\n**Reviewer concern: \"Evaluation is based on three models that are mostly small.\"**\n\n**Response:** We acknowledge this concern and appreciate the opportunity to clarify our evaluation scope.\n\n**Practical Considerations and Validation:** \n\n1. **Substantial model size**: An 8B parameter model represents a substantial scale that is widely used in practical applications and academic research. This scale is sufficient to validate our approach's effectiveness and transferability to larger models. And we think 8B code model already show enough capabality to solve code problems.\n\n2. **Computational constraints**: Due to limited computational resources, we cannot afford to evaluate on models larger than 8B parameters. However, our evaluation demonstrates meaningful validation, and the successful transfer from 1.5B to 8B models provides strong evidence of scalability to larger models.\n\n---\n\n### 5. Addressing Claimed Limitations\n\n**Reviewer concern: There are no explicit discussions on the limitations of the proposed approaches.\"**\n\n**Response:** We have the explict discussions on limitations in Appendix I.\n\n**Limitation (1): \"The approach requires secure distribution of the WPN model (including the secret key) to work\"**\n\n**Response:** This has been addressed in Answer 3 above. \n\n**Limitation (2): \"The theoretical analysis is based upon SWEET\"**\n\n**Response:** This is completely incorrect, as detailed in Answer 2 above. \n\n**Limitation (3): \"The WPN model has to be trained for each LLM\"**\n\n**Response:** This is factually incorrect. As demonstrated in Line 310-318 and Table 3, our WPN trained on a 1.5B model successfully transfers to an 8B model without retraining, achieving 81.22% AUROC compared to WLLM's 65.90%. This **contradicts** the claimed limitation and actually demonstrates the **transferability advantage** of our approach. The only requirement is that models share the same tokenizer, which is common in model families.\n\n---\n\n### 6. Addressing Detailed Comments\n\n**Comment 1: \"This criticism is unnecessarily harsh given the effort on making these methods tamper-resistant through coding theory...\"**\n\n**Response:** We sincerely appreciate this feedback and acknowledge that our language may have been overly critical. We deeply respect the original contributions of prior work—they have been tremendously inspiring and foundational to our research. While \"easier to apply\" is certainly a valuable advantage, we believe that for watermarking evaluation, the primary criteria should be detection performance and minimal impact on code functionality.\n\n**Comment 2: \"This argument assumes that it has to be a for/while loop, while in fact, it might be possible to have a conditional expression...\"**\n\n**Response:** Thank you for this thoughtful observation. Our example was intended to illustrate a specific scenario rather than suggest universal correctness requirements. We aimed to express the case where the LLM's candidate token list contains only `for` and `while` as viable options for a particular context, not that these are the only possible constructs. \n\n**Comment 3: \"These abbr. forms (WPN and ASTs) have been introduced and used already by this point.\"**\n\n**Response:** Thank you for catching this inconsistency. We will ensure proper abbreviation usage in the revised version.\n\n**Comment 4: \"These paraphrasing approaches are rather limited... I would suggest adopting a capable LLM, such as GPT, to refactor the code...\"**\n\n**Response:** This is an excellent suggestion. We conducted additional experiments using GPT-4 to perform sophisticated code refactoring with the explicit goal of evading watermark detection. The results demonstrate our method's robustness against more advanced attacks:\n\n| Attack          | Metric | WLLM  | EXP-edit | ACW       |\n| --------------- | ------ | ----- | -------- | --------- |\n| Original        | AUROC  | 70.17 | 66.50    | **84.43** |\n|                 | TPR    | 20.73 | 25.61    | **45.12** |\n| GPT Refactoring | AUROC  | 65.43 | 63.42    | **69.21** |\n|                 | TPR    | 13.41 | 10.11    | **17.62** |\n\n---"}]

Author rebuttal:

Meta-review: This paper introduces ACW (AST-guided Code Watermarking), which is designed for watermarking LLM-generated code in a black-box setting (i.e. no access to logits). The core idea is to use Abstract Syntax Trees (ASTs) to guide the watermarking process. By training a small model (the Watermark Partitioning Network) on AST-derived features, the system learns to identify positions in the code where a watermark can be embedded without breaking functionality.

The paper's primary strengths are its interesting domain-specific approach for code (which is challenging) and its large amount of empirical validation, which was strengthened during the review. The approach achieves strong detection rates while preserving code functionality.

The initial submission had some unanswered questions, such as its computational overhead and its ability to work across different languages and model sizes. However, the rebuttal addressed these points with new experiments that mostly satisfied reviewers. They demonstrated that the overhead is negligible, that the method works well in other languages.

Overall this is a complete paper and is technically sound with an interesting and effective idea.
Decision: Accept (poster)