Abstract

A Purpose String Is Not a Promise: Stopping Data-Purpose and AI-Capability Laundering at the Point of Use — Execution Finality for Verifiable Purpose Limitation Under GDPR and the EU AI Act

Abstract

Imagine a powerful AI model accessed under a declared purpose of “education”, whose capability is then used for a harmful end. This is an illustrative case, not a claim about any real deployment. Who is liable: the provider, the user or the jurisdiction? Today that question is often unanswerable, because nothing in the request path could refuse the switch or record what was actually authorised.

The same gap sits at the heart of everyday data sharing. A delivery app collects a home address to deliver an order; an unrelated advertising system later uses that address to infer household income. Data protection law requires purpose limitation, yet at the protocol level purpose is usually a string the requester writes in a token claim, API field or contract. A self-asserted purpose is evidence of intent, not proof of authority, and it fails exactly when the requester lies.

This disclosure makes purpose a conclusion the system derives, not a label the requester supplies:

  • Candidate Act. A request to read, transmit, transform or derive from protected data is held as a non-effective Candidate Act.
  • Binding records. A Protected Enforcement Domain evaluates the request against records the requester cannot write: authenticated workload identity, workflow state, data-to-order association, recipient assignment, versioned policy for the permitted operation, expiry and revocation.
  • Execution Handle. Only after that check does the domain issue a short-lived, non-bearer handle scoped to the exact object, operation, requester and recipient.
  • Finality Sink. Before any release, decryption or write, the sink re-verifies identity, destination and current binding state.
  • Receipts. Every decision, pass or fail, produces a hash-chained, signed validation receipt.

The running example shows five outcomes:

  • the delivery request succeeds;
  • the advertising request is denied before profiling starts;
  • relabelling the purpose as “delivery” changes nothing;
  • an attested enclave still has no authority, because attestation is not authorisation;
  • a derived value such as “high-income household” is rejected on its propagated source lineage, with missing lineage treated as unknown rather than empty.

Seventeen engineering questions are answered, covering binding-authority compromise, TOCTOU, lineage stripping and substitution, legacy databases, external APIs, transformations, mixed datasets, alternate paths and denial of service. The limits are stated openly: plaintext copied after legitimate release, mosaic aggregation and decomposition are not solved. A reference implementation reports 88 tests, 19 conformance vectors run in Python, Go and Node.js, and 2,000 adversarial trials, all denied, with p95 local latency of about 0.21 ms in memory.

Industry relevance (AI-generated): the architecture concerns publicly described environments where purpose limitation matters, including:

  • commerce and delivery data (Amazon, Uber, DoorDash, Swiggy, Zomato);
  • advertising measurement and data clean rooms (Google Ads Data Hub, AWS Clean Rooms, Snowflake, Databricks);
  • enterprise identity and authorisation (Microsoft Entra, OAuth and GNAP ecosystems);
  • frontier AI providers (OpenAI, Anthropic, Google DeepMind), whose model capability can be obtained under one declared purpose.

These are named only as examples. Naming them does not allege misuse, deficiency, non-compliance or infringement, and does not imply endorsement. Regulatory context includes GDPR purpose limitation and compatibility of further processing (Articles 5(1)(b) and 6(4)), data minimisation and accountability, EU AI Act data-governance and record-keeping duties, the EU Data Act, India’s DPDP Act and US state privacy laws. 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 technical 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, 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; capability laundering; GDPR Article 5(1)(b); compatibility of further processing; EU AI Act; data minimisation; accountability; purpose-based access control; ABAC; XACML; OAuth; GNAP; RFC 8707; attestation is not authorisation; derived data lineage; data provenance; information flow control; data clean rooms; ad targeting; AI model misuse; AI liability evidence; execution finality; non-bearer Execution Handle; Finality Sink; fail-closed; machine enforcement.

Creative Commons License

Creative Commons License
This work is licensed under a Creative Commons Attribution-Noncommercial 4.0 License

Download

Share

COinS