Claude's Watermarking Policy Extends to Code

11 August 2026 at 14:35~ 7 min read

A Claude Code patch may now carry an extra requirement that has nothing to do with the software: it must remain detectable as Claude output.

Anthropic says supported Claude models will embed an imperceptible watermark in all generated text. The policy applies across the API, Claude, Claude Code, Claude Cowork and Claude Tag, worldwide. That could provide useful provenance, but source code is a poor place to introduce an undocumented generation constraint.

The concern is not that a watermark must make code worse. It is that Anthropic has not yet published enough technical detail or comparative testing to show that it does not.

What Anthropic has announced

Anthropic’s help article on AI-generated content describes two forms of marking:

an embedded, model-level watermark for generated text
signed C2PA provenance metadata for supported file types such as SVG, PNG and JPEG

Anthropic says the text watermark is invisible, survives copying and pasting, may survive some editing, and does not change the meaning, quality or readability of a response. A future detector will let users and third parties check for the mark.

This does not mean every Claude Code response is marked today. Models launched in the EU on or after 2 August 2026 are meant to support marking from launch, while support for older models is still being added. Very short passages may not contain enough information for reliable detection, and some platforms or features may not support every marking type.

The article does not explicitly say “source code”. It says the watermark applies to all generated text and names Claude Code as a covered product. The natural reading is that source code from a supported model is included, but the promised technical documentation needs to confirm the exact boundary.

This goes further than the EU rule

Anthropic presents the change as part of its commitment to the EU AI Act’s Code of Practice on Transparency of AI-Generated Content. The provider marking obligations started to apply on 2 August 2026.

The law is not forcing Anthropic to watermark source code. The European Commission’s final Article 50 guidance puts source code outside the marking obligation. Its exclusion covers programming, scripting, markup, query and configuration languages, and explicitly includes SQL, infrastructure as code, YAML, JSON, APIs and software libraries.

Applying one policy to every product and region is operationally simpler. It also avoids a patch being marked in one country and unmarked in another. But extending the watermark to code is an Anthropic product decision, not an unavoidable legal requirement.

A text watermark does not necessarily add hidden characters

“Embedded” can sound like zero-width characters, comments or padding added after generation. Anthropic has not said that it uses any of those techniques. It says the mark is applied at model level and that more technical guidance will follow.

Many published text watermarking methods instead influence which tokens the model selects. A simplified model looks like this:

scores = model(prompt, previous_tokens)
scores += watermark_bias(secret_key, previous_tokens)
next_token = sample(scores)

This is a schematic example, not Anthropic’s implementation. It shows why the detail matters: a watermark can leave the file length unchanged while still changing the generated program.

Natural-language generation usually has several acceptable next words. Code has many positions where only a small number of tokens compile, satisfy the type checker or preserve the intended behaviour. It also has choices that are functionally correct but not equivalent in cost: one algorithm may allocate more memory, issue more queries, produce a larger bundle or consume more gas.

LLM generation is already probabilistic in many configurations. The additional issue is that watermarking gives token selection another objective alongside correctness and the user’s request. With low-temperature or otherwise constrained generation, it may also change the output a team expects from an otherwise unchanged model configuration.

The positive case for marking code

A reliable provenance signal would be useful. It could help a team identify whether code passed through an AI system, investigate an incident, or apply a review policy to AI-assisted work. A mark that survives copying is more useful for snippets than metadata attached to a file.

Machine-readable marking is also better than requiring every generated function to contain a visible comment. Visible labels would pollute diffs, become stale during refactoring and invite developers to remove them immediately.

The global policy helps organisations build one compliance path. If detection is available locally and its limitations are clear, it could become one signal in a wider provenance record covering the model, tool, session and human review.

Anthropic is careful about the interpretation. A detected mark means that Claude may have processed the content. It does not prove that Claude originated the design, wrote the whole file or produced the version now under review. That is the right boundary, although downstream tools will need to preserve it.

Code makes the quality trade-off harder

Research on code watermarking supports the concern, but does not tell us how Anthropic’s unpublished system behaves.

Abstract execution paths showing a small statistical bias taking a longer route to the same result A correct result can still take a more expensive path.

The authors of SWEET, a code-specific watermarking method, found that a general text watermark could degrade generated code because code is a low-entropy task. Their method avoids watermarking positions where the model has too few safe token choices. Later work on syntax-aware code watermarking similarly reports a trade-off between correctness and detection, and tries to avoid syntax-critical tokens.

Those papers do not show that Claude generates slower or less correct code. They show that “the meaning does not change” is a testable engineering claim, not something that follows automatically from a watermark being invisible.

The useful comparison is the same model with and without its watermark. Anthropic should publish results for:

compilation, type checking and functional test pass rates
benchmark correctness on short functions and repository-level tasks
runtime, allocations, binary and bundle size, SQL query count and smart-contract gas where relevant
output length and unnecessary comments or indirection
stability under formatters, linters, minifiers, transpilers and ordinary refactoring
false-positive and false-negative detection rates by language and snippet length

Short source files deserve particular attention. Anthropic already warns that short text may be too small to detect reliably, while code often consists of short functions with few discretionary tokens.

A fragile mark can impose cost without preserving provenance

Code is routinely transformed after generation. A formatter changes whitespace, a developer renames a variable, a compiler discards comments, a minifier rewrites expressions and a refactor moves logic between functions.

A 2024 study of code-watermark robustness found that semantics-preserving transformations such as variable renaming could substantially reduce detectability. In many of its tests, true-positive rates fell below 50% after relatively minor changes.

Again, that is not a result for Claude’s watermark. It exposes the core trade-off. A strong mark may need to influence more token choices, increasing the risk of affecting output. A cautious mark may preserve quality but disappear during normal development.

Detection also creates a governance problem. A human-written module sent to Claude for a small refactor may come back marked, even though its architecture and most of its code are human work. Employers, clients and education providers could turn “processed by Claude” into “written by AI” despite Anthropic’s warning. A detector must report that distinction prominently rather than return an unexplained yes or no.

Code provenance belongs with the change

For software, a signed record attached to a pull request or commit is usually more useful than a statistical pattern in the source. It can record the model and tool used, which files changed, the tests run and who reviewed the result. It also survives formatting and compilation without asking the generator to choose a different token.

That approach will not follow a copied snippet into another repository. An embedded mark might, so the two mechanisms can complement each other. Anthropic should still let API and Claude Code users opt out of source-code watermarking, especially because the Commission’s guidance excludes code, and provide repository-level provenance as the stronger default.

Until the technical documentation and detector arrive, teams should treat this as they would a model change. Pin the model where possible, run the same coding and performance evaluations before and after marking support appears, and do not use a detected mark as proof of authorship. If the watermark is genuinely free for code, the benchmarks should make that visible.