Skip to main content
When a data subject invokes their right to be forgotten, you need two things: a portable copy of their data, and an irreversible delete that actually reaches every surface their activity touched — not just the user row. OrcaRouter makes both self-serve. A signed-in account can export its own data and schedule its own deletion; the deletion runs as a 30-day grace window followed by a PII scrub that cascade-purges the observability records tied to that account. This page covers the customer-observable erasure flow. For where evidence artifacts live, see Data residency; for how long request logs persist independently of erasure, see Retention.

​
1. gdpr erasure llm: the self-serve DSAR flow

Three console actions cover a data-subject access request end to end. Each is a UserAuth route under /api/user/* — driven by your console session, never a relay (sk-orca-…) key:

Export

Download a portable JSON copy of your personal data before you delete.

Delete

Soft-delete immediately; schedule the irreversible scrub for +30 days.

Cancel

Restore the account any time inside the grace window.
The export is data portability — the access half of a DSAR. The delete is the erasure half. Run the export first; once the scrub fires, there is nothing left to export.

​
2. Export your data (one concrete flow)

From the console, open Account → Privacy and choose Export my data. The console drives this read route with your session: 
GET /api/user/self/export
Authorization: Bearer <your console session>
The response is a downloadable JSON document of your profile and non-secret personal data. The export is an explicit allow-list — it never includes your password hash, your system access token, OAuth secrets, webhook/notification credentials, or request-log payload bodies.
Export stays available during the grace window. A scheduled-for-deletion account is soft-deleted but can still reach export and cancel — portability is the entire point of keeping that door open until the scrub runs.

​
3. Schedule the deletion

Account → Privacy → Delete my account soft-deletes the account immediately and schedules the PII scrub for now + 30 days: 
DELETE /api/user/self
Authorization: Bearer <your console session>
Content-Type: application/json

{ "password": "<current password>" }
The response carries the scheduled scrub date. A few guards apply:
Password accounts must supply their current password on the delete request — defense against a hijacked session permanently destroying data. OAuth-only accounts have no password; the authenticated session is the proof.
If you are the only owner of a shared team workspace that still has other members, the delete is refused — otherwise teammates would inherit an ownerless workspace. Transfer ownership or archive the workspace first.
The instance root account is refused — self-erasing it would leave the deployment with no super-admin. Hand off the root role first.
Calling delete again while already pending returns a friendly “already scheduled” response rather than an error.
Once scheduled, your session is restricted to the cancel and export endpoints for the rest of the grace window — a kept cookie no longer passes auth on the rest of /api/user/*. Cancelling lifts the restriction and restores full access without a re-login.

​
4. The 30-day grace window

The grace window is a deliberate undo buffer. Until it elapses the account is soft-deleted, not erased, and one call restores it: 
POST /api/user/self/deletion/cancel
Authorization: Bearer <your console session>
If a cancel lands in the race between the sweep selecting your account and the scrub running, the now-active account is not anonymized — the scrub guards on a still-pending state and skips anything that was revived.
Treat the 30 days as your DSAR fulfilment SLA buffer. A subject who changes their mind, or a request raised in error, is fully recoverable until the window closes — after which the scrub is irreversible by design.

​
5. The PII scrub and its cascade purge

When the grace window elapses, a sweep runs the scrub. It does not just hide a row — it strips direct identifiers and cascade-purges the records your activity left across every observability surface:
SurfaceWhat the scrub does
AccountDirect identifiers anonymized; credentials, keys, OAuth bindings, passkeys, and 2FA hard-deleted
Request logsPurged from the request-log store
Accounting / usage rowsUsername redacted and IP cleared on rows retained for billing
Guardrail matchesPurged — including any raw matched substrings
Firewall eventsPurged — tool names, IPs, and request IDs attributed to you
The account fields are anonymized in place (username and email rewritten to a deleted-… placeholder, status disabled), so accounting and audit rows that have a lawful basis to persist keep their shape while losing the embedded personal data. Everything credential-bearing is hard-deleted — true erasure, not a soft-delete that merely hides.
The cascade reaches the same three surfaces you read elsewhere in the console: Guardrail matches, Firewall events, and request logs. After the scrub, none of them resolve back to the deleted person. This is what makes the erasure symmetric across the content layer, the action layer, and the log.
Note the distinction from raw matched content. Guardrail matches only store a matched substring when that guardrail’s Log raw content toggle is on (off by default). Either way, the scrub purges those records entirely — so the toggle changes what was ever recorded, not what survives a deletion.

​
6. Erasure vs retention

Erasure and retention are two different clocks — don’t conflate them:
  • Retention ages out request logs on a rolling window for everyone — a 30-day default, server-clamped to a 180-day hard maximum. See Retention.
  • Erasure is a one-time, account-scoped event triggered by a DSAR: the 30-day grace window, then the scrub.
A subject’s logs may already have aged out under retention before they ever file a DSAR; the scrub still runs against whatever remains and redacts the retained accounting rows.

​
7. Where this fits

Right-to-erasure is one piece of your data-subject obligations. Pair it with region-stamped evidence and the broader compliance loop:

Retention

The rolling request-log window — 30-day default, 180-day clamp — that runs independently of erasure.

Data residency

The region your signed compliance reports are stored and served under.

GDPR pack

Install the controls and ship signed GDPR evidence to an auditor.

Shared responsibility

What the gateway erases for you and what stays your decision.
The gateway gives you a self-serve DSAR that reaches every record it owns. Deciding when a deletion is required, and meeting any jurisdiction-specific deadline, remains your call — the 30-day grace window is your buffer for making it.