Privacy Agent
A first-party privacy operator that maps public exposure, prepares and submits authorized removal requests, follows every deadline, and independently checks what actually disappeared.
01 / THE PROBLEM
Deletion is fragmented; recurrence is invisible.
Phone numbers, email addresses, household relationships, and other personal details accumulate across people-search sites and data brokers. Finding each source, learning its rules, submitting one request at a time, and checking again later is fragmented work that most people cannot sustain.
The hard product problem is not finding one result. It is preserving the relationship among discovery, identity confidence, legal authority, submission, source response, independent verification, and recurrence.
02 / THE OUTCOME
One accountable loop on every screen.
One shared web, iOS, and Android product with a 603-source registry catalog, consented public-search discovery, an encrypted identity vault, guarded standing authorization, first-party request execution, protected government handoffs, and privacy-safe reports.
Built for people protecting their own identity—not for data resale or another broker profile.
03 / ARCHITECTURE
Five guarded stages, one shared state model.
Check the public registry and explicitly consented web searches.
Separate a likely match from another person or household member.
Record the exact rights and scope the agent may use.
Inspect the source flow, submit safely, and track acknowledgement.
Recheck independently and report recurrence without overclaiming.
What the system does today
- The current California registry snapshot produces one versioned 603-source client and server catalog.
- Magic-link accounts keep identifiers in an encrypted identity vault; native sessions use Keychain and Android Keystore.
- The server allows browser work only against generated catalog targets and pauses on CAPTCHAs, file uploads, and attestations.
- Authorized email requests are idempotent, auditable, and correlated with source replies.
- Brave Search discovery is separately consented and works without an LLM; users may bring their own encrypted key.
04 / OPERATING BOUNDARIES
Automate routine work. Stop at consequential steps.
The agent may inspect published rights pages and submit a routine request only with current standing authorization. It cannot silently solve a CAPTCHA, upload an identity document, assert residency, sign a penalty-of-perjury statement, resolve an ambiguous household match, or claim a source result is gone without fresh evidence.
California DROP and the FTC Do Not Call Registry open in their official flows. Those boundaries are product behavior, not disclaimer text.
05 / PRODUCTION NOTES
The honest distance between a private preview and a public service.
- The hosted preview must not accept real identity data until the production email domain, D1 database, secrets, and legal contacts are configured.
- California DROP stays an official user handoff until written CPPA clarification confirms the intended authorized-agent automation path.
- FTC Do Not Call registration remains direct consumer action in the official government flow.
- A controlled owner-data pilot, accessibility verification, store declarations, and signed release testing remain launch gates.
06 / LESSONS
Privacy automation needs sharper language than “done.”
- A removal product needs an evidence vocabulary: observed, submitted, source-reported, and independently verified are different states.
- Standing authorization can automate routine work without turning identity documents or legal attestations into invisible background actions.
- A public registry is a source map, not proof that a company holds one person’s information.
- Most of the workflow is deterministic; model tokens are an optional fallback, not the product foundation.