Paint writes a server-issued ID into locally generated pixels, and egress logs will never see it

Network monitoring is the wrong instrument for this, and it fails in a specific direction. It would catch the outbound leg: Paint sends the prompt and the chosen style to a Microsoft moderation endpoint before the local model runs, and rejects the reply if either returned ID is all zeros ^[4][20]. Microsoft's own documentation already says the feature needs a signed-in account and an internet connection while the NPU does the generation ^[9]. What no egress rule catches is the return leg, because the server's chosen value leaves the process as pixels in a file ^[5].

The encoding tells you how hard it is meant to be to remove. Li describes a 144-bit message assembled from the GUID plus a prefix and a checksum, distributed through small changes to selected image blocks with each bit written at least three times, imperceptibly rather than as metadata ^[7]. A 16-byte identifier is 128 bits, so 16 bits of that message are framing ^[24], and the triple-placement rule puts a floor of 432 bit writes into the image ^[25]. That is a design intended to survive re-encoding, which is exactly what C2PA calls a soft binding: provenance that can still be matched after embedded file metadata is stripped ^[12]. The same watermarkId also appears in the signed C2PA manifest, in an assertion naming the algorithm com.microsoft.invismark.1 ^[11].

Then there is the failure philosophy, which is where the invariant gets interesting. In Paint, a watermarking failure is converted into a failure of the whole generation, so by design an unmarked image does not exist ^[6][18]. The same Watermarker.dll turns up in Microsoft Photos, where the dev.to writeup reports the code logs the error and carries on returning the image ^[15][19]. One library, two contracts. Anyone reasoning about "all output from this pipeline is marked" is reasoning about a per-app decision, not a platform guarantee. The user-facing control does not help either: the toggle for the visible Copilot logo runs a different code path and does not govern the pixel-level mark ^[8].

On sourcing, be careful. Both accounts trace to one analysis, published on August 24th by Xusheng Li, a core developer of Binary Ninja who leads its debugger work at Vector 35 ^[1][2], against Paint 11.2605.71.0, which ships encrypted ONNX models including a 302.4 MB image generator ^[3]. The dev.to writeup says its author does not own a Copilot+ PC and did not reproduce the work ^[22]; it reached the top of Hacker News with more than 500 points ^[21]. Li does not claim the GUID identifies a person, and describes the end-to-end reuse of one server-assigned value as the stronger finding ^[16]; nor does the analysis establish that the shipped code matches Microsoft's published InvisMark repository ^[13].

The gap that matters for anyone writing assurances is narrower than the headline. Microsoft discloses the C2PA manifests, the cloud filtering, and the collection of prompts with device and user identifiers, but not the pixel-level encoding, and not that the moderation response supplies the value written into local output ^[14]. So the audit target is the saved artifact, in every format the app writes ^[23], and the question is whether anything in it came from a server.