Find and export personal data
For: tenant admins and governance reviewers.
Find what you hold
oz0 subject find [email protected]
Subject hash: 8e71c42de9472845a912a7b270e1add4ea7a193a6d1c8c70ca22283c35f076a5
Keys: 2 live, 0 destroyed
Audit entries: 7 (0 redacted)
Jobs: 2
job-2b39f8cf-0ab4-47d9-9252-fc67fb848fc0 2026-10-03 06:35 readable support
job-71c0e2a4-5d6f-4c35-9a0e-3b8f0d7c1e55 2026-10-04 09:12 readable bookkeeper keep_for 7y until 2033-10-06 09:12
It also lists the person's restrictions and objections, how many decision records their jobs have, and an erasure that waits for a second person, including those recorded under the spelling's hash from before identifiers had one normal form.
Each job shows its agent, what keeps it (an agent's keep-for period), whether it is readable, deferred (an erasure waits for its period), erased, or off (started while erasure was off), and how many people it is about.
After an erasure that deferred jobs, Keys counts the person's keys that are kept only for those jobs as closed. job get and job trace on those jobs show what they hold. In the console, the Data subjects tab of Govern → Privacy shows the same.
Give a person their data
You need subjects.find and the content permission to export a person's data. Check that --account, if used, names that person's account: a wrong link puts another member's chats in the bundle. Export the bundle, verify it, then review its omissions before handing it over:
oz0 subject export [email protected] --out ./alice
oz0 subject export [email protected] --tar alice.tar --account alice
oz0 subject export --verify ./alice --key <fingerprint from oz0 audit key>
The bundle is a folder (or a tar file) you can hand over:
| File | What it holds |
|---|---|
index.html | everything below as one page to read in a browser; it loads nothing from the network and runs no script |
subject.json | the person's jobs with their agent, start and the date each is kept until; erasures with the jobs a keep-for period keeps and why; restrictions and objections; decision records and contests; the purposes the jobs named, each with the tenant's legal basis and its description |
audit/entries.jsonl | the audit entries about the person |
recipients.json | for each agent that ran a job about the person, where it can send data (recipients), as its records say today |
content/jobs/ | each of the person's jobs, child jobs included, with what it was started with, its steps' inputs and outputs and its answer, the tenant's secrets redacted in every form a job's content can hold them; a job whose own input and answer could not be read says so in its entry and in not_included |
content/board/ | the notes agents pinned to the boards of the person's job trees |
content/records.jsonl | the records plugins (such as the memory plugin) kept from those job trees |
content/chats/ | the chats of the person's own account, when they are a member |
manifest.json, manifest.sig, content/manifest.*, keys/ | every file's size and SHA-256, signed with the cluster's audit key and the edge's gateway key |
How it is made: an edge reads what the person's jobs read and wrote, their boards, records and chats, which only edges can open, and signs what it read; management adds its records, checks the edge's signature, and signs the whole. --verify checks a bundle anywhere, without the cluster or the network: both signatures, every file, nothing missing or added. Pin the audit key with --key and the fingerprint oz0 audit key prints, handed over by another channel.
What it holds and what it does not:
- Chats: the bundle holds the chats of the account that is the person, read as that account may read them.
A member whose sign-in name is the person's ID (often an email address) is linked by itself; --account names another, and the export's audit entry records which account was linked and how.
Reading those chats is a read of someone else's chat like any other: each is audited as conversation.view.private with the export as its reason, and the account's owner sees it.
Check the link before you hand the bundle over: a wrong --account puts another member's chats into it.
- Another member's private chat about the person is listed without what was said, as everywhere else. The board notes and plugin records of such a chat's job trees are left out too, and
not_includedsays how many. Whether the person's copy should hold it is a legal question the platform does not answer. - Staff appear by role, never by name: audit entries name the kind of actor (
user,apikey,system), and so do the fields of their details that say who acted (who approved a step, who asked for a change), the jobs' records (who exported them, who decided their approvals) and the bundle's own "made by". Decision records name who took part by role.
The person's own account stays named.
What a job read and wrote is the person's data and is in the copy as it was written, so a name someone typed into a job's input is there too.
Whether that is right for your copy is a legal question too; the audit log keeps the names for those who may read it.
- Walls: the walls of the tenant's label policies hold for the person who makes the bundle, and, for the account's chats, for that account too.
A job, a chat's turn or an audit entry's private part a wall closes is in the bundle without its content, marked as withheld by a wall (walled on an audit line, a note on a chat).
A board note or a plugin record a wall closes, by its job tree's compartments or by its own, is left out, as the board and the records route leave it out, and not_included says how many.
An audit entry's private part is decided by the job's compartments when the entry was recorded, so one written after its job joined a walled compartment is withheld too.
A bundle made by someone the walls do not apply to holds it.
- Jobs past Temporal's history retention are listed with what management keeps of them, and the bundle warns that what they read and wrote is gone.
- An erased person's bundle holds the erasure's record and the redacted audit entries' count, nothing of their jobs.
- A job about several people is in each of their bundles whole, with the others' data in it.
It needs the subjects.find permission and the content permission (a tenant admin with content), and is audited about the person (subject.export, subject.export.content), so erasing them redacts the entries too. Whether the bundle is a complete answer to a request is for you and your data protection officer to judge.
Exports
A person's own copy is their bundle. A whole-tenant export carries people's data the tenant holds: who started, owned and decided jobs, members and teams, audit entries' actors, and with --content what jobs read and wrote. It is audited, and its content needs the content permission.
What erasure took stays out of it: an erased subject's jobs are left out of the tables and of the jobs' content even before the edge has deleted them, their audit entries are exported redacted, and their erasure is exported as a record that names a hash, never the person.
Someone else's private chat is exported without what was said unless the exporter gives a reason, which is audited per chat and shown to the chat's owner.