On 20 August 2026, security researcher Xusheng Li published a reverse-engineering write-up of Watermarker.dll, a component shipping inside Microsoft Paint and Photos. The finding is narrower than the headlines suggested, and considerably more interesting. Paint does not watermark your ordinary edits. It watermarks AI-generated images, including the ones generated entirely on your own machine. And the identifier it embeds does not come from your machine at all.
That distinction is the whole story. On a Copilot+ PC, Cocreator runs Stable Diffusion inference locally on the NPU. The image never leaves the device. The identifier stamped into it does: it arrives as a watermarkId in the response from a remote prompt-moderation endpoint, alongside a promptGenerationId, a revisedPrompt, and a containsHumanReference flag. Successive requests carry a lastPromptGenerationId, chaining one generation to the next.
Most teams have spent the past year treating content provenance as a compliance checkbox. What this research shows is that provenance metadata has quietly become an identity layer, and almost nobody has audited what their asset pipeline is now carrying.
TL;DR
- Microsoft Paint and Photos embed a server-issued 16-byte GUID into AI-generated images, both as a signed C2PA manifest and as an invisible pixel-domain watermark. Ordinary edits are not affected.
- The GUID is issued by a remote moderation endpoint even when image generation runs locally on-device, and consecutive generations are linked server-side via a session chain.
- The pixel watermark survives metadata stripping, so “we strip EXIF on upload” is not a control. In one 512×512 test the encoder modified roughly 193,000 of 262,144 pixels.
- Embedding is a hard dependency: if the watermark cannot be written, Paint refuses to return the image, and saving to formats that cannot carry C2PA is blocked.
- EU AI Act Article 50 asks whether content is synthetic, a yes-or-no label. What is actually shipping is a unique per-generation identifier. Those are different things, and your governance policy probably only covers the first.
A label and an identifier are not the same thing
Article 50 of the EU AI Act, whose transparency obligations applied from 2 August 2026, requires that synthetic content be machine-readably marked as synthetic. That is a boolean. It answers one question: was a machine involved?
A GUID answers a different question entirely: which generation was this, on which account, from which prompt, in which session. The C2PA soft-binding assertion in these files (algorithm com.microsoft.invismark.1) records exactly that identifier, and the pixel watermark carries the same value redundantly. The vendor holds the map from GUID to account and prompt. You hold the artefact.
For most consumer use that is unremarkable. For an agency shipping client work it is a governance question that nobody put on the risk register. Two images produced in the same session, delivered to two different clients, are correlatable by anyone with access to the server-side records. A “generic” illustration in a public pitch deck ties back to the account that made it. An asset in an anonymised case study is not anonymised in the way you assumed.
None of that requires bad faith on the vendor’s part. It only requires that the data exists, that it is retained, and that it can be compelled or breached. That is the standard threat model for any identifier, and provenance identifiers have been getting a pass because everyone filed them under “compliance” rather than “tracking”.
Redundancy is the feature and the problem
Provenance systems are deliberately built with two layers. The manifest is a cryptographically signed sidecar in the file’s metadata. The soft binding is a watermark in the pixels themselves, so that when the metadata is inevitably stripped by a social platform or a resize pipeline, the identifier survives and can be matched back.
That design is sound for its stated purpose, which is fighting deepfakes and synthetic media laundering. It is also the reason the standard mitigation your team already has in place does not work. Most content pipelines strip EXIF and XMP on ingest, for good privacy reasons. Stripping metadata removes the manifest and leaves the watermark. The image still carries the GUID; you have simply removed the part you could read.
The robustness numbers are worth sitting with. The encoder needs a minimum of 192×192 pixels, spreads 144 bits across the image, and requires at least three successful placements per bit. In a 512×512 test it modified roughly 193,000 of 262,144 pixels. This is not a corner-case tweak to a few LSBs. It is a pervasive, content-adaptive modification designed to survive recompression, cropping and rescaling.
And detection is asymmetric. You can check for a C2PA manifest with standard tooling. You cannot reliably check for the pixel watermark without the vendor’s detector. Any audit you run on your own asset library will therefore give you a false negative on exactly the layer that persists. Be honest about that limitation rather than reporting a clean scan.
Provenance is now an uptime dependency
There is an availability angle that deserves more attention than it has had. Paint treats a watermark embedding failure as a total generation failure and refuses to return the image. It also blocks saving to formats that cannot preserve C2PA metadata. And because the identifier is server-issued, local generation still requires an account and a network connection.
Read that as an architecture pattern rather than a Microsoft complaint, because it is going to be copied. A creative feature that runs entirely on-device now has a hard runtime dependency on a remote service that exists for moderation and identification. If you are designing or procuring tooling for a content team, that is a single point of failure sitting in the middle of a workflow that used to be offline. Ask about it during evaluation, because it will not be in the marketing material.
What to actually do about it
This is a small amount of work, and it is the kind of thing that is embarrassing to be asked about and not have done.
- Inventory your generation surfaces. Not just the obvious image tools. Screenshot utilities, design plugins, presentation software and documentation tooling have all been quietly acquiring generative features. Find out which ones write provenance data, and whether the identifier is locally derived or server-issued.
- Scan for manifests, and record what you cannot scan for. Run C2PA-aware tooling across your asset library to find manifests. Then document explicitly that pixel-domain soft bindings are outside your detection capability. An audit that hides its own blind spot is worse than no audit.
- Fix the policy gap, not just the pipeline. Most AI usage policies say something like “label AI-generated content”. Rewrite the clause to distinguish between a synthetic-content label, which you want, and a unique per-generation identifier linked to an account, which you should be making a deliberate decision about.
- Get it into client contracts. If you deliver assets under an NDA, you need a position on embedded identifiers before a client’s legal team asks for one. Say what your tools embed, say what you cannot remove, and say so before delivery rather than after.
- Separate accounts for separate clients. Where generation is server-linked, shared accounts create correlatable session chains across client boundaries. This is the same discipline you already apply to cloud credentials, applied to a surface nobody thought to classify.
The wider pattern
We have written before about content authenticity as a defensive measure, protecting brands against synthetic impersonation. This is the mirror image: what your own toolchain writes into artefacts on the way out. Both matter, and only one of them is currently on anyone’s roadmap.
The broader lesson is one we keep running into with AI features generally. The interesting risk is rarely the model. It is the operational scaffolding built around the model, the moderation call, the telemetry, the account linkage, the thing that turns a local computation into a networked one. That scaffolding ships silently, it is documented thinly if at all, and it accumulates in your systems while your dependency audit terminates at the package manifest.
The teams that will handle the next few years well are the ones treating AI features as supply chain, not as product features. That means asking what leaves the machine, what gets written to the artefact, and what a vendor retains, before the tool is standardised across the company rather than after a client asks an awkward question.
Need help auditing this?
REPTILEHAUS builds and secures software for teams who need to know what their stack is actually doing. We run AI tooling audits, content pipeline reviews and DevOps hardening for agencies, SaaS companies and management teams who would rather find this sort of thing themselves than have a client find it for them. If you are rolling out generative tooling and want the governance to be real rather than performative, get in touch.
📷 Photo by George Prentzas on Unsplash
