How Data and AI Capability Get Laundered From One Purpose to Another, and How to Stop It at the Moment of Use

Abstract Every privacy law says data collected for one purpose must not be quietly reused for another. Yet in most real systems, “purpose” is just a word the requester types into a token, an API field or a contract. A delivery app collects your home address to bring you a parcel; months later, an unrelated advertising system uses the same address to guess your household income. An AI model is accessed “for education”, and its capability ends up serving a harmful goal (an illustrative case, not a claim about any real deployment). When that happens, nobody can prove what was actually allowed, so questions of responsibility between provider, user and jurisdiction become arguments about who said what. A purpose string is a promise anyone can write, and it fails exactly when someone lies. This work turns purpose from a label into something a system can check and refuse. Every attempt to read, send, transform or compute from protected data is treated as a proposal that has no effect yet. A protected enforcement component decides by looking at records the requester cannot edit, not at what the request says about itself. These records include: who the requesting workload really is; which order or workflow the data belongs to; which recipient is assigned; which operation the policy allows; whether that permission is still valid. Only then does it issue a short-lived, single-use permission tied to that exact data, operation, requester and recipient. The final release point checks everything again before anything is decrypted, sent or written. Every decision, approved or refused, leaves a tamper-evident receipt. The paper walks through five versions of the same request, and only the legitimate one gets through: The delivery company asks for the address to deliver the order, and the request succeeds. The advertiser asks openly, and is refused before any profiling starts. The advertiser relabels its request as “delivery”, and nothing changes. The advertiser runs inside a certified secure enclave, and is still refused, because proving the code is genuine is not the same as being allowed to use the data. The advertiser tries to save a derived result such as “high-income household”, and the write is blocked because the result inherits the restriction of the address it came from. The paper answers seventeen hard engineering questions and states plainly what it cannot solve. Copying of data after a legitimate release cannot be stopped. Neither can piecing together sensitive facts from many separately allowed requests. A reference implementation passes 88 tests, 19 cross-language conformance checks and 2,000 attack attempts, with sub-millisecond local decision time. The goal is not to stop legitimate data combination, including advertising. It is to make lawful use provable and unlawful reuse refusable, supporting GDPR purpose limitation (Article 5(1)(b)), data minimisation and accountability, and the data-governance and record-keeping expectations of the EU AI Act. Industry relevance (AI-generated): the work concerns publicly described settings where purpose limitation matters. These include commerce and delivery platforms (Amazon, Uber, DoorDash, Swiggy, Zomato), advertising measurement and data clean rooms (Google Ads Data Hub, AWS Clean Rooms, Snowflake, Databricks), enterprise identity and authorisation systems, and frontier AI providers (OpenAI, Anthropic, Google DeepMind). These are named only as examples. Naming them does not allege misuse, deficiency, non-compliance or infringement, and does not imply endorsement. This industry-relevance and regulatory material is AI-generated, is not legal advice, and must be cross-checked against the original PCT filings and primary sources before drawing any conclusion. This disclosure is based on the Mothership application PCT/IB2026/055615, filed 4 June 2026 and publicly disclosed 16 July 2026 (WO 2026/150382). That application claims priority from PCT/IB2026/053385, filed 7 April 2026 and publicly disclosed 4 June 2026 (WO 2026/115520). The architecture details are as published in Internet-Draft draft-das-purpose-execution-finality-03 on 12 September 2026. A companion analysis on AI inference is available at DOI 10.5281/zenodo.22719527, and related family applications can be cross-checked on WIPO PATENTSCOPE. Licensed under CC BY-NC 4.0. The author is open to acquihire or strategic collaboration. Keywords purpose limitation; purpose laundering; data reuse; AI capability laundering; AI misuse; AI accountability; AI liability; GDPR; GDPR Article 5; EU AI Act; data minimisation; privacy by design; data protection; advertising and privacy; data clean rooms; household profiling; delivery data privacy; data lineage; data provenance; derived data; remote attestation; confidential computing; access control; OAuth; GNAP; zero trust; tamper-evident audit; fail-closed; execution finality; machine enforcement.