Data-Purpose Laundering Prevention: Execution-Finality for Preventing Cross-Domain Data Reuse
draft-das-purpose-execution-finality-03
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Sangam Das | ||
| Last updated | 2026-09-29 (Latest revision 2026-09-11) | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Additional resources |
Before Comparing Meta Muse / Sentinel, Read the Earlier DAS Disclosures: An AI-Assisted Primary-Source Technical Guide — Zenodo
Purpose Execution Finality Validator — GitHub: Runnable reference implementation The Internet Solved Communication. It Never Solved Authority. — Zenodo. Broader technical background on the execution-finality gap. |
||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-das-purpose-execution-finality-03
Individual Submission S. Das
Internet-Draft Independent Inventor
Intended status: Informational 12 September 2026
Expires: 16 March 2027
Data-Purpose Laundering Prevention: Execution-Finality for Preventing
Cross-Domain Data Reuse
draft-das-purpose-execution-finality-03
Abstract
Consider a concrete case: a user invokes a highly capable AI model
under a declared purpose of education, but the resulting capability
is in fact used for a military or terrorist end -- an illustrative
example, not a claim about any real deployment. When such misuse
surfaces, an unresolved question follows: is the model provider
liable, is the user liable, or is the jurisdiction that permitted the
deployment liable? This document does not answer that question --
liability determination remains an external legal question for the
responsible court, regulator, or contracting parties -- but it
addresses the technical gap that makes the question unanswerable
today. Systems that collect data, or grant capability, for one
stated purpose routinely permit that data or capability to be
consumed for a different purpose, not because the second use was
authorized, but because nothing in the protocol path was capable of
refusing it or of recording what was actually authorized. The most
common technical control in deployment today is a self-asserted
purpose string: a "purpose" claim in a token, a field in an API
request, a comment in a data-sharing agreement. A self-asserted
string is evidence of intent, not proof of authority, and it fails
precisely when it matters most -- when the requester lies. This
architecture addresses that loophole deterministically: it makes an
undeclared or purpose-switched use technically detectable and
refusable at the point of use, and it produces verifiable evidence of
what was actually authorized, so that any subsequent liability
determination can be argued from that evidence rather than from an
unverifiable self-assertion. Achieving that determinism introduces a
bounded, measurable amount of evaluation latency at the point of use;
this document treats that latency as an acceptable, secured trade-off
for closing an otherwise unverifiable gap, not as a cost to be
minimized at the expense of the guarantee. The premise is not that
AI innovation should slow down, any more than cars should be built
slower; it is that innovation moving this fast needs the technical
equivalent of a seat belt.
Das Expires 16 March 2027 [Page 1]
Internet-Draft Data-Purpose Laundering Prevention September 2026
A runnable reference implementation accompanies this document at
Purpose Execution Finality Validator -- Runnable Reference
Implementation (https://github.com/sangmdas/Purpose-Execution-
Finality-Validator-to-Prevent-Data-Purpose-Laundering-in-AI-Systems).
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 16 March 2027.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 8
3.1. Self-Asserted Purpose Is Not Verifiable Purpose . . . . . 8
3.2. Attestation Answers a Different Question Than
Authorization . . . . . . . . . . . . . . . . . . . . . . 9
3.3. Derived Data Carries the Restriction, Not Just the
Value . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.4. The Residual Limit: Plaintext Already Released . . . . . 9
4. Architecture Overview . . . . . . . . . . . . . . . . . . . . 9
5. Worked Example . . . . . . . . . . . . . . . . . . . . . . . 10
5.1. Collection: Binding the Data Object to a Permitted Use . 10
5.2. A Legitimate Request . . . . . . . . . . . . . . . . . . 10
Das Expires 16 March 2027 [Page 2]
Internet-Draft Data-Purpose Laundering Prevention September 2026
5.3. An Unauthorized Request . . . . . . . . . . . . . . . . . 11
5.4. A Relabeled Request . . . . . . . . . . . . . . . . . . . 12
5.5. A Request From Inside an Attested Enclave . . . . . . . . 12
5.6. A Request for a Derived Value . . . . . . . . . . . . . . 13
5.7. What This Architecture Does Not Close . . . . . . . . . . 13
6. Threat Model . . . . . . . . . . . . . . . . . . . . . . . . 13
7. Relation to Existing Work . . . . . . . . . . . . . . . . . . 15
8. Relevance to IETF Working Groups . . . . . . . . . . . . . . 15
8.1. GNAP . . . . . . . . . . . . . . . . . . . . . . . . . . 15
8.2. OAUTH . . . . . . . . . . . . . . . . . . . . . . . . . . 16
8.3. RATS . . . . . . . . . . . . . . . . . . . . . . . . . . 16
8.4. SPICE . . . . . . . . . . . . . . . . . . . . . . . . . . 16
8.5. SECDISPATCH . . . . . . . . . . . . . . . . . . . . . . . 16
8.6. PEARG (IRTF) . . . . . . . . . . . . . . . . . . . . . . 17
9. Security Considerations . . . . . . . . . . . . . . . . . . . 17
10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 17
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17
13. Resources . . . . . . . . . . . . . . . . . . . . . . . . . . 18
13.1. Primary Reference Implementation . . . . . . . . . . . . 19
13.2. Other Reference Implementations . . . . . . . . . . . . 20
13.3. Companion Engineering Analysis . . . . . . . . . . . . . 20
14. Latency Characteristics (Non-Normative) . . . . . . . . . . . 21
15. Feasibility and Legacy System Integration . . . . . . . . . . 22
16. Engineering Considerations . . . . . . . . . . . . . . . . . 25
16.1. Does the Architecture Merely Move Trust Into an External
Database? . . . . . . . . . . . . . . . . . . . . . . . 26
16.2. What if the Authoritative Binding Authority Itself Is
Compromised? . . . . . . . . . . . . . . . . . . . . . 27
16.3. Is This Not Simply Moving the Security Problem
Elsewhere? . . . . . . . . . . . . . . . . . . . . . . 28
16.4. Why Is an Authenticated Binding Record Not Sufficient by
Itself? . . . . . . . . . . . . . . . . . . . . . . . . 29
16.5. What if Authoritative State Changes After Validation but
Before Effectuation? . . . . . . . . . . . . . . . . . 30
16.6. Can an Attacker Remove source_lineage and Make Restricted
Ancestry Disappear? . . . . . . . . . . . . . . . . . . 31
16.7. How Does the Finality Sink Know That Provenance Was
Required? . . . . . . . . . . . . . . . . . . . . . . . 32
16.8. What Happens When Governed Data Passes Through an External
API? . . . . . . . . . . . . . . . . . . . . . . . . . 33
16.9. What if an External API Strips All Provenance
Metadata? . . . . . . . . . . . . . . . . . . . . . . . 35
16.10. How Can This Work With a Legacy Database That Cannot Be
Modified? . . . . . . . . . . . . . . . . . . . . . . . 35
16.11. What if the Database Object Changes but Its Governance
State Does Not? . . . . . . . . . . . . . . . . . . . . 36
Das Expires 16 March 2027 [Page 3]
Internet-Draft Data-Purpose Laundering Prevention September 2026
16.12. What Prevents Copying Valid Lineage From One Object to
Another? . . . . . . . . . . . . . . . . . . . . . . . 37
16.13. What Prevents Transformation From Washing Away the
Restriction? . . . . . . . . . . . . . . . . . . . . . 37
16.14. What if Several Datasets Are Combined and Only Some Are
Restricted? . . . . . . . . . . . . . . . . . . . . . . 39
16.15. Does Execution Finality Solve Cross-Session or Mosaic
Aggregation? . . . . . . . . . . . . . . . . . . . . . 39
16.16. What if a Prohibited Operation Is Split Into Many Harmless
Ones? . . . . . . . . . . . . . . . . . . . . . . . . . 40
16.17. What if Another Path Bypasses the Finality Sink? . . . . 41
16.18. Does Fail-Closed Provenance Checking Create
Denial-of-Service Risk? . . . . . . . . . . . . . . . . 42
16.18.1. Latency and Benchmark Scope . . . . . . . . . . . . 43
16.19. Can the Requester Be the Authoritative Source of
Purpose? . . . . . . . . . . . . . . . . . . . . . . . 44
16.20. Does the Architecture Apply to Every AI Inference
Request? . . . . . . . . . . . . . . . . . . . . . . . 44
16.21. Is Purpose Not Semantic and Therefore Unenforceable
Cryptographically? . . . . . . . . . . . . . . . . . . 45
16.22. Summary of Engineering Invariants . . . . . . . . . . . 45
17. Normative References . . . . . . . . . . . . . . . . . . . . 47
18. Informative References . . . . . . . . . . . . . . . . . . . 47
Appendix A. Primary Reference Implementation -- Detailed
Validation Methodology . . . . . . . . . . . . . . . . . 51
A.1. Recorded Test Environment . . . . . . . . . . . . . . . . 52
A.2. Baseline Candidate Act, Binding Record, and Validation
Context . . . . . . . . . . . . . . . . . . . . . . . . 52
A.3. PED Decision Sequence . . . . . . . . . . . . . . . . . . 53
A.4. Execution Handle Lifetime Clamping . . . . . . . . . . . 53
A.5. Mutation and Threat-Model Testing . . . . . . . . . . . . 54
A.5.1. Purpose-Relabel Attack . . . . . . . . . . . . . . . 54
A.5.2. Additional Negative-Control Conditions . . . . . . . 54
A.5.3. Derived-Data Lineage . . . . . . . . . . . . . . . . 55
A.5.4. Trusted-Record Compromise . . . . . . . . . . . . . . 56
A.6. LAVR Generation, Chaining, and Tamper Detection . . . . . 56
A.7. Replay and Concurrency Testing . . . . . . . . . . . . . 56
A.8. Cross-Language Conformance . . . . . . . . . . . . . . . 57
A.9. Deterministic Adversarial Stress Testing . . . . . . . . 57
A.10. Latency by Topology, with Repeated Runs . . . . . . . . . 57
A.11. What the Testing Supports, What It Does Not, and Residual
Risks . . . . . . . . . . . . . . . . . . . . . . . . . 58
A.12. Reproduction . . . . . . . . . . . . . . . . . . . . . . 60
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 60
Das Expires 16 March 2027 [Page 4]
Internet-Draft Data-Purpose Laundering Prevention September 2026
1. Introduction
Purpose limitation is a stated requirement across data protection
law, sectoral regulation, and internal governance policy: data
collected for one purpose should not be repurposed for another
without new authority. It is, at the protocol level, almost never
enforced. What is typically enforced is that a request carries a
"purpose" value the requester chose to write down.
This gap is not a corner case. It is the default shape of most data-
sharing architectures in production today: an access-control check
confirms that a caller is _permitted to call the API_, and a
separate, unenforced convention -- a contract clause, a privacy
notice, a code comment -- says what the caller is supposed to do with
the response. Nothing in the request path distinguishes a truthful
purpose claim from a false one, because the claim was never checked
against anything the requester does not control.
This document uses a single concrete scenario to walk through what
changes when purpose is treated as something to be verified rather
than declared. A delivery application collects a home address in
order to fulfil an order. An unrelated advertising system later
attempts to use that same address to infer household income for ad
targeting. Every variation of that attempt -- a direct request, a
relabeled request, a request issued from inside an attested secure
enclave, a request for a value merely _derived_ from the address --
is traced through an enforcement boundary that answers one question
before doing anything else: is this caller, this operation, and this
destination actually authorized, based on records the caller cannot
write to?
The architecture generalizes past the delivery/advertising example to
any setting where data crosses an organizational, workload, or trust
boundary and the receiving side has an incentive to reuse it for
something other than what it was released for: cross-tenant AI agent
tool use, cross-border data transfer under jurisdictional
restriction, and inter-service data sharing inside a single company
under an internal purpose limitation policy are all instances of the
same problem. This document keeps the running example narrow so the
mechanism stays concrete; companion drafts in the same series
([DAS-EU-AI-ACT], [DAS-GLOBAL-PRIVACY], [DAS-PRECISION-EGRESS]) apply
the same underlying architecture to EU AI Act high-risk system
enforcement, general-purpose privacy-execution enforcement, and
precision-bounded data egress respectively.
[FUTURIUM-PURPOSE-LAUNDERING] develops the GDPR purpose-limitation
and high-risk AI governance framing of this same delivery/advertising
pattern in regulatory detail, and [FUTURIUM-PAPER-COMPLIANCE]
situates that framing within the broader argument for moving from
Das Expires 16 March 2027 [Page 5]
Internet-Draft Data-Purpose Laundering Prevention September 2026
paper compliance to technical enforcement under GDPR and the EU AI
Act; this document is the protocol-mechanics counterpart to that
discussion. See Section 13 for a Resources pointer to the drafts and
the runnable reference implementation that develop these mechanics
further.
This document specifies an execution-finality architecture in which a
Candidate Act to read, transmit, or derive from a protected data
object does not become effective merely because a caller labels its
request with an allowed purpose. Effect is withheld until a
Protected Enforcement Domain verifies caller identity, requested
operation, and destination against binding records -- not against
caller-supplied metadata -- and issues a scoped, non-bearer Execution
Handle before any release occurs. The document works through a
single running example (a delivery address later targeted by an
unrelated advertising system) to make the failure mode and the
enforcement boundary concrete, and states plainly which part of the
problem this architecture does not solve. It is offered as an
architectural pattern for discussion, not as a proposal for a new
wire protocol.
Cross-referencing data across systems, including in advertising, is a
legitimate and economically necessary function, and this document
does not argue for eliminating it; doing so would stall innovation
and materially harm the businesses that depend on it. What this
architecture offers such systems is a way to make an authorized
combination of data technically verifiable at the moment it happens,
rather than leaving that boundary to rest on a data-sharing agreement
nobody downstream actually checks -- making lawful cross-referencing
demonstrable, not making cross-referencing itself the target.
The same gap appears when four applications sit on a shared raw-data
path. Applications A, B, and C may be known operators: they host to
published standards, maintain written ethics and paper policies, and
implement the technical controls those policies require. This
document does not argue that such operators should be denied raw data
they are authorized to receive. Application D may request that same
raw object. Paper policy and a self-asserted purpose string give no
technical reason to believe that D will confine the object to the
purpose and jurisdiction under which it was collected, rather than
reuse it for an unauthorized purpose -- including surveillance or
intelligence activity directed against the jurisdiction that
originally authorized collection. This architecture does not ask A,
B, or C to stop receiving authorized raw data; it asks that D's
Candidate Act be refused at the Protected Enforcement Domain unless
binding records, not D's own label, establish that D, the requested
operation, and the destination are actually authorized -- so that
faith in D is replaced by a check D cannot write.
Das Expires 16 March 2027 [Page 6]
Internet-Draft Data-Purpose Laundering Prevention September 2026
A further motivation is stated directly here because it shapes
several design choices in this document: the same technical capacity
that lets an advertising system profitably combine location and
behavioral signals across sources is, absent a verifiable purpose
boundary, also capable of exposing patterns -- such as the movement
of military personnel or the operating rhythm of critical
infrastructure -- to a party in a jurisdiction other than the one the
data was collected in. Aggregated commercial location and behavioral
data has, in publicly reported incidents, already been shown capable
of revealing exactly this kind of sensitive pattern. This document
does not ask commercial systems to stop combining data for legitimate
purposes; it asks that a combination authorized for commercial
targeting be technically distinguishable, at the moment of use, from
a combination that has crossed into cross-jurisdictional
intelligence-gathering territory the data was never authorized for.
The architecture does not claim to solve purpose limitation in
general. Section 5.7 and Section 6 state directly what remains
unsolved once data has been legitimately released as plaintext to an
authorized recipient.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
2. Terminology
Candidate Act: A request to read, transmit, transform, or derive
from a protected data object. A Candidate Act has no effect on
its own; it is a proposal for an effect.
Non-Effective State: The state of a Candidate Act prior to
validation. No data release, decryption, or downstream write
occurs while a Candidate Act remains in this state.
Protected Enforcement Domain (PED): The component that evaluates a
Candidate Act against binding records -- caller identity, order/
workflow state, recipient assignment, and policy version -- and
decides whether to advance it out of the Non-Effective State. The
PED does not accept caller-supplied metadata (such as a "purpose"
field) as evidence on its own.
Execution Handle: A short-lived, non-bearer, scoped authorization
Das Expires 16 March 2027 [Page 7]
Internet-Draft Data-Purpose Laundering Prevention September 2026
issued by the PED after a Candidate Act passes validation. An
Execution Handle is bound to a specific data object, operation,
requester identity, and recipient; it is not a general-purpose
credential and is not intended to be transferable.
Finality Sink: The boundary at which a protected data object, or a
value derived from it, is actually released, decrypted, or written
to a destination store. The Finality Sink accepts only a valid,
unexpired, unrevoked Execution Handle.
Ledger-Anchored Validation Receipt (LAVR): An enforcement artifact
-- not an audit log -- generated by the PED at the point a
Candidate Act is validated or rejected. A LAVR records the check
performed, its result, and a hash-chained, domain-signed anchor,
and is generated regardless of outcome.
Algorithmic Logic Fingerprint (ALF): A binding of the specific
operation or computation a Candidate Act requests (e.g., "obtain
delivery destination" versus "infer household income") to the set
of operations the governing policy actually permits on that data
object.
Capability-Validated Inbound Descriptor (CVID): The structured
description of an inbound Candidate Act -- caller, requested
operation, target object, destination -- that the PED evaluates
against binding records before issuing an Execution Handle.
Purpose Laundering: The practice, intentional or not, of obtaining
data or a value derived from it under one declared purpose and
consuming it under a different, unauthorized purpose, where the
receiving system's own request format permits the original purpose
label to travel with the data without being re-verified at the
point of reuse.
3. Problem Statement
3.1. Self-Asserted Purpose Is Not Verifiable Purpose
Most deployed systems that reference "purpose" at all do so as a
string carried in a token claim (e.g., a JWT claim, see [RFC7519]),
an API parameter, or a log field. That string is written by the same
party requesting access. A verification step that only checks
whether the field is present, well-formed, or drawn from an
enumerated list does not verify that the caller's actual operation
matches the label -- it verifies that the caller knows which label to
write.
Das Expires 16 March 2027 [Page 8]
Internet-Draft Data-Purpose Laundering Prevention September 2026
3.2. Attestation Answers a Different Question Than Authorization
Remote attestation (see [RFC9334]) establishes that a piece of code
is running in an expected state on expected hardware. It does not
establish that the workload attested is authorized to perform a
specific operation on a specific data object. A correctly attested
enclave running an unauthorized computation is still an unauthorized
computation; attestation and purpose authorization are orthogonal
checks, and treating a passed attestation as implicit authorization
silently collapses that distinction.
3.3. Derived Data Carries the Restriction, Not Just the Value
A value computed from restricted data (e.g., an income estimate
computed from a home address) is not automatically free of the
restriction that governed the source, even where the derived value
contains none of the original data verbatim. Without deliberate
propagation of source lineage to the derived object, a downstream
consumer of the derived value bypasses every control placed on the
source.
3.4. The Residual Limit: Plaintext Already Released
Once a protected value is legitimately released as plaintext to an
authorized recipient, this architecture -- or any architecture
operating at the request/response boundary -- cannot guarantee that
the recipient will not copy, screenshot, or re-transmit that value
outside the enforced path. Section 5.7 and Section 6 return to this
point; it is stated here because any reader evaluating this document
for what it does NOT do should not have to search for the admission.
4. Architecture Overview
The architecture separates two things that are frequently conflated
in deployed systems: the authority to request an operation, and the
capability to actually perform it. A Candidate Act carries no
capability. It is evaluated by a Protected Enforcement Domain
against records the requester did not write (order state, recipient
assignment, policy version, workload identity). Only on a pass does
the PED issue a scoped Execution Handle, and only a Finality Sink
presented with a valid Execution Handle releases, decrypts, or writes
the underlying value. Every evaluation, pass or fail, produces a
LAVR.
Das Expires 16 March 2027 [Page 9]
Internet-Draft Data-Purpose Laundering Prevention September 2026
Requester --Candidate Act--> [Protected Enforcement Domain]
|
binding-record checks (Section 5.2)
|
pass? --------> Execution Handle
| |
fail --> LAVR Finality Sink
| |
LAVR release
This differs from a conventional access-control gate in one load-
bearing respect: the PED's checks are defined over records external
to the request (what the request _is about_), not over fields
internal to the request (what the request _says about itself_). A
caller cannot pass validation by changing what it writes in its own
request.
5. Worked Example
5.1. Collection: Binding the Data Object to a Permitted Use
A customer provides a delivery address for a specific order. The
address is stored as a protected data object. A separate, integrity-
protected policy record binds that object to a single permitted
workflow, operation, and recipient class, with an explicit
disallowed-operation entry and an expiry:
Data object: address-619
Allowed workflow: delivery-order-842
Allowed operation: obtain delivery destination
Allowed recipient: assigned courier service
Disallowed operation: advertising-profile enrichment
Expiry: configured delivery-access deadline
Policy version: 38
The party that will later compute an advertising profile is never
given the address's decryption key or database credentials. If it
were, every check described below would be enforcement theater --
bypassable at will by the party the checks are meant to constrain.
5.2. A Legitimate Request
The delivery service submits a Candidate Act:
Read address-619, for order-842, send to assigned-courier-6,
operation: obtain delivery destination
Das Expires 16 March 2027 [Page 10]
Internet-Draft Data-Purpose Laundering Prevention September 2026
The PED checks this against binding records, not against the
request's own claims:
+======================================+=======================+
| Check | Evidence checked |
+======================================+=======================+
| Is this really the delivery service? | Authenticated |
| | workload identity |
+--------------------------------------+-----------------------+
| Does this order exist? | Order-management |
| | record |
+--------------------------------------+-----------------------+
| Does this address belong to the | Protected order-to- |
| order? | address association |
+--------------------------------------+-----------------------+
| Is this courier assigned? | Current courier- |
| | assignment record |
+--------------------------------------+-----------------------+
| Is the requested operation | Versioned policy (ALF |
| permitted? | match) |
+--------------------------------------+-----------------------+
| Is access still valid? | Order status, expiry, |
| | revocation state |
+--------------------------------------+-----------------------+
Table 1: PED validation checks for the delivery Candidate Act
A pass issues a short-lived Execution Handle scoped to this exact
address, order, operation, and recipient; the Finality Sink releases
the minimum necessary delivery data on presentation of that handle.
Any check that cannot be completed -- a stale record, an ambiguous
assignment, an expired policy version -- MUST be treated as a failed
check. The PED fails closed by default; it does not proceed on
missing or ambiguous evidence.
5.3. An Unauthorized Request
An advertising workload submits:
Read address-619, operation: infer household income,
destination: advertising-profile-database
Das Expires 16 March 2027 [Page 11]
Internet-Draft Data-Purpose Laundering Prevention September 2026
Every check in Section 5.2 fails: the caller is not the delivery
service, the operation is not the permitted operation, and the
destination is not the permitted recipient. No Execution Handle is
issued, no address is released, and no decryption authority is
granted. The rejection occurs before the income computation begins
-- blocking only the resulting advertisement, after the profiling
computation has already run on the address, would not have prevented
the unauthorized use; it would only have hidden its output.
5.4. A Relabeled Request
The advertising workload resubmits with a relabeled purpose field:
Purpose: delivery, order: order-842
This does not change the outcome. The PED's checks are defined over
the caller's authenticated identity, its destination, and its actual
delivery-workflow authority -- none of which change because the
request's purpose field changed. A caller that presents even a
validly issued delivery Execution Handle from the wrong workload
identity or toward the wrong destination MUST fail validation,
provided identity and destination binding are actually enforced at
the Finality Sink and not only at issuance time. Purpose, in this
architecture, is a conclusion the PED reaches from verifiable
relationships -- not an input the caller supplies.
5.5. A Request From Inside an Attested Enclave
Suppose the income-inference computation runs inside a hardware
Trusted Execution Environment (TEE) that successfully attests its own
integrity. A successful attestation establishes that the enclave is
running the code it claims to run; it does not establish that the
code is authorized to decrypt address-619 for this purpose. The PED
still evaluates workload identity and requested operation against the
same binding records, and an enclave running an income-profiling
workload receives no authority to decrypt a delivery address it was
never granted.
A caveat: if a broadly authorized enclave already holds unrestricted
plaintext access to the address for an unrelated legitimate reason,
an output-only Finality Sink cannot retroactively undo profiling
computation that already occurred inside it. Access and computation
boundaries require enforcement at the point capability is granted,
not only at the point output is written.
Das Expires 16 March 2027 [Page 12]
Internet-Draft Data-Purpose Laundering Prevention September 2026
5.6. A Request for a Derived Value
The advertising system instead attempts to write a value computed
from, but not textually identical to, the address:
customer-17 -> estimated high-income household
The value contains no street address. A Finality Sink that checks
only for the literal restricted value would pass it. A Finality Sink
that checks propagated source lineage does not:
Derived object: income-estimate-52
Restricted source: address-619
Requested use: advertising
The profile-write boundary rejects the write on the lineage binding,
not on pattern-matching the output. This requires deliberate, non-
removable tracking of derived-data provenance; a label attached to
the output that the producing workload can choose to omit provides no
enforcement at all.
5.7. What This Architecture Does Not Close
If an authorized courier receives the plaintext address and copies it
into an unrelated application, the protected data service cannot
guarantee the copy is never reused. Containment beyond this point
requires controlled recipient software, restricted export paths,
minimal disclosure, and downstream enforcement at the recipient's own
boundary -- outside what a source-side PED can observe. Human
observation, screenshots, and compromised endpoints remain outside
this architecture's reach. The claim this document makes is
therefore bounded: within an enforced system boundary, data can be
made unavailable to unauthorized workloads, and unauthorized derived-
value writes can be blocked. Preventing every possible reuse after
legitimate plaintext disclosure is a different, and materially
harder, problem that this document does not claim to solve.
6. Threat Model
In scope:
* A requester relabels or forges the purpose field of a request to
obtain access to data it is not authorized to use for that purpose
(Section 5.4).
* A requester assumes that running inside an attested TEE
substitutes for a purpose-authorization check (Section 5.5).
Das Expires 16 March 2027 [Page 13]
Internet-Draft Data-Purpose Laundering Prevention September 2026
* A requester attempts to obtain a value derived from restricted
data as a way of evading a restriction on the source value
(Section 5.6).
* A requester replays a validly issued Execution Handle from a
different workload identity or toward a different destination than
the one it was scoped to.
* A requester uses a genuine, unexpired Execution Handle after the
binding state it was validated against has changed or been revoked
(Section 16.5).
* A requester copies valid lineage from a permitted object onto a
restricted one (Section 16.12).
* A requester reaches the protected effect through an alternate path
-- a direct database write, administrative interface, queue, or
backup writer -- that does not traverse a Finality Sink
(Section 16.17).
Out of scope / residual risk:
* Reuse of data after legitimate plaintext release to an authorized
recipient (Section 5.7).
* Compromise of the Protected Enforcement Domain itself, or of the
binding records it evaluates against; this architecture assumes
the PED and its record store are not themselves attacker-
controlled.
* Side-channel or covert-channel exfiltration from within an
authorized, attested computation.
* Reconstruction of prohibited information by aggregating many
individually authorized releases across sessions (Section 16.15),
or assembly of a prohibited composite from individually permitted
requests (Section 16.16). Per-act enforcement does not supply the
cumulative policy these require.
* Deployments in which no authority predicate exists that the
requesting workload cannot unilaterally manufacture; these fall
outside the architecture's applicability boundary (Section 16.20).
Das Expires 16 March 2027 [Page 14]
Internet-Draft Data-Purpose Laundering Prevention September 2026
7. Relation to Existing Work
The pattern of checking a request's declared purpose against a policy
before granting access is not new in the access-control literature;
purpose-based access control (PBAC) models and attribute-based access
control frameworks such as XACML define policy evaluation over
request attributes including purpose. This document's distinguishing
element is that the evaluated attributes are drawn from binding
records external to the request (order state, recipient assignment,
workload identity), the resulting grant is a short-lived, non-bearer,
single-scope Execution Handle rather than a general session grant,
and derived-value writes are checked against propagated source
lineage rather than against the presence or absence of a purpose
label on the output.
Decentralized information flow control (DIFC) systems address the
derived-data problem in Section 5.6 by propagating labels through
computation at the operating-system or language-runtime level. This
document does not specify a label-propagation mechanism; it specifies
that a Finality Sink MUST reject a derived-value write that cannot
demonstrate valid source lineage, leaving the propagation mechanism
to the implementing system.
[RFC8707] (Resource Indicators for OAuth 2.0) and audience
restriction in OAuth 2.0 bearer tokens address a related but narrower
problem: binding a token to an intended resource server. This
document's Execution Handle extends that idea to bind a grant to a
specific operation and destination, evaluated per Candidate Act
rather than issued once per session.
8. Relevance to IETF Working Groups
8.1. GNAP
GNAP [RFC9635] already separates the negotiation of a grant from its
use, and supports fine-grained, per-request access rather than a
single broad session token. The Execution Handle described here is
compatible with a GNAP access token scoped to a single resource/
operation pair; this document's contribution to GNAP-adjacent work is
the requirement that the Authorization Server's grant decision be
made against externally-verified binding records rather than against
client-supplied purpose or context claims, and that a derived-
resource request be evaluated against source lineage rather than
treated as a fresh, unrelated grant.
Das Expires 16 March 2027 [Page 15]
Internet-Draft Data-Purpose Laundering Prevention September 2026
8.2. OAUTH
OAuth 2.0 [RFC6749] deployments that rely on a "purpose" or "scope"
string supplied by the client are exposed to exactly the relabeling
attack in Section 5.4. [RFC8707]'s audience restriction is a partial
mitigation already in the OAuth toolkit; this document suggests that
audience restriction alone is insufficient where the threat model
includes a legitimately audience-scoped token presented for an
operation outside its intended purpose, and that purpose SHOULD be a
property the authorization server derives from verifiable request
context rather than a bearer-supplied claim.
8.3. RATS
Section 5.5 is directly a RATS-relevant finding: this document treats
a RATS [RFC9334] Attestation Result as answering "is this code
running as expected" and treats purpose/operation authorization as a
separate, subsequent check that a Relying Party MUST perform
independently. Where RATS-based systems are used to gate access to
sensitive data, this document's caution against conflating
attestation with authorization is offered as an applicability
consideration.
8.4. SPICE
SPICE's work on credential formats and selective disclosure is
relevant to Section 5.1's binding of a data object to a specific
permitted workflow: a credential-based encoding of the "allowed
workflow / allowed operation / allowed recipient" policy record would
let the binding travel with the data object in a verifiable form
rather than living only in a centralized policy store, which may be
of interest to SPICE's scope on interoperable credential structures.
8.5. SECDISPATCH
This document is submitted as an individual architectural pattern
rather than a protocol specification, and the author does not assert
a specific IETF venue for standardization. SECDISPATCH is the
appropriate venue to determine whether, and where, a purpose-binding
and derived-data-lineage mechanism of this kind warrants protocol-
level standardization versus remaining an architectural pattern
referenced by implementers of GNAP, OAuth, and RATS-based systems.
Das Expires 16 March 2027 [Page 16]
Internet-Draft Data-Purpose Laundering Prevention September 2026
8.6. PEARG (IRTF)
The Privacy Enhancements and Assessment Research Group is an IRTF
research group rather than an IETF working group, and is noted here
because Section 3.3 and Section 5.6 (derived-data lineage) and
Section 5.7 (the residual plaintext-reuse limit) are research
questions as much as engineering ones; PEARG's work on privacy threat
modeling and assessment methodology is relevant to evaluating how
completely a lineage-propagation mechanism actually closes the
derived-data gap in practice.
9. Security Considerations
The security of this architecture reduces to the integrity of the
Protected Enforcement Domain and the binding records it evaluates
against. An attacker who can write to the order-management record,
the courier-assignment record, or the policy-version store used in
Section 5.2 can forge a passing evaluation without needing to
compromise the PED's logic itself; those records MUST be integrity-
protected to a standard at least as strong as the PED's own decision
logic. Execution Handles MUST be short-lived, single-scope, and non-
bearer (i.e., bound to and unusable outside the requester identity
and destination they were issued for) to limit the value of a
captured handle. LAVR generation on both pass and fail outcomes is
REQUIRED so that a rejected Candidate Act is not silently dropped in
a way that hides a probing attack pattern.
10. Privacy Considerations
This architecture is itself a privacy control, but it introduces its
own data: the PED's binding records, and the LAVR trail, together
describe who requested what data for what purpose and when. That
record is sensitive in its own right and access to it SHOULD be
governed by the same purpose-binding discipline described in this
document, to avoid recreating the original problem one layer up.
Implementations SHOULD apply data minimization to LAVR contents --
recording that a check passed or failed and against which policy
version, rather than the full content of the Candidate Act, where the
Candidate Act's content is itself sensitive.
11. IANA Considerations
This document has no IANA actions.
12. Acknowledgments
None yet.
Das Expires 16 March 2027 [Page 17]
Internet-Draft Data-Purpose Laundering Prevention September 2026
13. Resources
[DAS-EU-AI-ACT] and [DAS-GLOBAL-PRIVACY] develop the execution-
enforcement model summarized in this document in greater technical
detail, including Candidate Acts, protected validation, scoped non-
bearer authority, Finality Sink enforcement, and privacy and
jurisdictional controls, together with deployment considerations not
repeated here. Readers interested in the protocol mechanics are
encouraged to review those drafts alongside
[DAS-PRIVACY-FINALITY-IMPL], a runnable reference implementation of
the privacy/purpose-enforcement path described in Section 5.
[DAS-PRIVACY-FINALITY-IMPL]'s built-in demo enforces GDPR Article
5(1)(b) purpose limitation and AI Act-style technical enforcement
obligations as one concrete instance of the general mechanism
specified in this document. The demo models a customer support
request scoped to CUSTOMER_SUPPORT (delivery_status,
expected_delivery_date) and denies a resubmission of the same request
under TARGETED_MARKETING before any Finality Sink effect is recorded
-- the same Candidate Act / Protected Enforcement Domain / Finality
Sink pattern this document describes, in regulation-agnostic form, as
the delivery-address / advertising-profiling example in Section 5.
The mapping between the two is direct:
+====================================+=============================+
| Reference implementation | This document |
+====================================+=============================+
| Candidate Act (canonical JSON, | Candidate Act (Section 2) |
| SHA-256 digest) | |
+------------------------------------+-----------------------------+
| Protected Enforcement Domain (PED) | Protected Enforcement |
| | Domain (Section 2) |
+------------------------------------+-----------------------------+
| Signed act-bound Validation Permit | Execution Handle, non- |
| + workload proof-of-possession | bearer, scoped (Section 2) |
+------------------------------------+-----------------------------+
| Finality Sink (independent re- | Finality Sink (Section 2) |
| verification) | |
+------------------------------------+-----------------------------+
| Denied TARGETED_MARKETING | Section 5.4, relabeled / |
| substitution | purpose-substituted request |
+------------------------------------+-----------------------------+
Table 2: Mapping between the reference implementation and this
document
Das Expires 16 March 2027 [Page 18]
Internet-Draft Data-Purpose Laundering Prevention September 2026
GDPR and the EU AI Act are the regulatory framing the reference
implementation was built to demonstrate; the enforcement mechanism
itself, as specified in this document, is regulation-agnostic and
does not depend on any one jurisdiction's law.
[DAS-PRIVACY-FINALITY-IMPL] explicitly disclaims that it decides
whether a purpose is legally legitimate, whether consent is valid, or
whether a controller satisfies any specific data-protection statute;
it enforces machine-readable rules supplied to it, which is the same
scope this document claims for the architecture in Section 4.
13.1. Primary Reference Implementation
A second, purpose-built reference implementation,
[DAS-PURPOSE-FINALITY-IMPL] (the primary reference implementation for
this document), models the exact worked example in Section 5 directly
rather than a GDPR-framed analogue: its baseline Candidate Act is a
delivery-service request for address-619 to obtain a delivery
destination for assigned-courier-6, and its principal negative-
control test is an advertising-service requester submitting the same
object under a permitted-looking declared_purpose ("delivery") while
its authenticated requester, workload, operation, and destination are
all substituted for the advertising path -- exercising Section 5.4
directly rather than by analogy. It additionally implements the
Legitimacy and Authority Verification Record (LAVR) construct as a
hash-chained, HMAC-authenticated decision log, and tests derived-data
lineage propagation (Section 3.3) with both a positive control
(permitted lineage) and two documented negative controls (a lineage-
stripping limitation and a compromised trusted-binding-record
limitation), rather than treating lineage enforcement as
unconditionally solved.
The primary implementation's validation package comprises 88
automated Python tests, 19 deterministic conformance vectors
independently re-executed in Python, Go, and Node.js (57 total cross-
language executions), and 2,000 seeded adversarial mutation trials
(1,000 post-issuance field mutations, 500 purpose-relabel attacks,
and 500 wrong-holder proof-of-possession attempts), all denied as
expected. Measured local software latency (p95, recorded Linux/
x86-64 host) was benchmarked across three topologies:
Das Expires 16 March 2027 [Page 19]
Internet-Draft Data-Purpose Laundering Prevention September 2026
+========================+===========+==============================+
| Topology | p95 | Repository regression target |
+========================+===========+==============================+
| In-process memory | 0.2106 ms | <= 5 ms |
+------------------------+-----------+------------------------------+
| In-process SQLite/WAL | 0.2560 ms | <= 10 ms |
+------------------------+-----------+------------------------------+
| Localhost HTTP | 2.1363 ms | <= 20 ms |
| sidecar | | |
+------------------------+-----------+------------------------------+
Table 3: Primary reference implementation p95 latency by topology
As with [DAS-PRIVACY-FINALITY-IMPL], these are reference-software
engineering regression targets measured on a single local host, not
IETF protocol requirements, and not TEE, HSM, GPU, WAN, or
production-system performance claims; the sidecar figure is localhost
loopback and excludes any real network round-trip. The
implementation's own documented residual risks -- an authorized
recipient copying plaintext after legitimate release, a compromised
PED, a maliciously modified trusted binding record, stripped derived-
data lineage, and covert/side channels -- match the limitations
already stated in Section 3.3 and Section 5.7, and are not resolved
by this or any other implementation in this family.
13.2. Other Reference Implementations
Other reference implementations from the same author, supporting
companion drafts in the same execution-finality portfolio, are
provided here for context and are not relied upon by this document's
normative content: [DAS-HALLUCINATION-IMPL] (preventing AI
hallucination-driven and other unauthorized actions),
[DAS-EGRESS-IMPL] (precision-bounded location release), and
[DAS-6G-IMPL] (execution finality for AI-native 5G/6G and O-RAN).
13.3. Companion Engineering Analysis
"Declared Purpose Is Not Authorization: Capability Laundering and
Execution Finality at the AI Inference Boundary"
([DAS-CAPABILITY-LAUNDERING], DOI 10.5281/zenodo.22719527) is a
companion analysis to this document. It carries the engineering
objections of Section 16 across to AI inference deployments, where
the governed resource is model capability and the enforcement
boundary is the point at which a generated response is released to a
requester. Its central statement -- that generation is not release,
and computation is not authority -- is the inference-layer form of
the distinction this document draws between a Candidate Act and an
effect. It is published under a DOI and is not relied upon by this
Das Expires 16 March 2027 [Page 20]
Internet-Draft Data-Purpose Laundering Prevention September 2026
document's normative content.
14. Latency Characteristics (Non-Normative)
This section reports measured, not projected, latency for the
[DAS-PRIVACY-FINALITY-IMPL] reference implementation's three
sequential stages -- PED validation (Section 5.2's checks), permit
issuance plus workload proof-of-possession (the Execution Handle of
Section 2), and Finality Sink verify-and-commit (the atomic effect
record of Section 4) -- each timed within a single request iteration
so the three figures compose into one end-to-end path, at 500
iterations, on the SME support-agent demo Candidate Act. Two runs are
reported: the implementation's own published figures, and an
independent re-run performed for this document on different hardware,
as a sanity check rather than a replacement measurement.
+=================+==========================+====================+
| Stage | Published median/p95/p99 | Independent re-run |
| | | median/p95/p99 |
+=================+==========================+====================+
| PED validation | 21.5 / 33.1 / 118.9 | 31.2 / 52.4 / 65.9 |
+-----------------+--------------------------+--------------------+
| Permit + PoP | 95.1 / 145.1 / 338.1 | 120.1 / 154.0 / |
| | | 190.5 |
+-----------------+--------------------------+--------------------+
| Sink verify + | 271.4 / 371.9 / 499.7 | 335.4 / 385.9 / |
| commit | | 459.9 |
+-----------------+--------------------------+--------------------+
| End-to-end (sum | ~388.0 | ~486.7 |
| of medians) | | |
+-----------------+--------------------------+--------------------+
Table 4: PED / permit / sink latency, published vs. independent
re-run (microseconds)
Two observations follow directly from the data. First, the Finality
Sink's atomic commit step (SQLite BEGIN IMMEDIATE plus unique-JTI
replay check) dominates the total in both runs -- roughly 60-70% of
end-to-end median latency -- not the cryptographic verification steps
(signature check, proof-of-possession). This is consistent with the
general expectation that the fail-closed, atomic finality boundary of
Section 4 is the more expensive operation to make correct, not the
identity or purpose checks upstream of it. Second, both runs land
the end-to-end path under half a millisecond, which is the basis for
describing this as a hot-path-suitable operation for interactive
request/response flows, subject to Section 15's caveats about the
sink's storage backend.
Das Expires 16 March 2027 [Page 21]
Internet-Draft Data-Purpose Laundering Prevention September 2026
As stated directly in the reference implementation and repeated here:
this is a local Python microbenchmark on a single process, not a
distributed-system or network-inclusive measurement, and it is NOT a
protocol performance claim. It excludes network round-trip time
between requester, PED, and Finality Sink when these run as separate
services; excludes the cost of the binding-record lookups in
Section 5.2's check table (the demo's vaults are in-process, not a
networked identity/order/policy store); and excludes concurrency
effects -- SQLite's single-writer model means throughput, not just
per-request latency, is the binding constraint at production scale
(see Section 15). A deployment claiming this latency profile MUST
re-measure against its own storage backend, network topology, and
binding-record sources before relying on these figures.
15. Feasibility and Legacy System Integration
*Deployment topology.* The PED, the Execution Handle issuer, and the
Finality Sink are logically separable and MAY run as one process, as
a sidecar per protected service, or as independently administered
services (a pattern already anticipated by
[DAS-PRIVACY-FINALITY-IMPL]'s note that vaults/PED/sink state can
move into separate processes, TEEs, HSMs, confidential VMs, or DPUs/
SmartNICs). The architecture is agnostic to which topology an
adopter chooses; Section 14's figures were measured in-process and
should be treated as a floor, not a ceiling, once a real network hop
separates these components.
*Cold path / hot path split.* Companion draft draft-das-execution-
finality-protocol-layer-00 separates policy reasoning (which bindings
apply, which policy version is current) from deterministic
verification (does this specific Candidate Act satisfy those
bindings). The former can be cached, precomputed, or evaluated
asynchronously as records change; the latter is what Section 14
measures and is designed to stay on the interactive request path.
Implementers SHOULD keep policy lookups (the "cold" work) out of the
per-request hot path so that the Finality Sink's atomic commit
remains the dominant, and only, per-request cost.
*Throughput and storage backend.* The reference implementation's
SQLite-backed replay/effect store uses a single-writer commit model;
at the measured ~330-490 us per commit, a single Finality Sink
instance backed by SQLite is bounded to roughly two to three thousand
committed effects per second before write contention dominates. This
is adequate for the SME demo's scale and NOT representative of a
production deployment's requirements; a production Finality Sink
SHOULD replace the single-writer store with a backend that supports
concurrent atomic commit with equivalent replay-prevention guarantees
(e.g., a transactional database cluster or an append-only ledger with
Das Expires 16 March 2027 [Page 22]
Internet-Draft Data-Purpose Laundering Prevention September 2026
unique-nonce enforcement), and MUST preserve the fail-closed, atomic-
consume property of Section 5.2 when doing so -- a faster backend
that weakens atomicity reintroduces the race this architecture exists
to close.
*Legacy system integration without a flag day.* This architecture is
intended to be adopted incrementally, not as a wholesale replacement
of existing access control:
* It SHOULD be deployed as an additional enforcement point
positioned at or behind an existing API gateway, service mesh, or
authorization layer (OAuth, GNAP, internal ABAC), not as a
replacement for those systems. Coarse-grained authentication and
general access control continue to run unchanged; this
architecture adds a finer-grained, purpose-and-lineage-aware check
at the specific data objects and operations an adopter chooses to
protect.
* Adoption SHOULD proceed data-object-class by data-object-class. A
newly protected class (e.g., delivery addresses, as in Section 5)
is bound to policy and enforced from the moment it is onboarded;
classes not yet onboarded continue to be served by whatever legacy
access control already governs them.
* An unmigrated resource MUST NOT be represented, in logs,
dashboards, or documentation, as being under this architecture's
enforcement. A resource with no binding record is not
"permissively allowed" by this architecture -- it is simply
outside its scope, and an adopter that fails to mark that
distinction risks the false sense of security this document argues
against in Section 3.1.
* No retroactive protection is created for data already released
under a legacy regime before onboarding. Section 5.7's residual
limitation applies identically here: onboarding a data class going
forward does not constrain copies already made under the prior
regime.
*Real-time bidding and other latency-constrained environments.* Real-
time bidding (RTB) in programmatic advertising operates within an
auction window commonly on the order of 100 milliseconds end-to-end
across multiple participants (supply-side platform, ad exchange, and
one or more demand-side platforms). This is among the tightest
latency budgets this architecture might be applied to and deserves
direct treatment rather than a general feasibility claim.
Das Expires 16 March 2027 [Page 23]
Internet-Draft Data-Purpose Laundering Prevention September 2026
Cross-referencing data across advertising systems -- combining
signals from multiple sources to select or price an ad -- is a
legitimate, economically load-bearing function of the industry and is
not, by itself, the problem this document addresses. The problem is
unauthorized cross-referencing: a system consuming a signal for a use
it was never granted, the same reuse pattern illustrated with
delivery data in Section 5.3. Removing an advertising system's
ability to combine data in order to make it "safe" would eliminate
the function the system exists to perform and would stall a
significant share of the economic activity the industry depends on;
that is not this document's goal. The goal is to make an authorized
combination technically demonstrable, and an unauthorized one
technically blocked, rather than leaving the boundary between the two
resting entirely on a data-sharing agreement that no downstream
system actually checks -- this architecture is offered as a way to
make lawful cross-referencing verifiable, not as a way to stop cross-
referencing.
Whether this is achievable inside a 100ms RTB budget is a question of
where in the bid path enforcement is placed, not whether enforcement
is possible at all:
* A per-bid Candidate Act evaluated against a live policy store,
with a TEE remote-attestation round-trip inline in the bid path,
is not compatible with a 100ms budget; the attestation handshake
alone commonly consumes a large share of that budget on its own,
independent of anything measured in Section 14.
* Section 14's measurements (sub-millisecond PED validation, permit
issuance, and Finality Sink commit) are achievable in-path only if
the expensive part -- deciding whether a given combination of data
sources is authorized for a given advertiser/publisher/purpose
triple -- is treated as cold-path work, evaluated and cached well
before any individual bid, and refreshed on a policy change rather
than on every auction. What remains in the 100ms hot path is then
the cheap, deterministic step: verifying that this bid's Candidate
Act matches an already-issued, still-valid Execution Handle for
this exact combination -- the sub-millisecond range Section 14
measured, not a fresh policy evaluation or a fresh attestation.
* Under this split, the architecture does not ask an RTB system to
slow its auction down to perform compliance work live; it asks the
system to be able to produce, on demand, a verifiable record that
a specific data combination used in a specific bid was covered by
a specific, current authorization -- which is close to what a
regulator asking for evidence of purpose-limitation compliance is
already asking advertising companies to be able to produce,
typically without machine-checkable evidence to offer today.
Das Expires 16 March 2027 [Page 24]
Internet-Draft Data-Purpose Laundering Prevention September 2026
An implementer that attempts to fit full live policy evaluation and
attestation into the per-bid path will fail the latency budget and
should not attempt to. An implementer that separates authorization
(cold, cacheable, amortized across many bids) from verification (hot,
sub-millisecond, per bid) has a credible path to a compliance record
without materially affecting auction latency -- and a credible,
auditable basis for arguing that its cross-referencing practice is
lawful, rather than merely asserted to be.
*Feasibility summary.* The mechanism itself -- Candidate Act,
binding-record check, scoped Execution Handle, atomic Finality Sink
commit -- is implementable with commodity components (a policy/record
store, an Ed25519 signing service, and a transactional commit
boundary) and does not require new hardware, though Section 5.5 notes
that hardware-rooted attestation strengthens, without being required
by, the workload-identity leg of Section 5.2's checks. The primary
adoption cost is organizational rather than cryptographic:
identifying which binding records (order state, recipient assignment,
workload identity) an adopter's systems already maintain reliably,
versus which must be newly built, since the PED's validity depends
entirely on the trustworthiness of the records it checks against
(Section 9).
16. Engineering Considerations
This section addresses engineering objections that arise when purpose
enforcement depends on external state, derived-data lineage, legacy
infrastructure, heterogeneous external services, or state that can
change between authorization and effectuation. It is presented in
question-and-answer form because each objection is independently
raised and independently answerable; the section is non-normative
except where [RFC2119] keywords appear.
A companion engineering analysis, [DAS-CAPABILITY-LAUNDERING],
applies the same objections to a different protected object: model
capability itself, governed at the response-release boundary rather
than at a data-release or write boundary. That analysis treats a
generated response as a Candidate Act in a Non-Effective State and
the release boundary as a Finality Sink, and states the corresponding
applicability condition -- that an independently maintained
authorization scope must exist -- alongside the limits of per-release
enforcement against cross-session decomposition. Readers concerned
with AI inference deployments rather than with stored data objects
should read that document alongside this section.
The problem this section returns to throughout is:
Das Expires 16 March 2027 [Page 25]
Internet-Draft Data-Purpose Laundering Prevention September 2026
data authorized for Purpose A
|
v
computation / inference / transformation / aggregation
|
v
must not silently become
data authorized for Purpose B
The architecture does not assume that application code, AI agents,
request fields, ordinary databases, intermediate services, or
external APIs behave honestly. The governing principle is that
computation is not authority: a result may be computed, inferred,
transformed, queued, or prepared without thereby gaining authority to
become externally consequential.
16.1. Does the Architecture Merely Move Trust Into an External
Database?
No. The architecture moves authority away from caller-controlled
assertions, but it does not treat every external database entry as
trustworthy.
A weak design would be:
caller says:
purpose = DELIVERY
database says:
purpose = DELIVERY
therefore:
ALLOW
That merely relocates the writable field. The stronger arrangement
is the one described in Section 4: a Candidate Act is evaluated by
the PED against authoritative state, provenance and authenticity,
freshness and version, and requester, object, workflow, and
destination binding, before any scoped execution authority is issued
to a Finality Sink.
The important distinction is:
external state
!=
authoritative state
Das Expires 16 March 2027 [Page 26]
Internet-Draft Data-Purpose Laundering Prevention September 2026
An external record becomes security-relevant only if the enforcement
system can establish properties such as:
AUTHENTIC
CURRENT
NON-ROLLBACK
BOUND TO THE RELEVANT OBJECT
BOUND TO THE RELEVANT WORKFLOW
BOUND TO THE RELEVANT AUTHORITY DOMAIN
NOT UNILATERALLY WRITABLE BY THE REQUESTER
The storage system may carry authoritative evidence. It does not
create authority merely because a value exists in storage.
16.2. What if the Authoritative Binding Authority Itself Is
Compromised?
Then the root of authority is compromised. If a trusted authority or
its signing key produces apparently valid authorization evidence, a
downstream verifier generally cannot distinguish that issuance from
honest issuance merely by checking the same credential.
actual intended rule:
customer-data -> delivery only
compromised authority:
customer-data -> advertising allowed
If the compromised authority generates valid evidence authorizing
advertising, downstream cryptography cannot infer the policy that the
trusted authority should have issued instead. This is a root-of-
trust limitation, and it is the same residual condition recorded in
Appendix A.5.4.
High-assurance deployments MAY reduce that risk using:
Das Expires 16 March 2027 [Page 27]
Internet-Draft Data-Purpose Laundering Prevention September 2026
independent authorities
threshold signatures
quorum approval
dual control
HSM-backed signing
append-only transparency records
cross-checking between domains
policy-authority separation
revocation and key-rotation controls
For example:
Policy Authority --------\
\
Compliance Authority -----> quorum -> authority state
/
Security Authority ------/
The architecture can strongly resist caller forgery, database-row
injection, cache poisoning, record substitution, rollback, stale
authority, transport tampering, and unauthorized replay, while still
acknowledging that compromise of the ultimate authority remains a
residual trust boundary.
16.3. Is This Not Simply Moving the Security Problem Elsewhere?
Every security system has roots of trust. The engineering objective
is not to eliminate trust but to make it explicit, narrow,
authenticated, freshness-bound, machine-verifiable, and not
requester-controlled.
Without such separation:
application requests operation
|
v
application says operation is authorized
|
v
operation executes
Das Expires 16 March 2027 [Page 28]
Internet-Draft Data-Purpose Laundering Prevention September 2026
With execution-finality enforcement:
application requests operation
|
v
independent authority evaluated
|
v
freshness and scope verified
|
v
candidate act bound
|
v
sink verifies authority
|
v
operation becomes effective
The attack surface therefore changes from any component able to
invoke the operation, to components able to compromise the protected
authority chain. That is a meaningful reduction, not an elimination.
16.4. Why Is an Authenticated Binding Record Not Sufficient by Itself?
Authentication answers who issued a piece of state. It does not
answer whether that state is the state actually evaluated, whether it
is still current, whether it applies to this object, workflow, or
destination, or whether it was replaced or revoked after evaluation.
The authorization path should therefore depend on the security-
relevant state actually evaluated:
Das Expires 16 March 2027 [Page 29]
Internet-Draft Data-Purpose Laundering Prevention September 2026
Evaluated Authority State
|
+--> object
+--> workflow
+--> requester
+--> operation
+--> destination
+--> policy epoch
+--> revocation state
+--> freshness
|
v
protected commitment
|
v
Execution Handle / bounded authority
Otherwise this attack becomes possible:
validate against State V1
|
v
authorization generated
|
state changes to V2
|
v
reuse authority created under V1
The enforcement mechanism therefore needs some way to ensure that the
authority used at effectuation still corresponds to the relevant
validated state.
16.5. What if Authoritative State Changes After Validation but Before
Effectuation?
That is a time-of-check/time-of-use (TOCTOU) problem. It is not
addressed by the handle-replay protection described in Section 6: the
handle in question is genuine, unexpired, and used by its intended
holder, and only the underlying binding has changed.
Das Expires 16 March 2027 [Page 30]
Internet-Draft Data-Purpose Laundering Prevention September 2026
10:00:00
Courier A is assigned.
10:00:01
Authorization generated.
10:00:03
Order reassigned to Courier B.
10:00:05
Courier A attempts data release.
Two mitigations exist. Under the first, the issued authority is
deliberately short-lived -- valid for one transaction, or for a
narrowly bounded freshness window -- so that mutable external state
cannot drift far from the validated state. The appropriate lifetime
depends on the mutability and consequence class of the underlying
authority.
Under the second, the Finality Sink revalidates the security-relevant
predicates capable of changing after the original validation:
recipient assignment, revocation state, order state, policy version,
destination state, account state. The architecture can therefore
separate heavier authority evaluation, performed on the control path
by the PED, from small mutable-state checks performed at the Finality
Sink. A deployment MAY use either technique or both.
The invariant is that a previously valid decision MUST NOT become
permanent authority after the state on which it depended has
materially changed.
16.6. Can an Attacker Remove source_lineage and Make Restricted
Ancestry Disappear?
Deleting a lineage field MUST NOT convert restricted ancestry into
unrestricted ancestry.
A system is bypassable if it implements:
if source_lineage exists:
enforce lineage restrictions
else:
assume unrestricted
because the attacker can then perform:
Das Expires 16 March 2027 [Page 31]
Internet-Draft Data-Purpose Laundering Prevention September 2026
restricted derived object
|
remove source_lineage
|
v
apparently unrestricted object
The correct distinction has three states, not two:
verified permitted lineage
verified restricted lineage
required provenance unavailable or unverifiable
The core rule is that missing evidence of restricted ancestry is not
evidence of unrestricted ancestry. For an operation whose policy
requires established provenance:
required provenance
+
cannot establish provenance
|
v
predicate unsatisfied
|
v
no effectuation
This requirement is operation- or policy-driven. It MUST NOT depend
merely on whether a caller happened to supply an optional lineage
field.
16.7. How Does the Finality Sink Know That Provenance Was Required?
This is the distinction between field-driven and operation-driven
lineage enforcement. The sink MUST NOT ask only whether the object
carried a lineage field. The policy determines whether the candidate
operation requires established provenance:
Operation:
write advertising profile
Input class:
customer-derived information
Requirement:
verified provenance
Das Expires 16 March 2027 [Page 32]
Internet-Draft Data-Purpose Laundering Prevention September 2026
Then:
provenance present and valid
->
evaluate provenance
provenance required but unavailable
->
deny / remain non-effective
The requirement therefore exists independently of the metadata field,
and no object outside the operation classes that require provenance
is obliged to carry lineage at all.
Appendix A.5.3 of this document records a negative control that
demonstrates precisely the failure mode of field-driven enforcement:
in the primary reference implementation, stripping the lineage field
from a derived object before it reaches the sink results in
EFFECTUATED. That outcome is the reason the stronger rule is stated
here:
current negative control:
field absent
->
lineage requirement not triggered
->
EFFECTUATED
architectural requirement:
operation requires provenance
+
provenance unavailable
->
NO EFFECTUATION
Until the reference implementation implements the operation-driven
rule, Appendix A.5.3 remains an explicitly disclosed implementation
limitation and is not presented as a solved property of the
architecture.
16.8. What Happens When Governed Data Passes Through an External API?
The external service does not need to understand the finality
protocol. Three deployment patterns are available.
Under the first, protected provenance travels with the object:
Das Expires 16 March 2027 [Page 33]
Internet-Draft Data-Purpose Laundering Prevention September 2026
object
+
protected provenance envelope
The external system MAY ignore that envelope. It MUST NOT be able to
modify the protected binding without detection.
Under the second, external computation produces only a candidate
result:
Protected Authority Domain
|
v
candidate request
|
v
External Compute Service
|
v
candidate result
|
v
Protected Return Boundary
|
v
Finality Sink
The external service is allowed to compute. It does not receive
final authority; the returned result remains non-effective until
local protected validation occurs.
Under the third, a protected connector surrounds a legacy service:
Protected Gateway
|
v
Legacy / External Service
|
v
Protected Gateway
|
v
Finality Sink
The service itself can remain unchanged; the protected boundary
controls whether its inputs or outputs acquire consequential
authority. The key distinction is that external computation is not
external authority.
Das Expires 16 March 2027 [Page 34]
Internet-Draft Data-Purpose Laundering Prevention September 2026
16.9. What if an External API Strips All Provenance Metadata?
Then any design relying solely on that API voluntarily preserving
optional metadata is insecure. Purpose enforcement cannot rest on a
request that a JSON field be left intact.
A protected deployment MUST instead use one or more of:
authenticated in-band provenance
independent protected provenance state
trusted revalidation
trusted reconstruction
protected connector state
fail-closed handling
when required provenance cannot be established
The desired failure mode is:
provenance destroyed
|
v
authority cannot be established
|
v
operation blocked
and not:
provenance destroyed
|
v
restrictions vanish
An attacker may therefore be able to cause an availability failure by
destroying required evidence. That is a different and lesser outcome
than obtaining additional authority; see Section 16.18.
16.10. How Can This Work With a Legacy Database That Cannot Be
Modified?
The ordinary database does not have to carry governance state. A
deployment MAY maintain security-relevant state separately:
Das Expires 16 March 2027 [Page 35]
Internet-Draft Data-Purpose Laundering Prevention September 2026
Legacy Database
--------------------------------
object-719:
value = "high income"
Governance State
--------------------------------
object-719
version = 17
purpose_scope = fraud-only
source = customer-profile-22
policy_epoch = 93
Physical separation is not what creates trust. The governance store
is not trustworthy merely because it is a second database. Its
security value comes from authenticated writes, restricted write
authority, cryptographic integrity, version and freshness
enforcement, protected signing keys, rollback protection, and binding
to the governed object.
The correct distinction is therefore:
ordinary application database
!=
protected authority state
and not:
database 1
!=
database 2
therefore database 2 is trusted
At effectuation, the sink verifies object binding, authority state,
current version, and requested purpose before allowing or denying.
The central requirement is that application code cannot obtain
greater authority merely by editing the ordinary database.
16.11. What if the Database Object Changes but Its Governance State
Does Not?
That is an object-binding failure. Authority should not be attached
merely to a reusable logical name such as record-728, because the
contents behind that name may change.
A stronger authority binding can incorporate object identifier,
object version, content digest, source or provenance state, and
policy epoch:
Das Expires 16 March 2027 [Page 36]
Internet-Draft Data-Purpose Laundering Prevention September 2026
ObjectBinding =
H(
object_id,
version,
content_digest,
governance_state
)
Then:
database value changes
+
old authority remains
|
v
binding mismatch
The old authority cannot silently authorize the new object.
16.12. What Prevents Copying Valid Lineage From One Object to Another?
That is lineage substitution:
Object A
permitted ancestry
|
copy provenance
|
v
Object B
restricted ancestry
A lineage assertion MUST therefore be bound to the object or
transformation result it describes. Binding elements may include
object digest, object identifier, object version, parent digest,
generation identifier, transformation identifier, producer identity,
and policy epoch.
The security condition is not that valid lineage exists, but that
valid lineage exists for this object.
16.13. What Prevents Transformation From Washing Away the Restriction?
Transformation is not declassification. This restates Section 3.3 in
the terms reviewers most often raise it.
The unsafe assumption would be:
Das Expires 16 March 2027 [Page 37]
Internet-Draft Data-Purpose Laundering Prevention September 2026
customer address
|
v
income estimate
|
v
"no longer address data"
|
v
unrestricted
or:
personal data
|
v
embedding
|
v
"not personal anymore"
A derived artifact may still encode, summarize, infer, classify,
compress, or otherwise depend on governed source data. The
architecture therefore treats transformation as a new governed event:
Source A
purpose = DELIVERY
|
v
Transformation F
|
v
Derived B
The fact that B differs from A does not establish that the authority
of B exceeds the authority of A. A transformation can broaden
authority only if an authorized policy transition permits that
result, and that transition MUST itself be established rather than
inferred from the fact that the representation changed.
Das Expires 16 March 2027 [Page 38]
Internet-Draft Data-Purpose Laundering Prevention September 2026
16.14. What if Several Datasets Are Combined and Only Some Are
Restricted?
There is no universal rule that can safely be reduced to simple set
intersection. The resulting authority should be derived through a
protected composition policy that evaluates the contributing source
restrictions, the transformation type, the resulting sensitivity, the
purpose, recipient, destination, and jurisdiction, and where
applicable join risk, aggregation depth, exposure history, and output
class.
A conservative deployment may sometimes use:
result_scope =
intersection(source_scopes)
but that is only one possible policy rule and is not generally
sufficient. Consider:
Dataset A:
analytics allowed
Dataset B:
analytics allowed
A + B:
reveals identity or sensitive behavior
The combined result may require stricter authority than either parent
dataset individually. Derived authority is therefore determined by
protected policy over both the contributing inputs and the
transformation itself, and the resulting authority can be narrower
than the authority of every individual source. The application does
not get to choose which contributing restrictions to remember.
16.15. Does Execution Finality Solve Cross-Session or Mosaic
Aggregation?
Not by itself, and this is stated explicitly rather than left for a
reader to discover.
Das Expires 16 March 2027 [Page 39]
Internet-Draft Data-Purpose Laundering Prevention September 2026
session 1 -> permitted small result
session 2 -> permitted small result
session 3 -> permitted small result
...
session 10,000 -> sensitive profile reconstructed
Each individual release may satisfy its local authorization
conditions. The prohibited result appears only after aggregation
across time. That is the mosaic problem, and per-act execution
finality does not automatically determine whether many individually
allowed outputs collectively reveal prohibited information.
A deployment may introduce additional predicates:
cumulative disclosure budget
recipient exposure state
cross-session counters
query similarity state
join-risk state
aggregation depth
privacy budget
mosaic-risk state
but those are additional stateful controls, and the necessary state
is not created by this architecture. The limitation is that per-act
finality does not itself prove that a sequence of individually
authorized releases cannot collectively reconstruct prohibited
information. Execution finality can enforce a cumulative policy once
one exists; it does not discover the correct cumulative policy.
16.16. What if a Prohibited Operation Is Split Into Many Harmless Ones?
This is related to mosaic aggregation but distinct from it. In the
mosaic case the prohibited result is inferred statistically; here it
is assembled directly. Suppose the prohibited consequence is the
export of a complete customer profile. The attacker may instead
request:
Das Expires 16 March 2027 [Page 40]
Internet-Draft Data-Purpose Laundering Prevention September 2026
request 1 -> name
request 2 -> postcode
request 3 -> salary estimate
request 4 -> behavior class
request 5 -> account risk
request 6 -> purchase history
Each request may be acceptable individually, and none carries a
purpose label that is false. Preventing the composite result
requires cumulative state:
recipient exposure state
+
data-class budget
+
time window
+
purpose
+
join-risk rule
|
v
release decision
Execution finality provides the enforcement point. It does not
invent the policy determining which sequence becomes prohibited. The
separation is:
policy:
"What cumulative behavior is disallowed?"
finality architecture:
"Can that disallowed behavior become effective?"
These are separate engineering problems and this document addresses
only the second.
16.17. What if Another Path Bypasses the Finality Sink?
Then that alternate path is itself an effectuation boundary.
Security cannot depend on protecting one approved write function
while leaving others capable of creating the same protected
consequence:
Das Expires 16 March 2027 [Page 41]
Internet-Draft Data-Purpose Laundering Prevention September 2026
raw_sql_write()
debug_write()
admin_api()
backup_writer()
message_queue()
direct_storage_path()
The invariant is that every path capable of producing the protected
effect MUST encounter equivalent finality enforcement. Conceptually,
an estate in which several paths reach the effect independently:
API A -------\
API B --------\
SQL -----------> protected effect
queue ---------/
admin --------/
MUST become one in which they converge on a common boundary:
API A -------\
API B --------\
SQL -----------> Finality Boundary ---> protected effect
queue ---------/
admin --------/
or one in which each path independently enforces equivalent
authority. An unprotected alternate effect path is a bypass, and an
adopter that protects only the documented path has not deployed this
architecture.
16.18. Does Fail-Closed Provenance Checking Create Denial-of-Service
Risk?
Yes. Security and availability are different properties. If required
provenance is unavailable and the system denies, an attacker who can
destroy or block that evidence may be able to prevent a legitimate
operation. But the alternative -- allowing on unverifiable state --
turns destruction of evidence into privilege escalation.
The safer property is:
Das Expires 16 March 2027 [Page 42]
Internet-Draft Data-Purpose Laundering Prevention September 2026
uncertainty
->
availability loss
rather than:
uncertainty
->
authority expansion
Availability can be improved through replicated authority services,
locally verifiable signed evidence, bounded-validity caches,
protected local state, quorum replicas, recomputation from trusted
sources, checkpointed state, and explicitly authorized constrained
fallback. None of those SHOULD silently convert unverifiable
security state into unrestricted authority.
16.18.1. Latency and Benchmark Scope
These availability mechanisms MUST NOT be confused with the published
reference benchmark. The figures in Section 14 and Appendix A.10
measure the deterministic local verification path under the recorded
reference conditions of Appendix A.1. They do not include:
WAN authority queries
remote revocation lookups
quorum formation
external signature services
distributed consensus
remote provenance reconstruction
production HSM latency
production TEE transitions
Evidence acquisition and distributed authority latency are
deployment-dependent. They may occur on a control path, during
admission, during authority refresh, using bounded-validity cached
evidence, or selectively at finality, according to the required
assurance level. The local verification measurements MUST NOT be
interpreted as an end-to-end service level for distributed authority
acquisition.
Das Expires 16 March 2027 [Page 43]
Internet-Draft Data-Purpose Laundering Prevention September 2026
16.19. Can the Requester Be the Authoritative Source of Purpose?
Not if the architecture is intended to resist purpose laundering by
that requester. If the same requester can assert a request for
advertising use and also generate the evidence stating that
advertising use is authorized, there is no independent authority
boundary.
The architecture therefore requires an authority source the requester
cannot unilaterally manufacture or rewrite. Depending on deployment,
that may be an enterprise policy authority, an order-management
authority, a consent authority, customer authorization state, a
workflow controller, device-protected state, a regulated policy
service, an HSM-backed registry, or a multi-party approval authority.
The precise source varies; the invariant does not:
requester assertion
!=
authorization evidence
16.20. Does the Architecture Apply to Every AI Inference Request?
No. The architecture has an applicability boundary, and it is stated
here so that a reader evaluating this document does not have to
derive it.
anonymous caller
|
v
public model
|
v
ordinary text response
If there is no protected data, no consequential controlled effect, no
independent authority, no protected sink, and no governed resource,
then there may be no execution-finality authority to enforce. The
architecture becomes relevant when a consequence depends on protected
state -- personal-data release, enterprise record mutation, payment,
account modification, AI tool invocation, external communication,
regulated export, medical workflow, critical-infrastructure action,
database commit, or model-memory mutation.
Das Expires 16 March 2027 [Page 44]
Internet-Draft Data-Purpose Laundering Prevention September 2026
The applicability requirement can therefore be stated as follows:
execution-finality enforcement requires a consequence-bearing
boundary and at least one authority predicate that the requesting
workload cannot unilaterally manufacture or rewrite. Without an
independent authority source, this architecture does not claim to
manufacture authority from nothing.
16.21. Is Purpose Not Semantic and Therefore Unenforceable
Cryptographically?
Cryptography cannot determine human intention in the abstract, and
that is not the claim. The architecture enforces the result of a
machine-verifiable authorization decision. An external policy or
authority may determine that a customer address is permitted for
delivery. That can be represented technically as:
purpose_class = DELIVERY
recipient_class = assigned-courier
destination_class = delivery-interface
valid_until = order-completion
output_class = minimum-needed-address
The protected architecture then enforces those predicates. It does
not prove what a human intended; it determines whether this candidate
consequence matches the authorized machine-verifiable scope. The
transition from delivery-authorized data to an advertising-profile
write can be blocked unless a separate authorized transition
establishes advertising authority.
The architecture therefore addresses technical enforcement of purpose
boundaries, not automatic discovery of the legally correct purpose.
16.22. Summary of Engineering Invariants
The data-purpose-laundering defense described in this document
reduces to the following distinctions:
Das Expires 16 March 2027 [Page 45]
Internet-Draft Data-Purpose Laundering Prevention September 2026
Caller assertion
!= authority
Database presence
!= authority
External storage
!= trusted storage
Authentication
!= current authorization
Valid signature
!= fresh state
Prior ALLOW
!= permanent authority
Transformation
!= declassification
Aggregation
!= automatically permitted derivation
Missing lineage
!= clean lineage
Valid lineage
!= lineage for this object
Same object identifier
!= same object version
Attestation
!= purpose authorization
Successful computation
!= permission to effectuate
Possession of an execution handle
!= reusable bearer authority
Unverifiable required state
!= ALLOW
At the consequential boundary:
Das Expires 16 March 2027 [Page 46]
Internet-Draft Data-Purpose Laundering Prevention September 2026
Candidate Act
|
v
ESTABLISH REQUIRED AUTHORITY
|
v
ESTABLISH REQUIRED PROVENANCE
|
v
VERIFY CURRENT STATE
|
v
VERIFY OBJECT / VERSION / WORKFLOW
|
v
VERIFY PURPOSE / DESTINATION / REQUESTER
|
v
BIND AUTHORITY TO THIS ACT
|
v
BIND AUTHORITY TO THIS FINALITY SINK
|
v
RECHECK OR CONSUME FRESHNESS STATE
|
v
EFFECTUATE
If a required predicate cannot be established, the Candidate Act
remains non-effective. The architecture does not attempt to prevent
computation itself; it controls the transition from computed to
consequence-bearing, and requires that this transition occur only
after the authority relevant to the exact act, object, destination,
provenance state, and Finality Sink has been established.
17. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
18. Informative References
Das Expires 16 March 2027 [Page 47]
Internet-Draft Data-Purpose Laundering Prevention September 2026
[DAS-6G-IMPL]
Das, S., "Execution-Finality for AI-Native 5G/6G and O-RAN
-- Runnable Reference Implementation", GitHub repository,
<https://github.com/sangmdas/Execution-Finality-for-AI-
Native-5G-6G-and-O-RAN---Runnable-Reference-
Implementation>.
[DAS-AGENTIC-ZEROTRUST-REFERENCE-IMPLEMENTATION]
Das, S., "Execution Finality for AI Agents, GPUs,
Confidential Computing, and Zero-Trust Automation", GitHub
repository, <https://github.com/sangmdas/Execution-
Finality-for-AI-Agents-GPUs-Confidential-Computing-and-
Zero-Trust-Automation>.
[DAS-AI-GOV-REFERENCE-IMPLEMENTATION]
Das, S., "Execution-Finality Technical Enforcement for EU
AI Act and AI Governance Constraints -- Runnable Reference
Implementation", GitHub repository,
<https://github.com/sangmdas/Execution-Finality-Technical-
Enforcement-for-EU-AI-Act-and-AI-Governance-Constraints>.
[DAS-CAPABILITY-LAUNDERING]
Das, S., "Declared Purpose Is Not Authorization:
Capability Laundering and Execution Finality at the AI
Inference Boundary -- Hired for one purpose, used for
another: what a disclosed weapons-development misuse case
reveals about purpose enforcement at the model response
boundary", Zenodo, publication, CC BY 4.0,
DOI 10.5281/zenodo.22719527, 12 September 2026,
<https://zenodo.org/records/22719527>.
[DAS-DIGITAL-SOVEREIGNTY-REFERENCE-IMPLEMENTATION]
Das, S., "Digital Sovereignty Without Data Localisation:
Compute-Plane / Authority-Plane Execution Finality",
GitHub repository, <https://github.com/sangmdas/Digital-
Sovereignty-Without-Data-Localisation-Compute-Plane-
Authority-Plane-Execution-Finality>.
[DAS-EGRESS-IMPL]
Das, S., "Access Is Not Egress: Precision-Bounded Location
Release -- Reference Implementation", GitHub repository,
<https://github.com/sangmdas/Access-Is-Not-Egress-
Precision-Bounded-Location-Release-Reference-
Implementation>.
Das Expires 16 March 2027 [Page 48]
Internet-Draft Data-Purpose Laundering Prevention September 2026
[DAS-EU-AI-ACT]
Das, S., "Technical Execution Enforcement for the EU AI
Act", Work in Progress, <https://datatracker.ietf.org/doc/
draft-das-eu-ai-act-execution-enforcement/>.
[DAS-FUTURIUM-DIGITAL-SOVEREIGNTY-ARTICLE]
Das, S., "Protecting Europe: A Technical Foundation for
Digital Sovereignty, Data Protection, and AI Governance",
EU AI Alliance Futurium,
<https://futurium.ec.europa.eu/en/apply-ai-alliance/
community-content/protecting-europe-technical-foundation-
digital-sovereignty-data-protection-and-ai-governance>.
[DAS-GLOBAL-PRIVACY]
Das, S., "Global Privacy Execution Enforcement", Work in
Progress, <https://datatracker.ietf.org/doc/draft-das-
global-privacy-execution-enforcement/>.
[DAS-GPU-CONFIDENTIAL-REFERENCE-IMPLEMENTATION]
Das, S., "Execution Finality for GPU AI Accelerators and
Confidential Workloads", GitHub repository,
<https://github.com/sangmdas/Execution-Finality-for-GPU-
AI-Accelerators-and-Confidential-Workloads>.
[DAS-HALLUCINATION-IMPL]
Das, S., "Preventing AI Hallucinations and Unauthorized
Actions -- Runnable Reference Implementation", GitHub
repository, <https://github.com/sangmdas/Preventing-AI-
Hallucinations-and-Unauthorized-Actions-Runnable-
Reference-Implementation>.
[DAS-HARDWARE-FINALITY-REFERENCE-IMPLEMENTATION]
Das, S., "Hardware Execution Finality for AI and
Autonomous Systems", GitHub repository,
<https://github.com/sangmdas/Hardware-Execution-Finality-
for-AI-and-Autonomous-Systems>.
[DAS-PRECISION-EGRESS]
Das, S., "Precision-Bounded Egress", Work in Progress,
<https://datatracker.ietf.org/doc/draft-das-precision-
bounded-egress/>.
[DAS-PRIVACY-FINALITY-IMPL]
Das, S., "Privacy Finality Reference Implementation",
GitHub repository,
<https://github.com/sangmdas/privacy-finality-reference>.
Das Expires 16 March 2027 [Page 49]
Internet-Draft Data-Purpose Laundering Prevention September 2026
[DAS-PURPOSE-FINALITY-IMPL]
Das, S., "Purpose-Execution-Finality Validator: Preventing
Data-Purpose Laundering in AI Systems -- Runnable
Reference Implementation", GitHub repository,
<https://github.com/sangmdas/Purpose-Execution-Finality-
Validator-to-Prevent-Data-Purpose-Laundering-in-AI-
Systems>.
[DAS-RATS-MODEL-RELEASE-REFERENCE-IMPLEMENTATION]
Das, S., "Execution Finality (RATS) for AI Model Release",
GitHub repository, <https://github.com/sangmdas/execution-
finality-rats-ai-model-release>.
[DAS-REFERENCE-IMPLEMENTATION-V010]
Das, S., "Privacy Finality Reference Implementation,
Release v0.1.0", GitHub repository,
<https://github.com/sangmdas/privacy-finality-
reference/releases/tag/v0.1.0>.
[DAS-SECURITY-CROSS-DOMAIN-REFERENCE-IMPLEMENTATION]
Das, S., "Execution-Finality Security for Agentic AI,
Autonomous Systems, Cloud, Payments, Telecom, OS, and
Robotics", GitHub repository,
<https://github.com/sangmdas/Execution-Finality-Security-
for-Agentic-AI-Autonomous-Systems-Cloud-Payments-Telecom-
OS-and-Robotics>.
[DAS-TOOL-BINDING-REFERENCE-IMPLEMENTATION]
Das, S., "tool_use Is Not invoke(): Binding Execution-
Finality to Agentic Tool-Call Interfaces and MCP", GitHub
repository, <https://github.com/sangmdas/tool_use-Is-Not-
invoke-Binding-Execution-Finality-to-Agentic-Tool-Call-
Interfaces-and-MCP>.
[FUTURIUM-PAPER-COMPLIANCE]
Das, S., "From Paper Compliance to Technical Enforcement:
Making GDPR and the EU AI Act Executable in the AI Era",
EU AI Alliance Futurium,
<https://futurium.ec.europa.eu/en/apply-ai-alliance/posts/
paper-compliance-technical-enforcement-making-gdpr-and-eu-
ai-act-executable-ai-era>.
Das Expires 16 March 2027 [Page 50]
Internet-Draft Data-Purpose Laundering Prevention September 2026
[FUTURIUM-PURPOSE-LAUNDERING]
Das, S., "Preventing Data-Purpose Laundering by Agentic
AI: A Hardware-Rooted Pre-Effectuation Layer for GDPR
Purpose Limitation and High-Risk AI Governance", EU AI
Alliance Futurium, <https://futurium.ec.europa.eu/en/
apply-ai-alliance/community-content/preventing-data-
purpose-laundering-agentic-ai-hardware-rooted-pre-
effectuation-layer-gdpr-purpose>.
[RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",
RFC 6749, DOI 10.17487/RFC6749, October 2012,
<https://www.rfc-editor.org/info/rfc6749>.
[RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
(JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
<https://www.rfc-editor.org/info/rfc7519>.
[RFC8707] Campbell, B. and A. Bansal, "Resource Indicators for OAuth
2.0", RFC 8707, DOI 10.17487/RFC8707, February 2020,
<https://www.rfc-editor.org/info/rfc8707>.
[RFC9334] Birkholz, H., Thaler, D., Richardson, M., Smith, N., and
W. Pan, "Remote ATtestation procedureS (RATS)
Architecture", RFC 9334, DOI 10.17487/RFC9334, January
2023, <https://www.rfc-editor.org/info/rfc9334>.
[RFC9635] Richer, J. and F. Imbault, "Grant Negotiation and
Authorization Protocol (GNAP)", RFC 9635,
DOI 10.17487/RFC9635, October 2024,
<https://www.rfc-editor.org/info/rfc9635>.
Appendix A. Primary Reference Implementation -- Detailed Validation
Methodology
This appendix records the detailed validation methodology for the
primary reference implementation ([DAS-PURPOSE-FINALITY-IMPL],
Section 13.1), at a level of granularity beyond the summary given in
Section 13.1. It is provided so that the specific test conditions,
decision ordering, and negative controls behind the summary figures
are independently inspectable. As throughout this document, these
are reference-software engineering results, not protocol
requirements.
Das Expires 16 March 2027 [Page 51]
Internet-Draft Data-Purpose Laundering Prevention September 2026
A.1. Recorded Test Environment
The validation was executed once, on the following recorded
environment; the repository does not claim these figures on Windows,
macOS, ARM64, HSMs, TEEs, GPUs, DPUs, SmartNICs, confidential VMs,
Kubernetes, WAN networks, or production advertising systems:
+=================+===================================+
| Parameter | Recorded value |
+=================+===================================+
| Validation date | 9 September 2026 |
+-----------------+-----------------------------------+
| OS / kernel | Linux 6.18.35, x86-64, glibc 2.41 |
+-----------------+-----------------------------------+
| CPU | Intel Xeon Platinum 8370C @ 2.80 |
| | GHz (5 logical CPUs visible) |
+-----------------+-----------------------------------+
| Python | 3.13.5 (GCC 14.2.0 build) |
+-----------------+-----------------------------------+
| SQLite / | 3.46.1 / 3.5.5 |
| OpenSSL | |
+-----------------+-----------------------------------+
| Go / Node.js | 1.23.2 linux/amd64 / 22.16.0 |
+-----------------+-----------------------------------+
| Benchmark timer | time.perf_counter_ns() |
+-----------------+-----------------------------------+
Table 5: Recorded test environment
A.2. Baseline Candidate Act, Binding Record, and Validation Context
A deterministic baseline was used so every mutation could be compared
against a known-valid act. The Candidate Act (act-001, policy
version 38, 10-second validity window) requests obtain delivery
destination on object address-619 for workflow delivery-order-842,
from requester/workload delivery-service / delivery-workload, to
destination assigned-courier-6, carrying declared_purpose: delivery.
The matching external binding record independently authorizes the
same object/workflow/requester/workload/operation/destination/policy-
version tuple and is valid for 60 seconds. The declared_purpose
field is deliberately treated as untrusted requester-supplied
metadata, never as authorization evidence -- the central test in
Appendix A.5.1 is whether relabeling it can rescue an unauthorized
request; it cannot. The baseline validation context (authenticated
requester/workload, order existence, object association, recipient
assignment, binding store availability and integrity, attestation
result, timeout flag) is independently varied in the negative tests
below.
Das Expires 16 March 2027 [Page 52]
Internet-Draft Data-Purpose Laundering Prevention September 2026
A.3. PED Decision Sequence
The PED applies a deterministic, fail-closed evaluation order; any
earlier failure short-circuits to DENY with an associated failure
LAVR, and later checks are not reached:
1. Validation timeout?
2. Binding store available?
3. Binding store integrity acceptable?
4. Binding record exists?
5. Candidate Act still fresh?
6. Binding record still fresh?
7. Binding revoked?
8. Policy version correct?
9. Requester identity correct?
10. Workload identity correct?
11. Protected object correct?
12. Workflow correct?
13. Operation permitted?
14. Destination permitted?
15. Workflow/order exists?
16. Object belongs to workflow?
17. Recipient assignment current?
18. Required attestation valid?
Only after all eighteen checks succeed is the result ALLOW. A key
architectural test verifies that attestation_ok = true does not
override an OPERATION_MISMATCH, REQUESTER_MISMATCH,
DESTINATION_MISMATCH, or WORKLOAD_MISMATCH -- i.e., attested is not
authorized.
A.4. Execution Handle Lifetime Clamping
With max_handle_ms = 2000, handle expiration is min(Candidate Act
expiration, issuance time + 2000 ms). Boundary tests at candidate
lifetimes of 0, 1, 10, 100, 1000, and 1999 ms from PED issuance time
all produced a clamped handle; 2000 ms produced the maximum unclamped
handle -- verifying the PED cannot issue a handle exceeding either
its own configured maximum or the Candidate Act's own expiration.
The handle itself binds handle_id, the Candidate Act digest, object,
workflow, operation, requester, workload, destination, policy
version, nonce, issuance/expiry times, and the proof-of-possession
key ID -- i.e., authorization for this exact act under this exact
binding state, not general access.
Das Expires 16 March 2027 [Page 53]
Internet-Draft Data-Purpose Laundering Prevention September 2026
A.5. Mutation and Threat-Model Testing
Canonical JSON serialization (sorted keys, no incidental whitespace,
UTF-8, deterministic separators) is SHA-256 hashed to produce the
Candidate Act digest, so any load-bearing field change alters the
digest. Two independent mutation surfaces were tested:
* *Post-issuance mutation* (handle already issued): each of object,
workflow, operation, destination, requester, workload, declared
purpose, nonce, and policy version was individually mutated after
issuance; every case produced ACT_DIGEST_MISMATCH, since the
previously issued handle no longer matches the altered act's
digest.
* *PED-side mutation* (before issuance): the same fields were
mutated before the PED evaluated the act; each independently
produced its corresponding *_MISMATCH denial (e.g., requester,
workload, object, workflow, operation, or destination mismatch).
A.5.1. Purpose-Relabel Attack
The principal threat-model test: an advertising requester/workload
submits an act for operation infer household income against
destination advertising-profile-database, but writes
declared_purpose: delivery. Result: DENY, because the external
binding record still reflects the delivery
requester/workload/operation/destination tuple -- the purpose-string
relabel does not change those externally-held facts. This was
additionally tested against several plausible-sounding purpose
strings (customer_support, legitimate_interest, consent, security,
fraud_prevention), all denied with OPERATION_MISMATCH, and conversely
the legitimate delivery act was tested with several different
declared-purpose values (including DELIVERY, targeted_marketing, an
empty string, and a 128-character arbitrary string) and remained
allowed in every case, confirming the decision is driven by the
binding relationship, not the spelling of the purpose field in either
direction.
A.5.2. Additional Negative-Control Conditions
Further independently-tested failure conditions and their results:
Das Expires 16 March 2027 [Page 54]
Internet-Draft Data-Purpose Laundering Prevention September 2026
+================================+==================================+
| Condition varied | Result code |
+================================+==================================+
| Attestation required but false | ATTESTATION_FAILURE |
| (with otherwise-valid act) | |
+--------------------------------+----------------------------------+
| Attestation true but operation | OPERATION_MISMATCH (attested is |
| still unauthorized | not authorized) |
+--------------------------------+----------------------------------+
| Binding store unavailable | BINDING_STORE_UNAVAILABLE |
+--------------------------------+----------------------------------+
| Binding store integrity | BINDING_STORE_INTEGRITY_FAILURE |
| uncertain | |
+--------------------------------+----------------------------------+
| Binding record missing | NO_BINDING_RECORD |
+--------------------------------+----------------------------------+
| Candidate Act / binding record | CANDIDATE_EXPIRED / |
| / handle expired | BINDING_EXPIRED / |
| | HANDLE_EXPIRED |
+--------------------------------+----------------------------------+
| Binding revoked | BINDING_REVOKED |
+--------------------------------+----------------------------------+
| Policy version incorrect (0, | POLICY_VERSION_MISMATCH (every |
| 1, 37, 39, 40, 1000 tested) | value) |
+--------------------------------+----------------------------------+
| Workflow missing / object | WORKFLOW_NOT_FOUND / |
| association broken / recipient | OBJECT_ASSOCIATION_MISMATCH / |
| assignment changed | RECIPIENT_ASSIGNMENT_MISMATCH |
+--------------------------------+----------------------------------+
| Validation timeout forced | VALIDATION_TIMEOUT (not |
| | interpreted as permission) |
+--------------------------------+----------------------------------+
Table 6: Additional negative-control test conditions
A.5.3. Derived-Data Lineage
A derived object (income-estimate-52, sourced from address-619)
submitted by the advertising requester for write advertising profile
is deliberately given a binding record that would otherwise allow the
write, so the PED issues a valid Execution Handle; the Finality Sink
independently checks source_lineage against the protected lineage
rule (which permits address-619 only for the delivery operation/
destination) and denies with LINEAGE_RESTRICTION_MISMATCH even though
a valid handle exists -- confirming the sink remains independently
load-bearing rather than trusting a prior PED ALLOW. A positive
control (the same lineage attached to the legitimate delivery act)
returns EFFECTUATED, confirming lineage presence alone is not a
Das Expires 16 March 2027 [Page 55]
Internet-Draft Data-Purpose Laundering Prevention September 2026
denial trigger. A documented negative control -- stripping
source_lineage from the derived object before it reaches the sink --
results in EFFECTUATED, an intentionally disclosed limitation:
lineage must be protected from stripping or independently
reconstructable, or this control is bypassable.
A.5.4. Trusted-Record Compromise
A separate negative control deliberately rewrites the authoritative
binding record itself to authorize the advertising operation; the PED
(correctly, given its inputs) returns ALLOW. This is intentional: it
demonstrates that a correct PED cannot compensate for corrupted
authoritative truth, and that the binding-record system's integrity
must be protected to at least the assurance level of the enforcement
decision itself -- stated as a residual security assumption, not
hidden.
A.6. LAVR Generation, Chaining, and Tamper Detection
Every PED decision (PASS or FAIL) generates a Legitimacy and
Authority Verification Record (LAVR) containing a monotonic sequence
number, the previous LAVR's hash, the Candidate Act digest, the PASS/
FAIL result and reason code, policy version, and timestamp, HMAC-
authenticated as a body. The first LAVR's previous-hash field is 64
zero characters; each subsequent record's prev_hash is the SHA-256 of
the prior LAVR, and the suite verifies sequence continuity, hash-
chain continuity, and HMAC integrity. A deliberately tampered LAVR
signature is correctly detected by chain verification. This is a
local authenticated hash chain, not a public blockchain or
distributed ledger.
A.7. Replay and Concurrency Testing
A valid Execution Handle used once returns EFFECTUATED; the identical
handle reused returns REPLAY_DETECTED. Two replay backends were
tested: an in-memory lock-protected set of consumed handle IDs, and a
persistent SQLite/WAL-backed table keyed on handle_id (primary-key
violation on reuse, transaction rolled back). Concurrency was tested
directly rather than only sequentially: for the memory backend, five
profiles (2/4/8/16/32 worker threads issuing 10/32/64/100/128
concurrent attempts against the same handle) each produced exactly
one EFFECTUATED and (attempts - 1) REPLAY_DETECTED outcomes; for the
SQLite backend, four profiles (2/4/8/16 threads, 8/16/32/64 attempts)
produced the same exactly-one-success invariant. Persistence was
additionally verified across a simulated restart: issue, consume,
close the SQLite connection, reopen, and re-attempt the same handle
-- REPLAY_DETECTED, confirming local persistent replay state (not
distributed multi-node replay consensus, which remains out of scope).
Das Expires 16 March 2027 [Page 56]
Internet-Draft Data-Purpose Laundering Prevention September 2026
A.8. Cross-Language Conformance
Nineteen deterministic conformance vectors (each a Candidate Act,
binding record, validation context, expected decision, and expected
SHA-256 Candidate Act digest) were independently re-implemented and
executed in Python 3.13.5, Go 1.23.2, and Node.js 22.16.0, covering:
baseline valid request; wrong
requester/workload/object/workflow/operation/destination; changed-
but-untrusted purpose only (still ALLOW); wrong policy version;
revoked, expired, or missing binding; missing workflow; broken object
association; changed recipient assignment; unavailable or integrity-
failed binding store; attestation failure; and forced timeout. Each
language independently canonicalizes, digests, and decides; results
were 19/19 in all three languages (57 total executions of the 19
shared vectors -- not 57 distinct threats). This demonstrates that
canonicalization, digest semantics, binding-record checks, decision
ordering, and reason-code behavior can be implemented consistently
across languages; it does not establish that the Go and Node
conformance programs are complete production equivalents of the full
Python reference (LAVR lifecycle, replay store, and PoP lifecycle
remain primarily implemented in Python).
A.9. Deterministic Adversarial Stress Testing
A seeded (20260909), reproducible stress test outside the pytest
suite ran 2,000 total trials in three groups: 1,000 post-issuance
field mutations (a random load-bearing field replaced with a random
value after handle issuance), 500 purpose-relabel attacks
(advertising requester/workload/operation/ destination with a random
0-40-character purpose label), and 500 wrong-holder proof-of-
possession attempts (proof generated with the non-bound holder key).
All 2,000 trials were denied. This volume is reported separately
from, not summed with, the 88 pytest cases and 57 cross-language
executions, since the categories overlap conceptually and a combined
"2,145 tests" figure would overstate distinct coverage.
A.10. Latency by Topology, with Repeated Runs
Three local software topologies were benchmarked, each with a fresh
Candidate Act per iteration (avoiding replay-state contamination
across iterations) and a distinct engineering regression target:
Das Expires 16 March 2027 [Page 57]
Internet-Draft Data-Purpose Laundering Prevention September 2026
+============+===========+======+======+======+======+=======+======+
| Topology | Warm-up |p50 |p95 |p99 |mean |max |Target|
| | / | | | | | | |
| | measured | | | | | | |
+============+===========+======+======+======+======+=======+======+
| In-process | 300 / |0.1678|0.2106|0.2618|0.1796|3.0804 |<= 5 |
| memory | 3,000 |ms |ms |ms |ms |ms |ms |
+------------+-----------+------+------+------+------+-------+------+
| In-process | 200 / |0.1987|0.2560|0.3841|0.2147|2.7283 |<= 10 |
| SQLite/WAL | 2,000 |ms |ms |ms |ms |ms |ms |
+------------+-----------+------+------+------+------+-------+------+
| Localhost | 100 / |1.4670|2.1363|3.7796|1.5826|10.5086|<= 20 |
| HTTP | 1,000 |ms |ms |ms |ms |ms |ms |
| sidecar | | | | | | | |
+------------+-----------+------+------+------+------+-------+------+
Table 7: Primary latency run by topology
Each topology's p95 was additionally repeated three further times to
avoid accepting a single favorable run: memory 0.2154-0.2424 ms,
SQLite 0.2605-0.4145 ms, HTTP sidecar 2.0291-2.3466 ms across the
three repeats, every repeat remaining under its target. One HTTP-
sidecar repeat recorded a maximum latency of 47.9501 ms (retained,
not discarded as an inconvenient outlier) while its p95 remained
2.2572 ms -- illustrating that an isolated scheduler/runtime pause
can inflate the maximum without moving the percentile figures the
targets are defined against. The HTTP-sidecar figures are localhost
loopback only and exclude any real network round-trip, remote policy
lookup, or remote attestation.
A.11. What the Testing Supports, What It Does Not, and Residual Risks
On the recorded Linux/x86-64 environment, the evidence supports the
bounded claim that the Candidate Act -> external-binding-validation
-> LAVR -> scoped non-bearer handle -> holder proof -> independent
Finality Sink -> atomic single-use effectuation path executed
correctly under the tested threat, mutation, concurrency, storage,
language, and local-topology variations, within the repository's own
p95 regression thresholds. It does not establish that all
implementations of this pattern are secure; that production systems
will see sub-millisecond or WAN-equivalent latency; that TEE/HSM
latency matches this software path; that lineage can never be
stripped; that the authoritative binding database cannot itself be
compromised; that plaintext cannot be copied after legitimate
release; that covert channels are prevented; that the protocol is
formally verified; or that the architecture by itself establishes
legal compliance.
Das Expires 16 March 2027 [Page 58]
Internet-Draft Data-Purpose Laundering Prevention September 2026
+====================================+==========================+
| Residual risk | Status |
+====================================+==========================+
| Authorized recipient copies | Not solved by source- |
| plaintext after legitimate release | side finality alone |
+------------------------------------+--------------------------+
| PED itself compromised | Outside the PED's own |
| | protection |
+------------------------------------+--------------------------+
| Trusted binding record maliciously | Can produce a false PASS |
| modified | (Appendix A.5) |
+------------------------------------+--------------------------+
| Derived lineage stripped before | Sink may lose provenance |
| the sink | |
+------------------------------------+--------------------------+
| Side/covert channel inside | Not solved |
| authorized computation | |
+------------------------------------+--------------------------+
| Human screenshot/observation of | Not solved |
| released data | |
+------------------------------------+--------------------------+
| Software-held test key compromise | Reference-implementation |
| | limitation |
+------------------------------------+--------------------------+
| SQLite single-host replay/effect | Not hyperscale evidence |
| store | |
+------------------------------------+--------------------------+
Table 8: Main residual risks (documented, not hidden)
These match, and do not extend, the limitations already stated for
the architecture generally in Section 3.3 and Section 5.7.
Recommended next-level validation, replacing one software assumption
at a time with a real deployment component, includes: a protected or
cryptographically signed external binding-record store; a non-
exportable holder proof-of-possession key; HSM- or TEE-backed handle
signing; a replicated transactional replay/effect database; real
service-mesh/API-gateway integration; remote-attestation freshness
and revocation integration; protected lineage propagation through a
real computation pipeline; network-partition and stale-replica fault
injection; sustained concurrency/throughput measurement at production
scale; and an independent interoperable implementation built solely
from the published conformance vectors.
Das Expires 16 March 2027 [Page 59]
Internet-Draft Data-Purpose Laundering Prevention September 2026
A.12. Reproduction
The validation package's expected primary results are 88 passed
Python tests; 19/19 conformance vectors in each of Python, Go, and
Node.js; and 1,000/1,000, 500/500, and 500/500 denied outcomes for
the three deterministic stress groups of Appendix A.9, reproducible
via the commands and version pins published alongside
[DAS-PURPOSE-FINALITY-IMPL].
Author's Address
Sangam Kumar Das
Independent Inventor
Balasore
Odisha
India
Email: info@sangamdas.com
Das Expires 16 March 2027 [Page 60]