Baxnet Blog · founder-note
Consent Should Have a Receipt
TL;DR: A useful permission or deletion flow should leave the person with a record they can inspect, revisit, and act on later.
Six months later is when a lot of privacy decisions stop feeling like decisions.
Not at the moment you tap “allow.” Not while you are filling out the deletion form. Later, when you are trying to remember which service got access to what, whether you ever narrowed that permission, whether the deletion request actually went through, or what exactly the product was allowed to keep.
That is why I keep coming back to a simple product standard: consent should leave a receipt.
Not a legal PDF nobody reads. A usable record.
What did I allow? When did I allow it? Which identifiers or accounts were involved? What was the scope? How do I check the status? How do I revoke it, narrow it, or update it when my situation changes?
California’s DELETE REQUEST and Opt-out Platform, or DROP, is interesting for this reason. It does not solve the whole data-broker problem, but it turns a vague right into an operational object. The user gets a DROP ID. They can check status. They can add more identifiers later if a broker could not find them the first time. Beginning on August 1, 2026, brokers have to start processing those requests, report statuses back, and keep suppression logic in place so the request has some memory after the first pass.
That shape matters.
The useful part is not only the deletion right. It is the fact that the action leaves a trail the person can revisit.
You can see the same direction in other data-rights systems. Australia’s Consumer Data Right puts the consumer at the centre of the sharing flow and lets them decide when and how data is shared with accredited parties. The UK’s Data (Use and Access) Act 2025 pushes further toward authorised access to customer data and related contextual data, which is another way of saying that rights are being turned into repeatable workflows rather than static legal entitlements.
Personal AI needs the same maturity.
If a system can read your notes, remember a preference, inspect your documents, or draw on private context to answer a question, the permission should not evaporate the moment you click through the prompt. It should become a small ledger entry the person can inspect later.
Recent agent-privacy research is moving in that direction too. The GAAP paper does not just ask users to trust an agent. It collects permission specifications describing how private data may be shared, then enforces the agent’s disclosures against that specification. That is a more serious product instinct. The permission is not theatre. It becomes part of the system’s behaviour.
This matters because memory fades faster than systems do.
A person may vaguely remember agreeing to share a bank feed, a message archive, a location history, or a private notebook with some tool during a busy week. That is not good enough. If the data is intimate, the person should not have to reconstruct the boundary from memory.
For the kind of product world Baxnet cares about, trust gets stronger when rights and permissions leave evidence behind. A good receipt does not just say “success.” It says what happened, what still applies, and what the person can do next.
That is a quieter idea than grand talk about user empowerment.
It is also more useful.
Further reading: CalPrivacy DROP, How DROP works, Australian Treasury, Consumer Data Right, UK Data (Use and Access) Act 2025 explanatory notes, and An AI Agent Execution Environment to Safeguard User Data.