End-user erasure

When one of your customers asks you to delete their data, an owner or admin can ask Morse to erase everything it holds about that end user in your workspace. The end user is identified by the user_id your agent sets on its traces (see Set context).

Start a request from Settings → Data handling → Erasure requests. The account-level controls for deleting your own Morse account are separate: see GDPR.

Who can request it

Owners and admins. A member sees counts and a note that owners and admins can request erasure; they do not see end-user ids. Erasure is not available in demo mode.

How the end user is matched

Morse matches the id you type exactly against the user_id on your traces, in your workspace only. The match is case-sensitive, with no wildcards and no partial matches: cust-42 does not match CUST-42 or cust-421. An empty id matches nothing. The same id in another workspace is never touched.

Before you confirm, Morse shows a preview: how many traces and how many pieces of feedback that id would remove. The preview uses the same selection the erasure uses, so the number matches.

If the same user appears under more than one id (an email on one agent, a database id on another), request each id. Morse does not infer that two ids are the same person.

What is erased

For every trace with that user_id:

the trace, its spans and context segments;
the derived rows built from it: eval scores and scoring jobs, eval cases curated from it, replays of its spans, outcome and attribution records, record keys, log records, rule candidates and connector attempts;
the stored payloads (prompts and outputs) kept in object storage;
the copies in the analytics store;
the audit-history rows that held a copy of the deleted content, such as comments and feedback.

Feedback this end user left on other users’ traces is also removed. Those traces stay; only the feedback rows go.

An error group, which is a pattern across many runs, is kept, but its sample message and its pointer to an erased trace are cleared.

Three stores

A request reports a status for each store:

Store	What it holds	States
`postgres`	Traces, spans, derived rows, audit-history copies	pending, done, failed
`blobs`	Large payloads in object storage	pending, done, failed, not configured
`tinybird`	The analytics copies of trace headers, spans and costs	pending, done, failed, not configured

An object-storage payload is deleted only when no remaining row refers to it. If a delete cannot be confirmed, the store is marked failed rather than assumed clean. Not configured means that store does not exist in your deployment, so there is nothing to delete from it, and it counts as finished.

The request itself has a status: pending, running, done, partial (at least one store still has work left) or failed. Morse says a user is erased in every store only when each store is done or not configured. Until then the request reads “Partly erased”.

Retries

Erasure is idempotent, so running it again is always safe. When a store fails, the request becomes partial and Morse retries automatically with a growing delay (1, 2, 4 minutes and so on, up to an hour), six times over about two hours. If it still has not finished, the request is marked failed.

From there an owner or admin can retry a failed or partial request. Morse holds the end-user id in plain text only while a retry may still need it. If a failed request goes 30 days without a retry, the id is cleared and the request can no longer be retried; start a new one.

What Morse keeps about the request

Each request is an audited record: who asked, when, the status of each store, and how many traces and feedback rows were erased. The end-user id itself is removed when the request completes. What stays is a keyed hash, used only to recognise a repeat request in the same workspace, and a short hint (the first two and last two characters). A second request for an id that is still in progress returns the existing request instead of starting another.

Backups

Morse’s database backups are snapshots and are not edited. Erased data therefore stays in backups until they age out, which takes up to 90 days. The request and the Data handling page state this number. A request reads as complete when the live stores are clean; the backup window is the stated time for the last copies to expire.

What it does not cover

Other places your data lives. Erasure removes what Morse stored. It cannot reach your LLM provider, your own logs, or anything you exported from Morse.
Mentions in someone else’s trace. If the end user’s name appears inside the prompt or output of a trace that belongs to a different user_id, that trace stays.
Traces you never tagged. A trace with no user_id cannot be matched to anyone.

Before you have data

With no requests, the panel reads “No erasure requests”. If the preview finds no traces for an id, the request would erase nothing, and the preview says so.

Data handling
Set context — how user_id gets onto a trace.
GDPR — export and deletion of your own account.