Can AI Watermarking Double as User Tracking? What Deployers Must Decide

Watermark keys are identity bindings, and the way you issue them determines whether your Article 50 compliance machinery also functions as a user-tracking system. That is the practical finding of a NeurIPS 2026 position paper (arXiv:2605.13095), a single-team, unreplicated, lab-based study by Toluwani Aremu (MBZUAI), Jie Zhang (A*STAR) and Nils Lukas (MBZUAI). The authors show that when each entity holds its own watermark key, anyone with access to the detector and the key mapping can attribute outputs to that entity with at least 96% accuracy at a 1% false-positive rate per key, the study reports, even when the watermark is a “zero-bit” scheme designed to encode no identity at all. An outside observer with no keys and no detector access still identified the source of outputs with 73.0% top-1 accuracy on text and 91.0% on images, again per the same paper, in the specific configurations tested and after training on up to 4,000 labeled outputs per entity.

The consequence is concrete: deployers locking in machine-readable marking configurations ahead of Article 50 deadlines are making decisions about key granularity, rotation custody and detector access that current watermark evaluations do not report. Those decisions, not the watermarking algorithm itself, determine how much the mark reveals. The paper’s own framing is blunt: “We argue that watermarking should also be evaluated and governed as a monitoring primitive, because the same signal can link outputs to the entity that generated them.”

None of the Article 50 compliance tooling examined for this article surfaces those choices. The products market deadlines and attestation features; they are silent on who can query the detector and how keys map to users. That gap is the subject here.

Two observers, two risks

The paper separates the monitoring risk into two threat models, and the distinction matters because the defenses differ.

The internal observer holds keys, the key mapping and detector access: the provider’s own trust-and-safety team, an abuse investigator, a vendor running detection as a service, or anyone else granted query rights. The measured result is that per-entity keys make attribution near-trivial. Across twelve zero-bit watermarking methods and up to 16 entities, “internal attribution is correct for at least 96% of outputs at a 1% false-positive rate per key” (paper). A zero-bit watermark carries no payload. Its only job is to answer “is this watermarked, yes or no.” Yet because each entity signs with a distinct key, the detector’s yes becomes “yes, and it is key number seven.” Identity leaks through the key structure, not the payload.

The external observer has neither keys, detector access nor the key mapping: a journalist, a researcher, a data broker collecting public outputs. Here the mechanism is different. The authors report that external observers “identify the source of unseen text and image outputs in the configurations we test,” reaching 73.0% top-1 accuracy among 16 entities for KGW text and 91.0% for Tree-Ring images (paper), each after training on up to 4,000 labeled outputs per entity. The apparent mechanism is that per-entity keys leave subtly different statistical fingerprints in the output distribution, enough for a classifier trained on labeled samples to pick them apart. Those labeled samples are the binding constraint: the paper’s experiments “assume suitable labels and do not establish that thousands of such outputs are available for a typical user.”

The control results are what make this a configuration problem rather than an inherent flaw. In the same experiments, “outputs without a watermark or under a shared key leave it near chance, which we establish for one text and one image method.” When everyone shares one key, the identification signal collapses toward chance. The linkage is key-dependent.

The authors are careful about scope in a way deployers should be too: “The concern is not each attribution query but that access granted for one purpose also enables sustained observation, a capability we establish rather than observed misuse.” This is a demonstrated capability in a lab, with up to 16 entities: the internal attribution result spans twelve zero-bit watermarking methods, while the external-identification results and the shared-key and no-watermark controls rest on one text method and one image method. It is not evidence that any deployed provider is tracking users this way, and no evidence examined here documents the key-issuance or detector-access policy of SynthID, OpenAI or any other shipping provider. Whether deployed systems exhibit this risk is an open research question.

The three decisions: key granularity, rotation custody, detector access

The paper names the levers directly: “Both depend on deployment choices that evaluations do not report, namely how fine-grained and persistent the bindings between keys and entities are and who may query the detector.” Working through them:

Key granularity. Per-user keys maximize attribution and maximize monitoring exposure. Per-tenant or per-group keys collapse identity to the group. Shared keys push identification to chance in the tested configurations. The paper’s stated tradeoff: “shared or group-level keys reduce what the watermark reveals to the group, at the cost of entity-specific attribution, although other signals may still identify the entity.” That last clause matters. A shared key “does not establish anonymity where other identifying signals are present”, account logs, API tokens, output style. A shared key removes the watermark as an identifier; it does not anonymize the pipeline.

Rotation custody. Key rotation is standard hygiene, but rotation only limits linkage “when the observer cannot access the mappings between old and new keys.” Whoever holds the old-to-new mapping can stitch a user’s history across rotations. This is a custody question, and the tooling does not answer it. The c2pa-watermark-mcp runbook documents a real rotation procedure:

Q: How do I rotate the signing key? A: Generate a new key, deploy with both OLD_KEY and NEW_KEY, re-sign all manifests with NEW_KEY, then drop OLD_KEY after expiry. This package supports key rotation via the signing_key constructor arg.

The procedure is sound as far as it goes. It says nothing about where the old-to-new mapping lives or who can read it. That is exactly the gap the paper flags, sitting unaddressed in a shipping runbook.

Detector access. Every query right granted for one purpose (abuse investigation, provenance verification, regulator response) also enables sustained observation of whoever the keys identify. The paper asks governance to “limit these bindings and detector access,” and names restricting access to detectors, decoders and key mappings as the lever. The operational detail is left to deployers, so treat what follows as advice rather than the paper’s wording: purpose-bound roles, logged queries, and an explicit decision about which entities the detector can distinguish.

Configuration-to-attribution decision table

The table below combines the paper’s measured outcomes with the governance implications for each configuration. The “attribution exposure” column reflects the lab results except where a row is marked as inference; the “when to choose it” column is judgment, bounded by the paper’s caveats.

One inference to flag clearly: the paper measured ≤16 entities, and its tested configurations were per-entity keys plus shared-key and no-watermark controls, so the group, rotation-mapping and broad-detector-access rows above are inference from the paper’s discussion rather than measured results. How identification accuracy degrades as the entity count grows to thousands or millions is not established by this study. The paper itself calls for evaluations to report attribution and identification accuracy “as functions of the number of entities and of the labeled outputs per entity,” which implies the scaling behavior is unresolved. Treat the 73.0% and 91.0% figures in the paper, each reached with up to 4,000 labeled training outputs per entity, as existence proofs, not as predictions for your user base.

The vendor audit checklist

The compliance tooling market that has formed around Article 50 sells marking, disclosure and attestation. The agent-content-watermark-mcp package, for instance, exposes generate_watermark, verify_watermark and attach_c2pa_manifest operations against Article 50(2) with a C2PA manifest envelope. That is the configuration surface a deployer actually touches, and key granularity and detector access would have to live there. Open its documentation and search for a key-granularity setting or a detector-access policy; neither appears. So the burden falls on the questions you ask before signing off. Based on the paper’s proposed evaluation criteria, a vendor audit should demand:

1. Attribution accuracy, not just robustness. What is the internal attribution accuracy of this configuration, at what false-positive rate per key, across how many entities? If the vendor reports only robustness-to-removal numbers, the monitoring half of the evaluation is missing.
2. External identification accuracy. Has anyone measured whether a keyless observer can classify outputs by source? Under what entity counts?
3. Key issuance policy. Are keys shared, per-tenant or per-user? Can that be configured, or is it fixed by the product?
4. Rotation mapping custody. When keys rotate, who retains the old-to-new mapping, and under what access controls?
5. Detector access scope. Who may query the detector, for what purposes, with what logging? Is query access technically separable from key custody?
6. Payload semantics. Does the watermark payload encode entity-linked identifiers, or opaque per-asset serials?

On payload semantics, at least one shipping design shows the privacy-preserving pattern. Thumprint, a TrustMark variant, uses a 61-bit payload whose serial is explicitly content-free:

serial — opaque asset id (33.5M values). Meaning lives in your database, never in the bits. MAC — HMAC-SHA256(secret key, ver‖key_id‖serial) truncated to 32 bits. TrustMark’s models are public, so anyone can embed a watermark — the MAC is what makes “made by us” unforgeable. key_id — lets you rotate keys later without invalidating old marks.

The identity lives in a local registry the issuer controls, not in the bits anyone can scan. That design choice is directly portable to the deployment decision: keep payloads per-asset and opaque, and resolve meaning behind access controls you govern.

Thumprint’s threat model is also unusually candid about watermarking’s limits: “the secret key IS the product,” lost keys leave marks “detectable but can no longer be verified as yours,” and open-source removers “exist and improve monthly.” Two implications follow. First, robustness claims age quickly, so any vendor evaluation you accept has a shelf life. Second, the detector side is unreliable in the other direction too: Thumprint’s README cites a June 2026 study [unverified] claiming that permissively accepting any TrustMark model with any schema flags 10–20% of ordinary photos (Thumprint README). If accurate, watermark attribution is not audit-grade evidence on its own, and per-user attribution built on top of it inherits that unreliability. That cuts both ways: it weakens the case for aggressive tracking fears, and it weakens the case for treating detector output as proof of anything about a specific user.

Deadline pressure, and why you should verify the date yourself

The urgency around these decisions comes from the EU AI Act’s Article 50 machine-readable marking obligations, which the paper cites alongside California’s 2024 legislation as the reason providers deploy watermarking at all. But the deadline being sold to deployers is not stable across sources. The csoai-watermark-attest-mcp README markets itself as “Built for the 2 November 2026 cliff,” a week out at the time of writing. Two sibling repositories, watermarking-authenticity-mcp and c2pa-watermark-mcp, claim the deadline is 2 December 2026, and watermarking-authenticity-mcp alone says that date was “compressed by May 2026 Omnibus” [unverified]. Thumprint’s README states Article 50 marking applies from 2 August 2026 [unverified], a date that has already passed. Three different dates, all from vendor pages, none verified here against the EUR-Lex text.

The fine exposure cited alongside these dates, €35M or 7% of global turnover, is likewise a vendor README claim [unverified], and some of the same vendors’ pricing pages are internally inconsistent (the attestation tool lists Pro at both £199/mo and £79/mo in different parts of its README). Treat the marketing as a signal that the compliance market is selling urgency, not as a reliable statement of your obligations. Before you lock a configuration, pull the actual Article 50 text and application dates from EUR-Lex; the watermarking-authenticity-mcp repo claims its regulation text syncs daily from the EUR-Lex Cellar SPARQL endpoint, which at least points at the right primary source. The dates you verify may change your timeline. They do not change the configuration decisions, which are the durable part.

What this study does not establish

Every quantitative result here comes from one unreplicated, lab-based team. The internal attribution result covers twelve zero-bit methods, nine for text on Qwen2.5-14B and three for images on Stable Diffusion v2.1, with up to 16 entities; the external results rest on one text and one image method, KGW and Tree-Ring. Three things follow:

• No deployed vendor is implicated. The study establishes a capability, not observed misuse, and the authors say so. No evidence examined here documents any actual provider’s key-issuance or detector-access policy. Whether per-user keys exist in production anywhere is unknown, not merely unproven.
• The scaling behavior is open. Accuracy measured among 16 entities does not predict accuracy for a large user base. The paper’s own evaluation proposal treats entity count as a variable to be measured, which means the current numbers are a lower-bound warning, not a ceiling or a typical case.
• A shared key is not anonymity. It removes the watermark as an identifying signal. Other signals, account metadata, output content, timing, can still identify users. Choosing shared keys is a reduction in exposure, not a guarantee.

Where does that leave the decision? For deployments that owe users anonymity, public-facing generation APIs, tools used by journalists, clinicians or lawyers’ clients, I would default to shared or group-level keys, keep payload identifiers opaque and per-asset, restrict rotation-mapping custody and detector queries to purpose-bound audit roles, and require vendors to report attribution and identification accuracy alongside robustness before sign-off. That posture costs you per-user traceability, which is precisely the point: if you cannot articulate a documented need to trace outputs to individual users, the paper’s evidence says the per-user configuration buys you a monitoring capability you did not ask for and cannot currently measure.

For closed enterprise deployments with a genuine per-user accountability requirement, per-user keys are defensible, but the same evidence says you are issuing persistent pseudonymous identifiers. Govern them like it: log detector queries, bind access to purpose, and put rotation-mapping custody under the same controls as the keys themselves.

The deadline vendors will not raise any of this. Their runbooks rotate keys without saying who holds the mappings, and their audits check disclosure templates without measuring attribution. The paper’s core demand is the one to carry into procurement: watermarking is a provenance primitive that carries a monitoring capability, and until evaluations report both, the monitoring side is a deployment choice you are making blind.