When you generate an image using Paint on a computer equipped with dedicated AI silicon, the entire process actually checks in with Microsoft’s cloud servers twice. Many assume that once a model is downloaded to a machine, compute runs in a self-contained local loop and works even with the network cable unplugged. However, according to reverse engineering analysis published by Xusheng Li, the local image generation pipeline in Microsoft Paint and Photos consists of five fixed steps. This pipeline is already spinning in the cloud before the local hardware even kicks in.
When you enter a prompt and click generate, the local chip is still on standby while the system first sends the prompt and parameters to Microsoft’s moderation servers. Once cloud review passes, it returns the modified prompt along with two one-time unique IDs. These two IDs have distinct roles: one flags the generation request, while the other serves as the invisible watermark ID. After obtaining these IDs, the local chip loads the model and starts rendering the image. Once generated, the system invokes a watermarking module to embed the watermark ID into the pixels—in the author’s synthetic image tests, this module subtly tweaked over 70% of the pixels. Finally, upon saving the image, the client must upload the image back to the cloud to request a C2PA-compliant Content Credential signed by Microsoft, and only writes the file locally after receiving the credential payload.
Two unexpected engineering facts are tucked inside this workflow. The watermark module acts as a hard gate in Paint: if embedding fails, it aborts immediately with an error and produces no image; in Photos, however, a write failure merely logs a single line while the image is output as usual (original reverse engineering report). Content Credential signing is itself a cloud service: locally rendered images must be uploaded to the cloud for stamping to obtain trusted credentials.
The division of labor between the two IDs is equally intriguing. Photos embeds the request ID into pixels, whereas Paint embeds the watermark ID into pixels and includes the previous request ID in the next moderation request so the server can stitch sessions together. As the reverse engineer noted, local generation does not mean everything happens locally: Microsoft moderates prompts and issues unique IDs in the cloud, and the drawing software then bakes those IDs into the generated image.
Cross-referencing official Microsoft documentation reveals the boundaries of vendor disclosure. In its Paint feature instructions and image generation support page, Microsoft outlines several requirements: local features require account sign-in and an active internet connection, the cloud filters content and collects device and user identifiers to prevent abuse, violations lead to account bans, and files include Content Credentials. What remains unstated officially: invisible watermarks are embedded in pixels, watermark IDs are dynamically issued by servers, IDs may be linked to user accounts, and how long these logs are retained. As early as September 2023, Microsoft disclosed time-stamped invisible watermarks for cloud-based generation in an official Bing blog post, but made no mention of it in documentation for local features.
After this reverse engineering sparked discussions on Hacker News, people quickly confirmed that what was embedded in the image was a generation serial number. This raises a core question: is this architecture—rendering locally while issuing IDs and keeping ledgers in the cloud—a peculiar choice unique to Microsoft, or the standard blueprint drawn up by the entire industry?
Major vendors share a remarkably consistent architecture for on-device AI: compute can be offloaded to devices, but governance rules must remain on servers. Major vendors have drawn a clear line between compute workloads and safety controls. We can line up the designs of several leading vendors side by side:
| Vendor & System | Where Inference Runs | Where Control Plane & Signing Reside | Can User Disable It |
|---|---|---|---|
| Microsoft Paint & Photos | Local silicon | Cloud moderation & online issuance | Cannot be disabled |
| OpenAI Generation Services | Cloud clusters | Centralized cloud issuance & verification | Cannot be disabled |
| Google Image Generation | Cloud | Cloud watermark injection | Invisible layer cannot be disabled |
| Apple Intelligence Photo Editing | Local hardware | System-baked SynthID invisible watermark | Cannot be disabled |
| Meta Content Seal | Product-dependent | Cloud decoding & verification service | Verification must go through cloud |
| Adobe Firefly | Cloud clusters | Cloud credential issuance | Cannot be disabled |
Specific implementations across vendors exhibit the same underlying logic. In May 2026, OpenAI announced its content provenance strategy, bundling Content Credentials, invisible watermarks, and online verification tools together, making cloud API calls mandatory for authenticity verification. Adobe’s tools rely on cloud compute, with Content Credentials directly issued by Adobe servers. While Meta’s Content Seal scheme embeds invisible watermarks into multimodal content, external detection and provenance tracing still require sending files back to Meta’s servers for analysis.
Google demonstrated a tiered watermarking logic in its Nano Banana Pro announcement. Free and Pro tiers retain the visible Gemini sparkle icon, while Ultra subscriptions and AI Studio allow removing the visible badge; however, the deep SynthID invisible watermark remains enabled across all tiers. In the eyes of vendors, surface-level visible badges are commercialized features, while deep invisible watermarks form the non-negotiable foundation.
Among all vendors, Apple presents an example with the narrowest control plane. According to Apple’s official Apple Intelligence announcement in June 2026, Apple Intelligence relies primarily on on-device generation, and photo editing automatically embeds an un-disableable SynthID invisible watermark to identify AI-edited photos. Apple provides no toggle to turn it off, nor does any public material show a per-request cloud issuance step.
The fundamental industry reality is clear: as of August 2026, we found no consumer vendor that abandons cloud governance for on-device runtimes. Every vendor maintains a control plane; the only difference lies in its breadth. Microsoft’s peculiarity lies in how it combines these mechanisms: embedding cloud-issued per-request serial numbers into pixels, enforcing watermark insertion as a strict prerequisite for image output, and maintaining minimal disclosure in local documentation. While precedents exist for each of these three elements across the industry, Microsoft is currently the only vendor to stitch them all together.
Model weights can be downloaded to local hard drives, but the rules and ledgers that govern model behavior must stay in the vendor’s hands. Borrowing concepts from networking systems, model weights and matrix operations belong to the data plane handling the payload—the actual compute process of rendering an image; moderating prompts, assigning identities, cryptographic signing, and auditing constitute the control plane. In this wave of on-device AI evolution, vendors have pushed only the data plane down to user devices, keeping the control plane firmly anchored in the cloud.
Four mechanistic reasons explain why the control plane remains in the cloud. The first reason is that safety moderation rules require remote, dynamic updates. Adversarial examples and jailbreak prompts on the internet evolve constantly, allowing vendors to adjust filtering strategies in the cloud at any time. If moderation logic were bundled into local software, every update would have to wait for an OS or application release—a delay that would leave a dangerous window of vulnerability for safety guardrails.
The second reason is that abuse prevention relies on a centralized ledger of associations. The core imperative of governance mechanisms is having an auditable chain of evidence when violations or copyright infringements occur. If every identifier were generated offline by local devices without server-side stubs, post-hoc traceability would break. The issuance records stored on centralized servers are not incidental byproducts of data exchanges—they are the very core purpose of operating the governance system.
The third reason is that the credibility of digital signatures and credentials stems from the issuer. In cryptographic systems, a credential is trusted because the signing private key is held by an accredited, authoritative entity. If local software were allowed to self-sign with local private keys, such self-asserted claims would carry no credibility with third parties. To ensure cross-platform credibility for content, signatures must be executed back on cloud servers holding trusted certificates.
The fourth reason is that laws and regulations place compliance liability squarely on service providers. Whether enforcing safety moderation or injecting provenance markers, regulatory statutes consistently target commercial entities offering AI services, not the end users purchasing PCs. Vendors cannot evade statutory compliance duties simply because models execute on-device; naturally, they must maintain tethered control cords to the cloud in software. Sinking the data plane cuts latency for users and saves costly compute for vendors, while retaining the control plane in the cloud safeguards the vendor’s regulatory baseline and administrative authority.
Industry standards and legal statutes only require proving that content was generated by AI; they do not mandate linking each generation to a specific individual. As images circulate online, screenshots, compression, and metadata stripping are virtually unavoidable, frequently wiping out attached metadata. To ensure provenance remains identifiable even after this data is stripped, technical experts devised methods to blend markers directly into pixel values.
In the terminology of C2PA Specification 2.4, weak associations embedded directly within content are called soft bindings, while hash-verified strong associations are called hard bindings. Section 9.2 of the specification explicitly states that soft bindings must not be treated as hard bindings and do not provide robust tamper-proofing.
Under C2PA Implementation Guidance 4.2.6, whenever a system establishes a soft binding using watermarking, the generated credential manifest must record the watermarking action and corresponding assertion. In the reverse-engineered samples, Microsoft’s generated manifest records the watermarking algorithm alongside the identifier written into pixels. However, the specification itself only requires recording this field; it does not dictate that the identifier must be a distinct serial number rotated with every generation. Designing it as a globally unique serial number is Microsoft’s own engineering implementation. In advisory clauses, Guidance 4.2.7 cautions that querying centralized databases for credentials incurs privacy costs and recommends that vendors ensure user awareness. Regarding format support, Microsoft omits legacy BMP format, which technically cannot embed credential manifests.
Legal provisions reflect the same distinction. Article 50(2) of the EU AI Act establishes a statutory baseline, requiring providers to ensure AI system outputs are marked in a machine-readable format so third parties can detect that content was generated or manipulated by artificial intelligence. The core requirement of this provision is ensuring detectability; nowhere does it mandate tracing each generation act precisely back to a specific individual operator.
According to the Act’s rollout timeline, disclosure obligations under Article 50(4) for deepfake content officially came into force on August 2, 2026. The compliance grace period under Article 50(2) for legacy systems extends through December 2, 2026, while the deadline for watermarking detection interoperability solutions is February 2, 2027.
Regulation requires machines to recognize that content originated from AI, not to pinpoint who generated it and when. Going from generic markers that satisfy detectability to assigning unique serial numbers per prompt is an extra step built by vendors as their own risk control mechanism above the regulatory floor—not a legal mandate.
To evaluate how private an on-device AI product truly is, don’t look at the “local” badge plastered across marketing materials; look at which interfaces tether it to the cloud. Confronted with various AI tools advertising local and offline operation, we only need to examine three key data interfaces to see the true shape of their control planes.
The first interface is whether prompts leave the device: before local silicon begins generating images, must input prompts and parameters be sent to remote servers for safety filtering? The second interface is who issues identity markers: are feature marks or serial numbers embedded deep within files computed independently by the local device, or dispatched and registered by cloud services? The third interface is how long moderation and issuance logs are retained in the cloud: after servers process a request, how long do your user account, device attributes, and operational logs linger in the vendor’s database?
Applying these three interfaces to our vendor matrix makes each player’s trade-offs obvious. Apple focuses primarily on on-device generation, shows no similar cloud moderation actions in public documentation, and bakes SynthID invisible watermarks into Apple Intelligence photo editing; Google maintains an un-disableable invisible watermark in the cloud as a baseline defense; Microsoft executes the full suite across prompt offloading, server-side ID issuance, and dual binding across pixels and credentials. On the third interface, the silence in official Microsoft documentation regarding log retention duration represents the most pressing unanswered question in today’s on-device ecosystem.
When evaluating such architectural designs, we must distinguish between technical evidence and emotional speculation. Reverse engineer Xusheng Li was rigorous in his original report, explicitly stating that he found no official disclosure explaining the link between server-issued watermark IDs, prompt moderation, and pixel watermarking. What he proved was the data transmission mechanism between client and cloud; he never claimed to have accessed or inspected Microsoft’s backend server databases. Certain media outlets sensationalized this finding as a surveillance tool capable of pinpointing personal identities—an inference that overreaches what public technical evidence supports. Reporting by The Register on August 25, 2026 noted that Microsoft had not responded to requests for comment, and as of August 30, 2026, no official statement has been issued.
The failure modes of this multi-layered design also validate our discussion on layered defense in the previous article. Attached Content Credentials rely on standard file format containers; once an image is screenshotted, reformatted, or compressed by social media platforms, metadata is lost and validation explicitly fails with an error. Invisible pixel watermarks are blended directly into the image matrix, surviving routine format conversions but degrading silently under heavy distortion or noise interference. Vendors combine both essentially so that these two failure modes complement each other.
On-device hardware and local models certainly save users latency and spare vendors the steep costs of cloud compute. But assessing where control over an on-device product truly lies comes down to whose server holds the audit ledger across the generation pipeline; how many gigabytes of model weights reside on your local drive tells you nothing about governance boundaries.