---
title: Erase a subject (Article 17)
path: guides/erase-a-subject
status: published
---

# Erase a subject (Article 17)

Erasing a subject in ScaiLog is a cryptographic operation, not a search-and-
delete. ScaiLog stored every one of the subject's PI fields encrypted under a
per-subject data-encryption key (DEK); erasure destroys that key. With the key
gone, the ciphertext is unrecoverable wherever it was ever written — no need to
find and overwrite each row. This needs the `dpo` capability and is irreversible.

## Run the erasure

The CLI prompts for confirmation unless you pass `--confirm`. It reports how many
entries were tombstoned, the receipt id, and the `absolute_after` date.

```bash
scailog erase usr_8842 --confirm
# => erased — 1 entries tombstoned, receipt 01J…, absolute_after 2026-…Z
```

The equivalent API call requires `confirm: true` in the body:

```http
POST /v1/erase
Authorization: Bearer <dpo-capable key>
Content-Type: application/json

{ "tenant": "default", "subject": "usr_8842", "confirm": true, "mode": "tombstone" }
```

## Cryptographic erasure: the DEK is destroyed

The core of erasure is destroying the subject's DEK. Because PI was only ever
persisted encrypted under that DEK, destroying it makes every encrypted PI field
for that subject permanently undecryptable — fleet-wide, including any copies in
downstream SQLite files, because none of them hold the key. This is why ScaiLog
can promise erasure in Phase 1 without a distributed delete job. After erasure, a
[DSAR](/docs/scailog/guides/handle-a-dsar) for the subject returns
`subject_erased: true` and empty `pi_values`.

## Tombstone mode vs delete mode

Erasure has two modes. Default is `tombstone`; choose with `--mode`.

- **`tombstone`** (default) keeps the log entries for audit and integrity but
  marks them erased. The encrypted PI is already unreadable (its DEK is gone),
  and any plaintext `keep`-action PI is additionally scrubbed, since crypto-
  shredding only covers `encrypt`ed fields.
- **`delete`** removes the subject's entries outright. The receipt reports the
  count under `entries_deleted` instead of `entries_tombstoned`.

```bash
scailog erase usr_8842 --confirm --mode delete
```

## The signed erasure receipt

Every erasure produces an Ed25519-signed receipt — your evidence that the
Article 17 request was executed. The receipt records:

| Field | Meaning |
| --- | --- |
| `receipt_id` | ULID for this receipt |
| `type` | `"erasure"` |
| `tenant`, `subject` | who was erased |
| `requested_by` | the key id that ran it |
| `requested_at` | when the request was received |
| `key_destroyed_at` | when the DEK was destroyed |
| `entries_tombstoned` / `entries_deleted` | count, per mode |
| `erasure_mode` | `tombstone` or `delete` |
| `absolute_after` | `key_destroyed_at` + the configured keymap-backup retention (default 7 days) — after this, even key backups are gone |
| `signature` | Ed25519 signature block with `key_id` + public key |

Fetch a stored receipt again at `GET /v1/receipts/{receipt_id}`, and verify any
receipt offline the same way as a DSAR report:

```bash
scailog report-key verify receipt.json
```

## Idempotency and late-arriving PI

Erasure is idempotent: re-erasing an already-erased subject returns the
**original** receipt unchanged rather than minting a new zero-count one, so
retries and duplicate requests are safe.

ScaiLog also protects against PI that arrives *after* erasure. If a new log entry
comes in naming an erased subject, ScaiLog refuses to mint a fresh DEK for them;
the PI field is redacted server-side to `[REDACTED:<pi_type>]` and recorded with
the action `redact_erased`, so the entry is stored PI-free instead of silently
resurrecting the subject's data.