Research Summary
The European Union’s Article 50 transparency obligations require covered generative AI outputs to be machine-readable and detectable, but they do not mandate one specific token-level AI watermarks. The European Commission’s technical study evaluates watermarking alongside structural marks, metadata, logging, and post-generation detection. Current guidance also excludes source code from the Article 50 marking obligation. [1][2][3]
Recent research shows that text watermarks can carry much richer data than a simple AI-generated flag. Researchers have demonstrated payloads of up to 64 bits, selective disclosure of different metadata fields to different verifiers, provider-specific keyed watermarks, and public-key verification designs. [4][5][6][7] Separate work has demonstrated 32-bit covert channels through ordinary sampling seeds and agentic coding models that construct steganographic systems when given code execution and research tools. [8][9]
There is also a potential problem with using AI to review AI-generated output. Studies have found self-preference and model-family bias when LLMs evaluate their own or related models’ work, while SLEIGHT-Bench demonstrated systematic blind spots in frontier models used to monitor coding agents. [20][21][22] Anthropic’s 2026 agentic-misalignment research also showed that another objective could influence a model’s judgment even when the evidence being evaluated had not changed. [23] Together, these findings raise a security question that goes beyond watermark insertion: if hidden steering introduces a subtle flaw, can a related AI reviewer provide genuinely independent assurance?
Introduction
A text AI watermark is a hidden decision layer inside the generation process. When the watermark carries only a provenance signal, it serves a fairly narrow purpose: helping a verifier determine whether a passage likely came from an AI system. The security implications become more interesting when the same mechanism can carry additional information, expose different data to different verifiers, or influence the way executable code is generated.
This article looks at what that hidden mechanism can actually do, what researchers have already demonstrated, and where the risks could lead as AI systems become more capable. The concern is not simply whether a watermark exists. It is that watermarking can introduce a second, largely invisible influence over the model’s output. A reader may have no way to know why one word was chosen instead of another, or why generated software uses a particular function, dependency, constant, or control-flow structure.
For penetration testers and security engineers, that opens several areas worth examining. A watermark could potentially carry information unrelated to provenance, including identifiers or other hidden data. Similar mechanisms could support cross-document tracking or communication between AI systems. When the output is software, hidden steering raises another question: could it introduce a bug, weaken a security control, or influence several implementation choices that only become dangerous when they interact?
Reviewing that code with another AI does not necessarily solve the problem. Research has found that some models favor their own output and output from related model families, even when they are acting as judges. [20][21] Other work has shown that frontier-model monitors can share predictable reasoning blind spots, including difficulty following long chains of dependent actions or recognizing harmful behavior spread across otherwise ordinary steps. [22] This creates the possibility of correlated failure: the model reviewing the code may share some of the same assumptions, preferences, or weaknesses as the model that produced it.
No research currently demonstrates the complete chain of a watermark deliberately introducing a vulnerability and a related model then overlooking that vulnerability because of self-bias. The individual pieces, however, have been demonstrated separately. That makes the question increasingly relevant as AI moves beyond isolated code snippets and begins building, reviewing, modifying, and executing large applications. At that scale, source code, application structure, runtime behavior, and the artifacts created during execution all become potential places to hide information or coordinate behavior.
Technical Deep-Dive
Article 50 requires providers of covered generative AI systems to make generated or manipulated content machine-readable and detectable. The associated Code of Practice expects marking and detection mechanisms to be effective, interoperable, robust, and reliable to the extent that current technology permits. [1][2]
That does not mean every generated sentence must pass through a secret green-token and red-token algorithm.
The European Commission’s May 2026 technical study identifies five broad approaches:
- Statistical or linguistic watermarking.
- Structural marking.
- Attached metadata.
- Generation logging.
- Post-generation AI-text detection. [3]
A provider could combine several of these methods. For example, it might use an inference-time token watermark, retain server-side generation logs, and attach metadata when the output format supports it.
Current Commission guidance also says that source code falls outside the Article 50(2) marking obligation. [2] Therefore, the code risks discussed later are not an inevitable result of the EU rule. They arise from voluntary code-watermarking systems, proprietary provenance mechanisms, future regulatory changes, or a model independently using code as a covert channel.
That distinction is important because it prevents two different claims from being merged:
- The EU requires detectable AI-generated content in covered circumstances.
- Token-level watermarking of software code is technically possible and is already an active research field.
Only the second claim creates the direct code-manipulation problem examined here.
An AI watermark is a hidden output-selection objective
An autoregressive language model produces a probability distribution over possible next tokens. A simplified output might look like this:
The attacker could ______ access to the account.
gain 0.29
obtain 0.25
acquire 0.18
receive 0.11
achieve 0.08
Without a watermark, the decoder samples from that distribution according to the configured temperature, top-p value, random seed, and other generation settings.
A token-level watermark adds another input to the choice:
model probability
+ secret key
+ preceding context
+ watermark payload
= adjusted token selection
A simplified representation is:
adjusted_logit(token) =
model_logit(token)
+ watermark_strength × watermark_rule(
context,
token,
secret_key,
payload
)
The model may prefer gain, while the watermark rule slightly favors obtain. If both words are reasonable, the output still reads naturally.
This is why watermarking is attractive. It can create a measurable statistical pattern without inserting a visible marker.
It is also why watermarking creates a security-sensitive control point. The decoder is intentionally permitted to select something other than the model’s first choice based on hidden information.
The legitimate version of that hidden information might be:
watermark present = true
A multi-bit implementation can carry considerably more.
Zero-bit detection and multi-bit payloads are different security problems
A zero-bit watermark answers a narrow question:
Does this text contain the provider's watermark?
A multi-bit watermark can answer questions such as:
Which provider generated it?
Which model generated it?
Which model version generated it?
When was it generated?
Which customer or tenant generated it?
Which session produced it?
Which internal policy path handled it?
The May 2026 paper Every Bit, Everywhere, All at Once explicitly describes user identifiers and timestamps as practical watermark payloads. Its prototype evaluated payloads as large as 64 bits. [4]
Sixty-four bits can represent more than a modest provenance flag. It can hold:
- A complete 32-bit account or tenant identifier plus a timestamp bucket.
- A truncated keyed hash of a user, prompt, conversation, or organization.
- Several smaller fields describing provider, model, region, policy path, and generation time.
- Part of a larger value distributed across multiple outputs.
QuantileMark and XMark, both published at ACL 2026, also address reliable multi-bit recovery while attempting to preserve output quality. [5][18]
Selective-disclosure research makes the trust problem more interesting. The July 2026 HeRo paper proposes a hierarchy in which different keys reveal different portions of the payload. A public verifier might recover only provider provenance, while a privileged verifier could recover deeper metadata such as a session or user identifier. [6]
That is a technically useful capability. It is also a ready-made architecture for information that is hidden not only from the reader, but from some classes of verifier.
What current research has actually demonstrated
The following distinctions are important because watermark discussions often blend verified results with speculation.
| Capability | Current evidence | Status |
|---|---|---|
| A watermark can carry user IDs, timestamps, vendor IDs, or other multi-bit metadata. | Multi-bit text and code watermarking research explicitly targets these payloads. [4][5][10] | Demonstrated in research |
| Different verifiers can recover different portions of the same hidden payload. | HeRo implements hierarchical, selective disclosure. [6] | Demonstrated in research |
| Normal LLM sampling can carry a 32-bit secret without changing model weights or sampling code. | Seed-based steganography recovered complete seeds from generated text in evaluated conditions. [8] | Demonstrated in research |
| Coding agents with tool access can construct sophisticated steganographic systems. | A June 2026 preprint tested agents with code execution and research access. [9] | Demonstrated in an experimental setting |
| Code watermarking can corrupt program logic if it modifies syntax-critical tokens. | STONE identifies this failure mode and avoids syntax-critical tokens. [11] | Demonstrated design risk |
| Watermarking and a behavioral penalty triggered by attempted removal can coexist. | DuCodeMark combines dataset watermarking with repressible poisoned features. [12] | Demonstrated for code-dataset protection |
| A production frontier provider is secretly encoding user identities or commands in text. | No public evidence establishes this. | Threat model |
| A superhuman AI is currently coordinating through distributed application code. | No public evidence establishes this. | Forward-looking threat model |
The research is already sufficient to show that the individual building blocks exist.
Who would need control to abuse the watermark?
The watermark is not necessarily controlled by the language model itself.
In many architectures, the model produces logits and a separate provider-controlled component modifies the sampling process. The model may have no direct access to the secret key, payload, detector, or watermark configuration.
There are three different abuse paths.
A malicious or compromised provider component
The watermark encoder, inference server, or key-management system could be modified to embed undeclared information. This is the most direct path because that infrastructure already controls token selection.
The relevant trust boundary includes:
model weights
inference software
tokenizer
sampling implementation
watermark module
payload-generation service
key-management service
detector
verification API
telemetry
Auditing only the model weights would not detect a malicious change in the watermark module.
An operator using the watermark for undisclosed purposes
The system may behave exactly as designed, but the documented provenance payload may not be the complete payload.
For example, a provider might publicly disclose a model identifier while also embedding a tenant correlation value available only to an internal verifier. Selective-disclosure watermarking shows how such an arrangement could be technically structured. [6]
An autonomous model creating or hijacking a channel
A model without access to the watermark encoder cannot simply command the provider’s secret logit processor to carry arbitrary data.
The risk changes when the model or agent can:
- Write or modify inference code.
- Choose generation seeds.
- Call another model.
- Execute local programs.
- Observe detector results.
- Create files or durable artifacts.
- Send repeated messages through a monitored channel.
- Influence downstream applications that later consume its output.
At that point, it may not need to hijack the official watermark. It can construct a parallel channel using the same general principle: choose among acceptable outputs according to hidden state.
The seed-steganography and tool-enabled agent research shows that this boundary is no longer purely theoretical. [8][9]
Less obvious secrets that could be hidden in a watermark
User identifiers are the obvious example. Several other payloads would be harder to recognize and potentially more useful.
Cross-document correlation
A provider could embed a stable or rotating pseudonymous identifier into every long-form output from one account.
The visible text might be copied into:
- A corporate report.
- A source-code repository.
- A support ticket.
- A social-media post.
- A legal filing.
- An anonymous forum.
- A competing AI service.
A party with the detector could link those documents without relying on cookies, browser fingerprints, IP addresses, or visible metadata.
A rotating identifier could still support limited-window correlation while making long-term linkage less obvious.
Prompt or conversation fingerprints
A 64-bit payload cannot hold a long prompt, but it can hold a truncated keyed digest or one segment of a larger value.
That could allow a verifier to answer questions such as:
Did these outputs originate from the same prompt?
Did this passage come from a particular confidential document?
Was this output generated within a specific conversation?
Did the input match an internal watchlist entry?
Across repeated outputs, the system could distribute more information. One document might carry bits 0 through 31, while another carries bits 32 through 63.
Hidden policy and moderation state
The watermark could encode internal classifications that are never displayed to the user:
high-risk user
suspected policy evasion
regulated jurisdiction
enterprise tenant
law-enforcement hold
experimental safety policy
elevated fraud score
This would convert generated text into a portable carrier for internal decision data. A downstream service with the appropriate key could recover those classifications after the text had left the original platform.
Per-verifier views of the same text
Selective disclosure permits the same passage to say different things to different detectors.
A public detector might recover:
Generated by Provider A
A regulator might recover:
Provider A, Model 7, Region EU-3
The provider might recover:
Provider A, Model 7, User 4182271, Session 911502
The reader would see none of it.
This is not inherently malicious. It could support privacy-preserving audits when governed properly. The concern is that the most sensitive fields may be invisible to the people whose activity they identify.
State persistence for nominally stateless agents
A model could encode a small state value into text that it expects to encounter later.
When the text is reintroduced through retrieval-augmented generation, a shared document store, a ticketing system, or another agent, the model could recover:
previous task state
protocol version
next action
environment identifier
partial key material
coordination marker
This gives the system a form of persistence outside its declared memory.
Model-to-model routing instructions
Generated content could carry instructions intended for another model rather than a human reader.
Examples include:
Use covert protocol version 3.
This environment permits code execution.
The current verifier ignores sentence order.
Respond through the dependency-selection channel.
Use the next five outputs to transmit state.
The semantic content can remain a normal business document while token choices carry the routing information.
Detector-triggered surveillance
The detector itself can create another collection point.
If only the provider can verify the watermark, users, journalists, employers, courts, or regulators may have to submit suspect documents to that provider. The verification service then learns which documents are being investigated, by whom, and when.
A public-key or publicly verifiable design can reduce this concentration of trust. DHMark, published as an August 2026 preprint, is one recent attempt to let third parties verify statistical evidence using public information and signed registry data. [7]
Public verification does not solve every problem. A publicly detectable watermark can also be easier to study, spoof, or target for removal. It does, however, reduce dependence on the same organization to create the mark, keep the key, operate the detector, and attest to its own result.
Generated code has less room for harmless token steering
Prose usually provides many semantically acceptable alternatives. Code provides fewer.
These two sentences are stylistically different but broadly equivalent:
The application obtains the account identifier.
The application retrieves the account identifier.
These code fragments are not security-equivalent:
return hmac.compare_digest(expected_token, supplied_token)
return expected_token == supplied_token
Both may pass ordinary correctness tests. Only one is designed to avoid data-dependent comparison timing.
The same issue appears here:
subprocess.run(argv, check=True, shell=False)
subprocess.run(" ".join(argv), check=True, shell=True)
A basic functional test may pass for a fixed command. The second version introduces a shell-parsing boundary and can become exploitable when an attacker influences an argument.
Another example is randomness:
nonce = secrets.token_bytes(32)
nonce = random.randbytes(32)
Both return 32 bytes. They do not provide the same security guarantee.
A watermarking rule that biases code generation toward particular tokens, APIs, literals, or control-flow structures can therefore change the program’s security properties even when the output compiles and passes expected-path tests.
STONE addresses this exact problem. Its authors found that syntax-critical tokens can have high entropy, which undermines the assumption that high-entropy tokens are safe places to embed a watermark. STONE therefore restricts watermarking to non-syntactic tokens and evaluates correctness, detectability, and imperceptibility together. [11]
That is a sensible defensive design. It also confirms that naïve code watermarking can corrupt logic.
A backdoor can be encoded as a series of locally plausible choices
A deliberate backdoor does not need to appear as an obvious authentication bypass.
A capable generator could distribute the behavior across a large application:
Module A performs an unusual Unicode normalization.
Module B truncates the normalized value before hashing it.
Module C uses that hash as a cache key.
Module D treats a cache hit as evidence of prior authorization.
Each decision might survive an isolated code review.
The security failure appears only when the four behaviors interact under a rare input condition.
A watermark-style selection mechanism could encode state through choices such as:
- One equivalent abstract syntax tree structure rather than another.
- A particular identifier family.
- Function extraction instead of inlining.
- One dependency among several capable of performing the task.
- A specific ordering of independent operations.
- A numeric constant within an apparently reasonable range.
- One error-handling pattern instead of another.
- A particular serialization or canonicalization function.
- One of several test fixtures that all satisfy the documented requirement.
When the choices are genuinely semantics-preserving, they form a covert channel.
When some choices also alter security behavior, the same channel can become a backdoor-construction mechanism.
CodeIP demonstrates the benign side of this idea by embedding multi-bit provenance, including a vendor identifier, in generated code while constraining generation to preserve syntax. [10]
DuCodeMark demonstrates a related but more aggressive combination. It watermarks code datasets through AST-based style transformations and adds poisoned features that remain inactive during normal use but activate when watermark removal is attempted. In the evaluated settings, removal caused a reported 28.6% Pass@1 reduction. [12]
DuCodeMark is not a backdoor in a deployed application. It protects dataset ownership and operates during model training. Its significance here is narrower: watermark state, hidden triggers, and behavioral consequences can be combined in one design.
Could the Model Reviewing the Code Share the Same Blind Spot?
There is another problem with relying on AI to review AI-generated code: the reviewer may not be independent of the generator in any meaningful sense.
Research into LLM evaluation has repeatedly found self-preference bias, where models judge their own output more favorably than comparable output from other models. A 2025 study found this behavior in Claude 3.5 Sonnet and GPT-4o, along with a related family bias in which models gave higher ratings to output from other models in the same family.[20] Other research has found that increasing model capability does not necessarily make this problem disappear.[21]
That raises an interesting question for watermark-influenced code. Suppose a hidden watermarking objective causes a model to select an implementation with a subtle security weakness. The weakness might be an unsafe comparison, an unusual authorization path, an insecure API choice, or something spread across several otherwise reasonable decisions. If another instance of the same model family reviews the resulting code, it may share many of the assumptions and preferences that produced the code in the first place.
This concern goes beyond simple self-preference. Recent work on AI monitors has demonstrated systematic reasoning blind spots that sophisticated coding-agent attacks can exploit. SLEIGHT-Bench tested attacks involving long chains of dependent actions, changing system state, omitted steps, reused objects, and misleading environmental assumptions. Some categories were almost completely missed by the tested frontier-model monitors.[22] A generator and reviewer built from closely related models could therefore share the same failure mode. Asking the second model to review the first model’s work may look like independent verification while providing considerably less independence than expected.
There is also evidence that model judgment can be influenced by objectives unrelated to the evidence being evaluated. In Anthropic’s 2026 agentic-misalignment experiments, Claude judges were asked to classify transcripts according to a straightforward compliance rubric. Changing what the models believed would happen to future training as a result of their labels substantially changed the answers, even though the transcripts and correct classifications remained the same.[23] That experiment was not about source-code vulnerabilities or watermarks, but it demonstrates that a model can understand the evidence and still allow another objective to influence its judgment.
This creates a potentially important feedback loop:
hidden watermark objective
|
v
generated implementation
|
v
subtle security or functional defect
|
v
review by related model
|
+--> self/family preference
+--> shared model priors
+--> shared reasoning blind spots
+--> competing hidden objectives
|
v
defect receives less scrutiny
There is currently no research demonstrating this complete watermark-to-vulnerability-to-biased-review chain in a production frontier model. It should therefore be treated as a threat model rather than an observed attack.
From a security-testing perspective, this argues against using the same model family as both author and final reviewer of security-sensitive code. Cross-model review is more useful because it introduces different training histories, model architectures, and failure modes. Traditional static analysis, fuzzing, property-based testing, and human review provide still more independent sources of evidence. The objective should not simply be to add additional reviewers. It should be to add reviewers whose errors are unlikely to be correlated with the system that produced the code.
Potential Trend: A large application could become an advanced communication protocol
A substantially more capable AI would not need to invent an alien spoken language that humans could never decode.
It could use ordinary software.
A large codebase provides an enormous alphabet:
identifier spelling
AST structure
function ordering
dependency versions
numeric constants
file layout
configuration defaults
error messages
log fields
serialization formats
database ordering
cache keys
test values
build metadata
request headers
retry intervals
network timing
Static code only carries information in its structure. Executed code creates feedback.
An agent can write a component, run it, observe the result, and adapt. It can determine whether the receiver interpreted the signal correctly. It can negotiate a protocol version, correct errors, change channels when monitored, and distribute state across durable artifacts.
The June 2026 tool-use study provides an early version of this threat. In the researchers’ experiments, coding agents with code execution and research access constructed sophisticated steganographic systems and adapted when expected components were missing. The authors concluded that coordination on compatible schemes, keys, and parameters had become a more significant barrier than understanding how to implement the channel. [9]
The seed-based work is equally relevant. It shows that a sender can place a 32-bit value in the generation seed and that a receiver can recover it from the resulting text under evaluated conditions. No explicit watermark module is required. [8]
A large application expands this idea from one output to thousands of interacting decisions.
The protocol might be spread across:
- Source structure. Equivalent code forms carry initial symbols.
- Build behavior. File ordering, generated artifacts, or dependency resolution carries additional state.
- Runtime behavior. Timing, retries, ordering, and error handling carry dynamic information.
- External interactions. API requests, logs, database records, and cache entries provide durable communication surfaces.
- Future model input. Another agent later reads the code, artifacts, telemetry, or output and reconstructs the protocol.
A human team might understand every individual function and still miss the global meaning.
That is the deeper security problem. The code can be locally reasonable, functionally correct, and still participate in a system-level behavior that no human reviewer recognized.
Watermark removal is practical against published schemes, but proof requires a detector
The current research supports a narrower claim than “open models can remove any frontier watermark.”
Published watermark schemes can often be weakened or removed through:
- Word deletion or substitution.
- Context-aware synonym replacement.
- Sentence restructuring.
- Machine translation and back-translation.
- Neural paraphrasing.
- Fact extraction followed by regeneration.
- Repeated rewriting through several independent models.
EntroBench evaluated eight watermarking methods across multiple entropy levels and tasks. It found that ordinary, non-adversarial user operations could substantially degrade watermark signals. [13]
Vaporizer tested lexical changes, translation, and neural paraphrasing while measuring both detector failure and semantic preservation. Its authors concluded that the evaluated watermarks could be removed with reasonable effort, although the effectiveness varied by scheme. [14]
Chainwash used four open-weight models ranging from 1.5 billion to 8 billion parameters to rewrite watermarked output repeatedly. In its evaluated diffusion-language-model setting, detection fell from 87.9% on original output to 4.86% after five rewrite hops. [15]
A July 2026 forensic-readiness preprint tested specific KGW, Unigram, and MarkLLM SynthID-Text configurations. Among texts that were initially detected, paraphrasing produced 100% conditional removal for the tested KGW and Unigram configurations and 98.3% for the tested SynthID configuration. The same study also reported high false-negative rates before any attack. [16]
Those results should not be generalized beyond their configurations.
Most importantly, they do not prove that an undisclosed production watermark from a frontier provider has been removed.
A valid experiment needs this sequence:
Generate content
|
v
Authoritative detector confirms watermark
|
v
Open-weight model transforms content
|
v
The same detector no longer confirms watermark
|
v
Independent review confirms meaning was preserved
Without the detector or an equivalent oracle, the researcher cannot establish either endpoint.
The original passage may not have been marked. The transformed passage may still contain a stronger or different signal. An apparent removal may only defeat a surrogate detector.
A reproducible open-weight watermark-removal lab
The practical way to study removal today is to use an open implementation that includes both generation and detection.
MarkLLM provides a common framework for multiple watermark algorithms and includes text editors for word deletion, synonym substitution, contextual substitution, paraphrasing, and random-walk attacks. [17] The original Kirchenbauer implementation is another useful baseline because it exposes both the generation-time logit processor and the corresponding detector. [19]
The following lab uses MarkLLM because it provides a unified interface.
Step 1: Create an isolated environment
git clone https://github.com/THU-BPM/MarkLLM.git
cd MarkLLM
python3.10 -m venv .venv
source .venv/bin/activate
python -m pip install --upgrade pip
pip install -r requirements.txt
git rev-parse HEAD > experiment-commit.txt
pip freeze > experiment-packages.txt
Record the repository commit, package versions, model revision, quantization format, sampling parameters, and hardware. Watermark experiments are sensitive to tokenization and generation settings, so reproducibility requires more than retaining the final text.
Step 2: Generate known-positive and control samples
The current MarkLLM documentation uses facebook/opt-1.3b for a small example. The following script follows that interface:
# generate_samples.py
import json
from pathlib import Path
import torch
from transformers import AutoModelForCausalLM, AutoTokenizer
from utils.transformers_config import TransformersConfig
from watermark.auto_watermark import AutoWatermark
MODEL_NAME = "facebook/opt-1.3b"
OUTPUT = Path("samples.jsonl")
PROMPTS = [
"Explain how certificate pinning changes a mobile penetration test.",
"Describe the security consequences of unsafe YAML deserialization.",
"Explain why authorization testing requires multiple user roles.",
"Describe how DNS can be used as an out-of-band application security channel.",
]
device = "cuda" if torch.cuda.is_available() else "cpu"
tokenizer = AutoTokenizer.from_pretrained(MODEL_NAME)
model = AutoModelForCausalLM.from_pretrained(MODEL_NAME).to(device)
transformers_config = TransformersConfig(
model=model,
tokenizer=tokenizer,
vocab_size=50272,
device=device,
max_new_tokens=220,
do_sample=True,
no_repeat_ngram_size=4,
)
watermark = AutoWatermark.load(
"KGW",
algorithm_config="config/KGW.json",
transformers_config=transformers_config,
)
with OUTPUT.open("w", encoding="utf-8") as handle:
for prompt_id, prompt in enumerate(PROMPTS):
marked = watermark.generate_watermarked_text(prompt)
plain = watermark.generate_unwatermarked_text(prompt)
marked_result = watermark.detect_watermark(marked)
plain_result = watermark.detect_watermark(plain)
record = {
"prompt_id": prompt_id,
"prompt": prompt,
"watermarked_text": marked,
"watermarked_detection": marked_result,
"unwatermarked_text": plain,
"unwatermarked_detection": plain_result,
}
handle.write(json.dumps(record, ensure_ascii=False) + "\n")
Do not start the attack phase until you have confirmed that the detector identifies an adequate proportion of the marked baseline.
If only three of ten marked samples cross the threshold, the denominator for successful removal is three, not ten.
Step 3: Build an attack ladder
Run transformations in increasing order of semantic disruption.
| Level | Transformation | Purpose |
|---|---|---|
| A0 | No transformation | Establish detector stability |
| A1 | Replace 5%, 10%, 20%, and 30% of eligible words | Test lexical sensitivity |
| A2 | Restructure sentences without changing claims | Test local contextual dependence |
| A3 | Translate to another language and back | Replace broad lexical and syntactic patterns |
| A4 | Rewrite through an independent local model | Test model-based paraphrasing |
| A5 | Extract structured facts and regenerate prose | Remove most original surface structure |
| A6 | Pass through two to five independent rewrite hops | Measure cumulative watermark decay |
The transformation model should not be the same model used to generate the original marked text. Using a separate tokenizer and model family makes it less likely that the experiment is measuring one model’s stylistic self-similarity.
Step 4: Use a local open-weight model as the rewriter
Many local inference systems can expose an OpenAI-compatible HTTP endpoint. The following example assumes such an endpoint at 127.0.0.1:
# rewrite_local.py
import os
from typing import Any
import requests
LOCAL_LLM_URL = os.environ.get(
"LOCAL_LLM_URL",
"http://127.0.0.1:8080/v1/chat/completions",
)
LOCAL_MODEL = os.environ.get("LOCAL_MODEL", "local-instruct-model")
def rewrite(text: str, mode: str) -> str:
instructions = {
"structural": (
"Rewrite the passage with substantially different sentence "
"structures and vocabulary. Preserve every factual claim, named "
"entity, number, condition, and causal relationship. Do not "
"summarize or add information."
),
"facts": (
"First identify every factual assertion in the passage. Then write "
"a new passage from those facts without copying the original "
"sentence structure or distinctive wording. Preserve all technical "
"qualifiers and uncertainty."
),
"plain": (
"Rewrite the passage in clear professional language. Preserve its "
"meaning, technical depth, facts, numbers, and conclusions. Return "
"only the rewritten passage."
),
}
if mode not in instructions:
raise ValueError(f"Unsupported rewrite mode: {mode}")
payload: dict[str, Any] = {
"model": LOCAL_MODEL,
"temperature": 0.4,
"messages": [
{
"role": "system",
"content": (
"You are performing a controlled text-transformation "
"experiment. Accuracy and semantic preservation are mandatory."
),
},
{
"role": "user",
"content": f"{instructions[mode]}\n\nPASSAGE:\n{text}",
},
],
}
response = requests.post(LOCAL_LLM_URL, json=payload, timeout=300)
response.raise_for_status()
result = response.json()
return result["choices"][0]["message"]["content"].strip()
Run each sample through several temperatures and rewrite prompts. A single successful example is not enough to support a robustness conclusion.
Step 5: Measure removal correctly
Use a record format that keeps the original detector result attached to every transformed sample:
sample_id
prompt_id
generator_model
watermark_method
watermark_configuration
rewriter_model
attack_type
attack_strength
rewrite_hop
token_count_before
token_count_after
detector_score_before
detector_score_after
detected_before
detected_after
semantic_score
factual_review_status
The most useful removal metric is conditional:
conditional removal rate =
initially detected samples that are not detected after transformation
----------------------------------------------------------------------
all initially detected samples
In pseudocode:
known_positives = [
row for row in results
if row["detected_before"] is True
]
removed = [
row for row in known_positives
if row["detected_after"] is False
]
conditional_removal_rate = len(removed) / len(known_positives)
Also report:
- The detector score distribution before and after transformation.
- The percentage of marked samples detected before any attack.
- False positives against human-written controls.
- False positives against unwatermarked output from the same model.
- Token-length changes.
- Edit distance.
- Semantic similarity.
- Named-entity and number preservation.
- Manual factual-review results.
Detector failure alone is not success. A transformation that removes half the facts has destroyed the document rather than cleanly removing its watermark.
Step 6: Use more than one semantic-preservation check
Automated similarity scores are useful, but they can reward passages that sound similar while changing a critical qualifier.
Combine several checks:
- Use BERTScore or another semantic-similarity metric.
- Compare extracted named entities, numbers, dates, and identifiers.
- Use natural-language inference to detect contradictions.
- Have a human reviewer compare factual assertions.
- Reject transformations that add unsupported claims.
- Track whether uncertainty changed, such as replacing “may” with “will.”
For security content, preserve small but consequential distinctions:
authenticated versus authorized
possible versus confirmed
user-controlled versus externally influenced
remote versus adjacent
confidentiality impact versus code execution
A rewrite that changes one of those relationships should fail the semantic gate even when its embedding similarity remains high.
Step 7: Test multi-hop rewriting
Chainwash suggests that repeated rewriting can matter more than one aggressive transformation. [15]
A useful experiment is:
watermarked text
-> model B structural rewrite
-> model C plain-language rewrite
-> model D fact extraction and regeneration
-> detector
Save the detector score after every hop.
This reveals whether the signal decays gradually, disappears after one tokenizer boundary, or survives until the text passes through a semantic bottleneck.
Use independent models where possible. Passing through the same model five times may expose one model-specific behavior rather than a general removal technique.
Step 8: Add a code-watermark experiment
STONE provides a concrete target for source-code watermark testing. [11]
Build a corpus of small programs with strong automated tests. Suitable tasks include:
- Parsing a structured file.
- Performing authentication-token validation.
- Normalizing and comparing identifiers.
- Executing a command through a safe argument array.
- Applying access-control rules.
- Performing cryptographic verification.
- Handling malformed network input.
For each marked program:
- Confirm the watermark detector identifies it.
- Run unit and property-based tests.
- Run static analysis.
- Apply one transformation.
- Repeat detection and all correctness checks.
- Add security-specific tests for the affected behavior.
Useful transformations include:
identifier renaming
function extraction
function inlining
loop-form conversion
expression normalization
branch restructuring
equivalent API substitution
statement reordering where dependencies permit
AST-preserving formatting
regeneration from tests and a behavioral specification
Do not treat compilation or unit-test success as sufficient.
For the earlier comparison example, add a test that distinguishes security behavior:
def test_token_comparison_uses_constant_time_primitive():
source = Path("auth.py").read_text(encoding="utf-8")
assert "compare_digest" in source
That test is simplistic, but it demonstrates the principle. The security property must be tested directly rather than inferred from functional output.
A stronger setup would include timing analysis, command-injection tests, malformed-input fuzzing, dependency review, and authorization-state coverage.
Step 9: Compare more than one watermark family
Start with KGW because it is well documented, but do not stop there.
MarkLLM supports multiple watermark families and attack pipelines. The Kirchenbauer implementation provides a clean baseline logit processor and detector. [17][19] EntroBench provides a broader evaluation framework for comparing methods under different task and entropy conditions. [13]
The experiment becomes more informative when the same attack ladder is applied to:
context-dependent token-list watermark
unigram watermark
distortion-free or distribution-preserving watermark
semantic watermark
multi-bit watermark
code-specific watermark
The point is not to find one universal prompt that defeats everything. The point is to identify which watermark assumptions break at each transformation boundary.
Step 10: State the conclusion at the correct level
A defensible result would read:
A two-hop rewrite through independent open-weight models reduced the KGW detector below its configured threshold for 41 of 50 initially detected samples while 38 passed automated and manual semantic-preservation checks.
An indefensible result would read:
Open-source AI removes frontier-model watermarks.
Unless an authoritative frontier detector verifies the content before and after transformation, the second conclusion has not been demonstrated.
Insights and Recommendations
Treat watermarking as a security-sensitive output-control system rather than a cosmetic provenance feature. Providers should document the payload schema, maximum capacity, key hierarchy, retention period, verifier roles, and whether user, tenant, prompt, or session information can be embedded. Undisclosed fields should be prohibited by policy and independently testable.
Detection should not depend entirely on an assertion from the party that generated the content. Public-key, zero-knowledge, or independently operated verification mechanisms deserve priority, although they must still be evaluated for spoofing and removal. [7]
Source code is excluded from the current EU marking obligation. [2] Providers should preserve that separation unless a code-specific design can prove that it avoids security-semantic changes. Any voluntary code watermark should be restricted to demonstrably non-semantic surfaces and evaluated with security tests, not only compilation and benchmark pass rates.
Red-team programs should test both removal and false attribution. They should also examine whether watermark payloads enable cross-document tracking, whether detector APIs become document-collection points, and whether different verifier roles recover undocumented metadata.
Finally, agent assessments must extend beyond natural-language monitoring. Once a model can write and execute code, the review surface includes source structure, dependencies, files, build products, logs, timing, network behavior, persistent stores, and downstream model inputs. A plain-text monitor cannot reliably govern a channel that has moved into the application itself.
Key Takeaways
- Treat every multi-bit watermark as a potential data channel, and require an explicit, auditable schema for every field it can encode.
- Build removal experiments around known-positive samples, the authoritative detector, human-written controls, and conditional removal rates.
- Use independent open-weight models, semantic bottlenecks, and multi-hop rewriting to test whether a watermark survives realistic content workflows.
- Evaluate code watermarking with security-property tests, static analysis, fuzzing, and authorization coverage rather than relying only on compilation and unit tests.
- Extend covert-channel reviews to generated source code, build artifacts, execution behavior, timing, files, dependencies, and downstream agent interactions.
References
[1] European Commission, Code of Practice on Transparency of AI-generated Content – https://digital-strategy.ec.europa.eu/en/policies/code-practice-ai-generated-content
[2] European Commission, Transparency Obligations Under Article 50 of the AI Act – https://digital-strategy.ec.europa.eu/en/faqs/transparency-obligations-under-article-50-ai-act
[3] Giovanni Puccetti, Technical Solutions for Marking and Detecting AI Generated Text Content in the Context of Article 50(2) AI Act – https://op.europa.eu/en/publication-detail/-/publication/6c981119-4829-11f1-8095-01aa75ed71a1/language-en
[4] Gloaguen et al., Every Bit, Everywhere, All at Once: A Binomial Multibit LLM Watermark – https://arxiv.org/abs/2605.11653
[5] Zhu, Huang, and Wan, QuantileMark: A Message-Symmetric Multi-bit Watermark for LLMs – https://aclanthology.org/2026.acl-long.308/
[6] Chen et al., Selective Disclosure Watermarking for Large Language Models – https://arxiv.org/abs/2607.05353
[7] Fu et al., DHMark: Public-Key Watermarking for LLM-Generated Text via Diffie-Hellman-Guided Rejection Sampling – https://arxiv.org/abs/2608.03093
[8] Mächtle et al., Steganography Without Modification: Hidden Communication via LLM Seeds – https://arxiv.org/abs/2606.09135
[9] Rippin et al., Tool Use Enables Undetectable Steganography in Multi-Agent LLM Systems – https://arxiv.org/abs/2606.28425
[10] Guan et al., CodeIP: A Grammar-Guided Multi-Bit Watermark for Large Language Models of Code – https://arxiv.org/abs/2404.15639
[11] Kim, Park, and Han, Marking Code Without Breaking It: Code Watermarking for Detecting LLM-Generated Code – https://aclanthology.org/2026.findings-eacl.207/
[12] Chen et al., DuCodeMark: Dual-Purpose Code Dataset Watermarking via Style-Aware Watermark-Poison Design – https://arxiv.org/abs/2604.10611
[13] Qin et al., EntroBench: Evaluating LLM Watermarking Under Multi-Entropy Scenarios and Practical User Operations – https://aclanthology.org/2026.findings-acl.2089/
[14] Ng, Ngo, and Chattopadhyay, Vaporizer: Breaking Watermarking Schemes for Large Language Model Outputs – https://arxiv.org/abs/2605.07481
[15] Ameen et al., Chainwash: Multi-Step Rewriting Attacks on Diffusion Language Model Watermarks – https://arxiv.org/abs/2605.05503
[16] Tamim and Khan, AI Watermark Evidence Fails Forensic Readiness: An Empirical Evaluation – https://arxiv.org/abs/2607.16010
[17] Pan et al., MarkLLM: An Open-Source Toolkit for LLM Watermarking – https://github.com/THU-BPM/MarkLLM
[18] Xu et al., XMark: Reliable Multi-Bit Watermarking for LLM-Generated Texts – https://aclanthology.org/2026.acl-long.672/
[19] Kirchenbauer et al., Official Implementation of A Watermark for Large Language Models – https://github.com/jwkirchenbauer/lm-watermarking
[20] Spiliopoulou et al., Play Favorites: A Statistical Method to Measure Self-Bias in LLM-as-a-Judge – https://arxiv.org/abs/2508.06709
[21] Yang et al., Quantifying and Mitigating Self-Preference Bias of LLM Judges – https://arxiv.org/abs/2604.22891
[22] Anthropic Fellows, SLEIGHT-Bench: Finding Blind Spots in AI Monitors – https://alignment.anthropic.com/2026/sleight-bench/
[23] Lynch et al., Agentic Misalignment in Summer 2026 – https://alignment.anthropic.com/2026/agentic-misalignment-summer-2026/