As of this month, Claude watermarks its text output. Anthropic's documentation is direct about the mechanism: for text, "it weaves an imperceptible watermark directly into the text itself." For files, it attaches signed provenance metadata following the C2PA standard. That is worth reading as a systems fact rather than a policy announcement. A watermark is not a label attached to a document. It is an intervention in the sampling loop. Something is changing which token gets emitted, and that is a different kind of object from a metadata field.
The interesting question is what happens when the artifact being marked is a program.
What a token watermark actually does
The canonical construction is Kirchenbauer et al.'s green-list watermark. At each generation step, you hash the preceding token under a secret key, use that hash to pseudorandomly partition the vocabulary into a "green list" (some fraction γ of tokens) and a "red list," then add a constant δ to the logits of every green token before the softmax:
# 1. Seed a PRNG from the previous token under the watermark key.
rng.manual_seed(hash_key * prev_token_id)
# 2. Pseudorandomly split the vocabulary. Green gets gamma of the tokens.
green_ids = torch.randperm(vocab_size, generator=rng)[: int(gamma * vocab_size)]
# 3. Nudge green tokens up before sampling. This is the entire intervention.
logits[green_ids] += delta
next_token = sample(softmax(logits))Detection needs no model. Re-derive the partition at each position, count how many emitted tokens landed in green, and run a z-test against the γ you would expect by chance. A long enough passage from a watermarked model shows a green fraction far above γ. Unwatermarked text does not.
Google's SynthID-Text, the only production system with a peer-reviewed description, replaces the additive bias with tournament sampling: draw several candidate tokens, run them through keyed pairwise tournaments, and emit the winner. In one configuration the scheme is non-distortionary, meaning the output token distribution matches the unwatermarked model's.
"Non-distortionary" is a weaker promise than it sounds
Non-distortionary means the distribution is preserved. It does not mean you get the same output. A watermark is an active intervention. It arbitrages which code patterns get selected. You might have two equally valid ways to structure a loop or initialize a struct. Both are legitimate draws from the unwatermarked distribution. The watermark tilts the sampler toward the one that hashes into the green list.
This affects the actual code generated. And code patterns age poorly. An idiom that looks safe today becomes tomorrow's vulnerability when a new compiler optimization or attack surface is discovered. Because the watermark steered the generation toward specific patterns to construct its signal, the originator knows exactly which choices were made. If one of those patterns is later found to be vulnerable, the originator knows about all the places that have those vulnerabilities.
Entropy is the whole game
A watermark is a signal smuggled into your choice among tokens. That only works when there is a choice. Kirchenbauer et al. make this explicit: the "hard" watermark that simply forbids red-list tokens fails badly, because for low-entropy sequences where the next token is nearly deterministic, hard watermarking may prevent the model from producing it at all. The soft watermark, with its finite δ, exists so that a sufficiently confident model can still overrule the bias and emit the red token it was going to emit anyway.
Read as a design constraint, that says something sharp: a watermark is only free when the model was uncertain. Where the model is confident, you either corrupt the output or you skip it. Every credible scheme skips it.
The consequence is measured. An independent analysis of SynthID-Text notes that "in regions where entropy is low, watermarking is typically less effective, which is also advantageous for the attacker," and reports that all existing methods perform poorly on short text. SynthID-Text reaches only about 0.3 true-positive rate at a 1% false-positive rate on 50-token passages.
Source code is a low-entropy artifact with high-stakes tokens
Prose is forgiving because it is redundant. Swap "however" for "but" and the paragraph survives. That redundancy is the entropy the watermark lives in. Code is not like that. Enormous stretches are nearly deterministic given context, and a large share of the positions where the model is confident are the positions that carry the semantics:
// 1. '<' vs '<=' -- one token, one overflow
for (size_t i = 0; i <= n; i++)
dst[i] = src[i];
// 2. '&' vs '&&' -- one token, one segfault
if (p != NULL & p->len > 0)
use(p);
// 3. 'memcpy' vs 'memmove' -- one identifier, one UB
memcpy(buf, buf + 4, len);
// 4. 'int' vs 'size_t' -- one token, changes comparison meaning
int len = get_length();
if (len < MAX) copy(buf, src, len); /* negative len passes the check */Each is a single-token difference. Each compiles. Each is a well-known CWE. And in each case the surrounding context makes the model quite confident about which token it wants, which is to say these are the low-entropy positions where a watermark has nowhere to hide.
That gives two horns, and they are not symmetric:
- If a scheme perturbs high-confidence positions, it can flip a semantically load-bearing token, and in code there is no such thing as a harmless synonym. Well-designed schemes avoid this, which is why the soft watermark exists at all.
- If a scheme does not perturb high-confidence positions (the correct engineering choice, and what every credible construction does), then it carries almost no signal in code. Not a little less than in prose. Qualitatively less, because the low-entropy fraction of a program is so much larger.
The second horn is the true one, and it is worse for the industry than the first.
The failure mode is institutional, not cryptographic
Watermarking is strongest on long, high-entropy, redundant text and weakest on short, low-entropy, structured text. Code is short, low-entropy, and structured. So the provenance signal is weakest on the artifact class where the provenance question has real consequences, and it is arriving as regulation, procurement, and CI pipelines start to build policy on top of it.
The vulnerability watermarking introduces into software is a false negative that reads as a clean bill of health. "We scanned the PR and found no AI watermark" is not evidence that a human wrote it. For a 40-line function it is barely evidence of anything. Any gate inherits a detector whose miss rate on its most important input class is enormous, and inherits it silently.
Four other properties compound it:
- Scrubbing is trivial for code. Stripping a watermark from an essay means paraphrasing it. Stripping it from a program means running the formatter. gofmt, black, rustfmt, and prettier rewrite whitespace and token layout wholesale; a rename pass changes identifiers. All preserve semantics exactly and demolish a token-sequence statistic.
- Detection is an oracle, and oracles cut both ways. Anyone who can run detection against a repository can label which regions are model-generated. That is a targeting signal. An attacker who knows which subsystems were machine-written knows where to look first.
- The key holder can enumerate; nobody else can. Detection requires the watermark key, and the originator holds it. A provider already knows what it generated from request logs. What a watermark adds is recognition of your own output after it has left your infrastructure.
- Spoofing inverts attribution. A watermark proves a statistical property of a token sequence, not authorship. The interesting abuse is laundering deliberately introduced human-written flaws as "just AI output."
A watermark is a census, not a certificate. It tells you which regions of a codebase were machine-written, which is exactly the map an adversary wants. Provenance transparency is not free; it tells your adversary something too.
Thompson settled this in 1984
Suppose every objection above were answered. Suppose detection is flawless, scrubbing impossible, spoofing infeasible, and every line of machine-written code in your repository is reliably attributable. You still know nothing about whether the code is correct.
Provenance and correctness are orthogonal axes, and the industry is midway through a large, well-funded, regulation-driven push along the axis that does not carry the risk. A perfect watermark on a buffer overflow tells you a machine wrote the buffer overflow. The overflow is unaffected.
Ken Thompson made the stronger version of this point in his Turing Award lecture, which opens by asking "to what extent should one trust a statement that a program is free of Trojan horses? Perhaps it is more important to trust the people who wrote the software." He then builds an attack in three stages, and the payload is a login backdoor: the compiler miscompiles the login command so that it accepts either the intended encrypted password or a particular known password.
Provenance and correctness are orthogonal axes. A perfect watermark on a buffer overflow tells you a machine wrote the buffer overflow. The overflow is unaffected.