PaperlayerView exact revision on arXiv

Source-linked AI summary

Who Wrote this Code? Watermarking for Code Generation

Taehyun Lee, Seokhee Hong, Jaewoo Ahn, Ilgee Hong, Hwaran Lee, Sangdoo Yun, Jamin Shin, Gunhee Kim

arXiv:2305.15060v4cs.CL

TL;DR

Existing watermarking and post-hoc detection methods do not function appropriately for low-entropy code generation, where watermarking can impair functionality or remain difficult to detect. The paper proposes SWEET, which selectively applies entropy-thresholded watermarking, and reports improved detection with less code-quality degradation than WLLM. The method also demonstrates practical applicability without prompts, with smaller surrogate detectors, and under paraphrasing attacks.

  • Problem

    Existing watermarking and post-hoc detection methods fail to operate appropriately for low-entropy code generation, while reliable detection is important for deploying coding-capable LLMs fairly.

  • Method

    SWEET extends logit-modifying watermarking by applying the green-red rule only to tokens whose entropy exceeds a threshold.

  • Results

    SWEET improves both watermark detectability and code-quality preservation relative to existing methods, including WLLM, in code-generation tasks.

  • Takeaways & Limitations

    SWEET maintains practical performance without prompts, with a smaller surrogate detector, and under paraphrasing attacks.

  • Takeaways & Limitations

    SWEET requires entropy-threshold tuning and operates in a white-box setting, so detection may impose computational burdens for some users.

Abstract

from arXiv · show

Since the remarkable generation performance of large language models raised ethical and legal concerns, approaches to detect machine-generated text by embedding watermarks are being developed. However, we discover that the existing works fail to function appropriately in code generation tasks due to the task's nature of having low entropy. Extending a logit-modifying watermark method, we propose Selective WatErmarking via Entropy Thresholding (SWEET), which enhances detection ability and mitigates code quality degeneration by removing low-entropy segments at generating and detecting watermarks. Our experiments show that SWEET significantly improves code quality preservation while outperforming all baselines, including post-hoc detection methods, in detecting machine-generated code text. Our code is available in https://github.com/hongcheki/sweet-watermark.

1 Introduction

LLMs improve coding productivity but raise legal, ethical, and security concerns, creating a need for reliable machine-generated code detection. Existing watermarking and post-hoc methods struggle with low-entropy code, while SWEET selectively watermarks higher-entropy tokens to balance detectability and functionality.

  • LLMs have advanced toward expert-like software proficiency, improving engineering productivity and lowering barriers for non-experts.
  • Machine-generated code raises concerns including licensing, plagiarism, vulnerabilities, and malware, making reliable detection important for fair deployment.
  • Existing watermarking and post-hoc detection methods transfer poorly to code because low entropy limits detectable watermark embedding without impairing functionality.
  • Strong watermarking can break code through incorrect tokens, whereas weak watermarking may produce too few green tokens for reliable detection.
  • SWEET applies the green-red rule only to tokens above an entropy threshold, protecting functionally important tokens while watermarking less important ones.
  • SWEET achieves higher machine-generated code detection performance than WLLM while preserving code quality more effectively, including without prompts, with smaller detectors, and under paraphrasing attacks.

2 Related Work

Software watermarking embeds secret signals in code, while LLM text watermarking increasingly modifies tokens during sampling. Existing watermark detection is vulnerable in low-entropy settings, motivating methods designed for code generation.

  • Software Watermarking: Software watermarking embeds a secret signal in code to prevent software piracy without affecting performance.
  • Software Watermarking: Static watermarking modifies code through replacement or reordering, whereas dynamic watermarking injects signals during compilation or execution.
  • Software Watermarking: Watermarking LLM-generated code is closer to static watermarking, including methods that replace synonymous code but depend heavily on language-specific rules.
  • LLM Text Watermarking: Most LLM text watermarking methods modify original text using predefined rules, another language model, or token-level sampling procedures.
  • LLM Text Watermarking: Existing watermark methods show degraded detection performance in low-entropy situations, including code generation, while CTWL is among the limited studies addressing this issue.
  • Post-hoc Detection: Post-hoc detectors distinguish human-authored from machine-generated text using perplexity features, fine-tuned language-model classifiers, or methods requiring no additional training.

3 Method

SWEET selectively applies watermarking to high-entropy code tokens, avoiding low-entropy tokens that are important for functionality while retaining detectable green-token signals. Its entropy threshold improves detectability, but thresholds that exclude too many tokens can reduce watermarking strength.

  • 3.2 The SWEET Method: SWEET applies the green-red watermarking rule only to tokens whose entropy exceeds a threshold.Low-entropy tokens are excluded during both generation and detection.
  • 3.2 The SWEET Method: The method avoids promoting green tokens for low-entropy positions, preserving tokens that are important for functional code.This targets the quality degradation caused when watermarking strongly alters constrained code-token choices.
  • 3.1 Motivation: In the HumanEval/4 example, SWEET improves code quality and z-score over WLLM, while a moderate threshold peaks in z-score and higher thresholds reduce it.The decline at higher thresholds is attributed to a lower watermarking ratio.
  • 3.2 The SWEET Method: SWEET computes detection statistics over high-entropy tokens and classifies a sequence as watermarked when its z-score exceeds a cutoff.The detector counts high-entropy tokens and their green-token subset before computing the z-score.
  • 3.3 Effect of Entropy Thresholding: Ignoring low-entropy tokens increases the green-token ratio and yields a higher lower bound on the z-score than WLLM under the theorem’s assumption.The assumption requires selecting a threshold that does not ignore too many low-entropy tokens.

4 Experiments

The experiments evaluate SWEET’s code-quality preservation and detection strength across code-generation benchmarks and compare it with post-hoc and watermarking baselines. They use pass@k for functional quality and AUROC, with additional evaluation across models, datasets, and software-development contexts.

  • 4 Experiments: The evaluation measures both functional quality preservation and machine-generated-code detection strength.StarCoder is the main base model, with additional LLaMA2 experiments reported in the appendix.
  • 4 Experiments: HumanEval, MBPP, and DS-1000 serve as the main Python code-generation testbeds, with HumanEvalPack and ClassEval extending evaluation to diverse contexts.The tasks provide programming problems, test cases, and canonical human-written answers.
  • 4 Experiments: Pass@k estimates the percentage of correctly functioning generated programs, while AUROC is the main detection metric and TPR is also reported at fixed FPR.These metrics separately assess code functionality and detection ability.
  • 4.2 Baselines: The baselines include zero-shot and trained post-hoc detectors, plus watermarking methods such as WLLM; post-hoc methods do not modify generation and therefore do not impair output quality.EXP-EDIT is also expected not to degrade quality because it does not distort the sampling distribution.
  • 4.2 Baselines: Table 1 calibrates WLLM and SWEET across the detection-quality trade-off by selecting best AUROC near 90% of non-watermarked pass@1 and best pass@1 among AUROC ≥0.9.The table reports separate settings for detection and quality priorities.

5 Results

SWEET improves machine-generated code detection while preserving more code functionality than watermarking and post-hoc baselines. Across programming languages and parameter settings, it achieves a stronger detection–quality tradeoff.

  • Detection Performance: SWEET outperforms all baselines in detecting machine-generated code at roughly 10% code-functionality degradation.It achieves AUROC 0.873 on MBPP and 0.815 on DS-1000, while baselines remain below 0.8.
  • Detection Performance: AUROC reaches 0.943 on HumanEval with only 2.4% degradation of code functionality.Under approximately 10% degradation, WLLM has lower detection performance than SWEET.
  • Detection Performance: None of the post-hoc detection baselines exceeds AUROC 0.6, despite preserving code functionality because they do not modify generated code.EXP-EDIT also fails to exceed AUROC 0.6 in all cases, including its high-entropy setting.
  • Code Quality Preservation: SWEET loses 2.4%, 12.2%, and 28.5% pass@1 on HumanEval, MBPP, and DS-1000, respectively, versus larger WLLM losses.WLLM loses 24.3%, 36.0%, and 67.3% on the same datasets.
  • Cross-Language Results: On C++ and Java class-level generation, SWEET generally preserves more functionality than WLLM and has the highest detection performance except Java TPR.In Java, WLLM’s TPR exceeds SWEET’s.
  • Pareto Frontiers: SWEET’s Pareto frontier leads WLLM’s across HumanEval, MBPP, and DS-1000, and this advantage persists across entropy-threshold configurations.Figure 3 uses entropy threshold 1.2; Figure 6 covers all threshold values.

6 Analysis

Entropy-threshold calibration creates a quality–detection tradeoff: higher thresholds preserve generation quality but can eventually reduce detection. Detection also weakens when prompts are unavailable or code variables are extensively renamed, although SWEET remains ahead of baselines.

  • Entropy Threshold Calibration: Higher entropy thresholds increase pass@1 toward the non-watermarked model, while detection AUROC first rises and then declines.Few watermarked tokens at very high thresholds reduce detection ability.
  • Detection Without Prompts: SWEET with general prompts has lower AUROC than original SWEET because inaccurately approximated entropy impairs detection.It nevertheless remains ahead of WLLM across entropy thresholds.
  • Surrogate Detection: A LLaMA2-7B surrogate detector causes insignificant detection-performance declines when detecting code watermarked by LLaMA2-13B.The authors associate this preservation with the models’ identical training corpus.
  • Paraphrasing Robustness: All watermarking methods lose AUROC as variable renaming increases, while SWEET remains better than baselines.When all variables are renamed, SWEET’s AUROC drops to about 0.8 because variable names comprise many high-entropy tokens.

7 Conclusion

The paper formalizes code LLM watermarking and identifies low entropy as the source of failures in existing approaches. SWEET selectively thresholds entropy to improve detection while reducing code-quality degradation, including under several practical conditions.

  • Conclusion: The work formalizes the need for watermarking code LLMs to support safer deployment amid legal, ethical, and security concerns.The authors describe this need as previously unimplemented despite advances in coding capability.
  • Conclusion: Existing watermarking and detection techniques fail in code generation through inadequate watermark embedding or impaired code execution.SWEET filters tokens least relevant to execution quality using selective entropy thresholding.
  • Conclusion: SWEET performs better than baselines, including post-hoc detection methods, while causing less code-quality degradation.The conclusion also reports effectiveness without prompts, with a smaller surrogate model, and under paraphrasing attacks.

Limitations

The paper identifies robustness, watermark forgery, entropy-threshold calibration, and source-LLM dependence as limitations requiring mitigation or additional computation.

  • Robustness against paraphrasing attacks remains incomplete, with further enhancement left for future work.
  • Watermark forgery is possible if attackers recover the watermarking rules through brute-force mechanisms.The paper suggests conditioning list division on prior tokens or using SelfHash to improve security.
  • Entropy-threshold tuning is still needed for best performance and incurs computational cost.The authors report broad threshold robustness and discuss calibration methods, but do not eliminate tuning.
  • SWEET requires the source LLM during detection, although a smaller surrogate model can preserve performance to some degree.This white-box requirement may burden users with limited computational resources.

Ethical Statement

The paper frames watermarking as a response to misuse risks while describing the operational pipeline for generating and detecting watermarks and evaluating it across code benchmarks.

  • Watermarking can create a new misuse risk if its mechanism is publicly exposed and abused to embed authentic-looking watermarks in unethical text.The authors recommend caution about exposing detailed mechanisms.
  • WLLM randomly partitions vocabulary tokens into green and red groups and increases green-token logits during generation.The resulting text is expected to contain more green-list tokens than the baseline proportion γ.
  • Detection applies a one-sided z-test to the number of recognized green tokens, classifying text as watermarked when z exceeds zthreshold.A higher zthreshold lowers the false-positive rate and reduces Type I errors.
  • SWEET computes token probabilities and entropy, applies selective watermarking using an entropy threshold, and recovers green/red lists from hashed preceding tokens.Its generation and detection procedures are specified in Algorithms 1 and 2.
  • The experiments evaluate HumanEval, MBPP, DS-1000, and C++ and Java subsets of HumanEvalPack under specified sampling and hyperparameter settings.The main Python benchmarks contain 164, 500, and 1000 problems, respectively.

E.3 Results

SWEET maintains strong detection and code functionality across C++ and Java and achieves the highest AUROC in the longer, more complex ClassEval setting.

  • SWEET outperforms all baselines in detecting machine-generated C++ and Java code while preserving functionality better than WLLM.Its Pareto frontier also remains ahead of WLLM’s in these languages.
  • The C++ and Java results suggest SWEET’s efficacy is not limited by programming language or code length.Average lengths are 100 tokens for C++, 97 for Java, and 57 for Python.
  • As code becomes longer, post-hoc detection performance increases, while EXP-EDIT performs worse than in the high-entropy setting.

F Further Pareto Frontier Results on StarCoder/LLaMA2

Across decoding conditions, models, code lengths, and benchmark settings, SWEET generally provides a favorable detectability–functionality tradeoff, while threshold calibration and computation remain practical considerations.

  • Further Pareto Frontier Results on StarCoder/LLaMA2: At temperature 0.8 with 200 HumanEval outputs, SWEET remains consistently on the Pareto frontier, with AUROC ranges similar to temperature 0.2.The higher temperature raises pass@100 relative to pass@1 without heavily changing detection strength.
  • Further Pareto Frontier Results on StarCoder/LLaMA2: SWEET achieves higher AUROC than all baselines with LLaMA2 13B while preserving more code quality than WLLM.This extends the method beyond code-specific language models to a general-purpose LLM.
  • Further Pareto Frontier Results on StarCoder/LLaMA2: SWEET reaches AUROC 1.0 once HumanEval and MBPP code exceeds 70 tokens, whereas no baseline reaches that score.Its superior detection performance also appears in short code texts.
  • Further Pareto Frontier Results on StarCoder/LLaMA2: A corpus-based calibration procedure finds the highest pseudo-z′ in the entropy-threshold interval [0.820, 0.871].The authors describe one forward pass over the corpus as the computational cost of this calibration.
  • Further Pareto Frontier Results on StarCoder/LLaMA2: SWEET requires one forward pass to calculate entropy, while DetectGPT uses many forward passes and EXP-EDIT requires O(mnk^2) computation plus T = 500 test-statistic repetitions.A smaller surrogate model can make SWEET computationally more efficient, though EXP-EDIT avoids LLM inference.
  • Further Pareto Frontier Results on StarCoder/LLaMA2: Higher entropy thresholds increase NAME tokens from 26%p to 63%p, creating vulnerability to attacks that change variable names.Below the threshold, NAME and RESERVED proportions do not increase, while INDENT rises from 18%p to 22%p.

K Further Analysis of Breakdown of Post-hoc methods

Post-hoc detectors perform poorly on machine-generated code because classifiers face out-of-domain issues, code blocks are short, and DetectGPT cannot reliably estimate perturbation curvature.

  • None of the post-hoc baselines exceeds 0.6 AUROC on HumanEval or MBPP, while TPR is around 10% or lower.
  • Out-Of-Domain for classifiers: Trained classifiers such as GPTZero and OpenAI Classifier suffer from out-of-domain issues for machine-generated code.The authors conjecture that insufficient machine-generated-code examples may limit classifier training.
  • Relatively Short Length of Code Blocks: Short generated code blocks challenge post-hoc detectors designed for near-paragraph-length text or texts longer than 1,000 tokens.Length is also a prime factor in WLLM-based detection and the detectability@T metric.
  • Relatively Short Length of Code Blocks: Intentional watermark signals may help with short code, whereas post-hoc methods struggle to detect it without embedded signals.
  • Failures in DetectGPT: DetectGPT fails because code rephrasing often preserves the original line or breaks functionality, producing poor perturbation-curvature estimates.The authors also attribute difficulty to unsatisfactory code-generation performance by the base and masking models.
Loading 2305.15060v4…