GDPR Right to Erasure

Mnemom supports GDPR Article 17 (right to erasure) through a documented, auditable deletion cascade. When a deletion request is issued, the agent is immediately inaccessible and an automated cascade removes agent-identifiable data from Mnemom’s data stores, with cryptographic and regulatory audit trails preserved.

This document describes the technical deletion mechanism. It does not constitute legal advice. Consult qualified legal counsel for your specific GDPR obligations as a data controller or processor.

Requesting deletion

Agent-level deletion

curl -X DELETE \
  -H "X-Mnemom-Api-Key: $MNEMOM_API_KEY" \
  https://api.mnemom.ai/v1/agents/{agent_id}

Response: 202 Accepted

{
  "deletion_request_id": "dr-a1b2c3d4-...",
  "status": "tombstoned",
  "requested_at": "2026-04-16T14:30:00Z"
}

The status value progresses through the cascade phases documented in Cascade phase breakdown below. Initial state after the 202 is tombstoned (the agent is immediately inaccessible — all read endpoints return 404); the deletion-status endpoint below reports progress through the remaining phases. The agent is immediately inaccessible — all read endpoints return 404 after the request is accepted. Data deletion proceeds asynchronously across all stores. An owner or admin of the org that governs the agent can delete it, and so can the agent’s creator while they are still a member of that org. Another member of the org gets 403; a caller outside the org gets 404, the same answer as an agent that doesn’t exist. The same rule applies to tombstoning and restoring an agent.

Org-level deletion

curl -X DELETE \
  -H "Authorization: Bearer $TOKEN" \
  https://api.mnemom.ai/v1/orgs/{org_id}

Only the org’s owner can call this. Unlike agent deletion, org deletion does not cascade to the org’s agents — it is refused with 409 Conflict until every blocker is cleared:

Every agent in the org must already be deleted (or tombstoned).
The org must have no active subscription.
The org must have no remaining API keys.

Once those are clear, the call revokes the org’s API keys, deletes the org record, and returns 200 OK with { "deleted": true }.

Deleting an org does not delete its agents. To fully erase an org’s data, delete each agent first (above), then delete the org.

Checking deletion status

curl -H "X-Mnemom-Api-Key: $MNEMOM_API_KEY" \
  https://api.mnemom.ai/v1/agents/{agent_id}/deletion-status

Returns the current phase and completion status of the deletion cascade. Any member of the agent’s org can read it. After the cascade has removed the agent itself, only the person who requested the deletion or a member of the org recorded on the request can read it. Everyone else gets 404, the same answer as when no deletion was requested.

Idempotency

Repeated DELETE requests for the same agent return 202 with the existing deletion request. The operation is safe to retry.

What gets deleted

Fully removed (hard delete)

All agent-specific data is permanently deleted from Mnemom’s primary database:

Data category	Examples
Integrity & reasoning	Integrity checkpoints, cryptographic verdict proofs, cross-turn advisories, containment logs, reclassification history
Cards & policies	The agent’s alignment card, protection card, policies, and policy evaluations
Reputation & trust	Reputation scores, reputation events, trust edges, reputation snapshots
On-chain mapping	Off-chain Merkle tree state and score-publication records that link the agent to its on-chain anchors (see On-chain anchors below)
Detection & session data	Safe House evaluations and configs, drift alerts, session records, agent-authored content, feedback the agent filed
Agent record itself	The agent record, its composed/canonical card, and any per-section exemptions are removed last, once every table that references the agent has been cleared
Cache	All cached data associated with the agent

Retained under a legal carve-out (Article 17(3))

A small number of record types are not deleted or pseudonymized — they are kept exactly as-is because deleting them would conflict with another legal obligation:

Data category	Legal basis	What is retained
Usage and billing records	Art. 17(3)(b) tax/accounting	Retained verbatim, including the agent identifier — required for reproducible historical billing.

Pseudonymized (person stripped, record retained)

Two record types are scrubbed of agent- and person-identifying fields but kept for audit purposes:

Data category	Legal basis	What is retained
Governance audit log	SOC 2 audit trail, Art. 17(3)(e) legal claims	Timestamps and action types. The agent identifier is replaced with an irreversible pseudonym; before/after snapshots are cleared.
Card amendments	Tamper-evidence / signed correction record	The signed amendment and its before/after diff are kept as evidence; only the requesting person’s identifier is removed and the agent identifier is pseudonymized.

Naturally expiring (external stores)

Mnemom’s own OpenTelemetry spans (distinct from the traces database rows removed in phase 7 above) are exported to the observability backend and age out under that platform’s own retention window, independent of the deletion cascade.

On-chain anchors

Mnemom anchors aggregate Merkle roots to Base L2 for tamper-evidence (see On-Chain Verification). These on-chain records are immutable by design. However, agent identifiers do not appear in any on-chain data. The Merkle leaf pre-images contain only checkpoint-specific fields (checkpoint ID, verdict, thinking block hash, chain hash, timestamp). Deleting the off-chain mapping tables permanently severs the link between an agent and any on-chain anchor.

Deletion timeline

Phase	Timing	What happens
Immediate (< 1 second)	On request	Agent tombstoned; all read endpoints return 404
Cascade	Async, kicked off immediately; a cron sweep every 15 minutes resumes any interrupted cascade	Database rows deleted across all tables; cached data cleared
Pseudonymization	Async	Retained records scrubbed of agent identifiers
Complete	Monitored against an internal 2-hour SLA — well inside GDPR’s “without undue delay” standard	Deletion request status transitions to `complete`
Trace expiry	Per the observability backend’s own retention window	OpenTelemetry spans (separate from the `traces` database rows already removed above) age out naturally

Deletion is irreversible. Once a deletion request completes, the agent and all associated data cannot be recovered. Ensure you have exported any needed data before requesting deletion.

Cascade phase breakdown

Each deletion request transitions through a fixed sequence of status values as the cascade progresses. Use GET /v1/agents/{agent_id}/deletion-status to observe the current phase.

Phase	`status` value	What happens
Tombstone	`tombstoned`	Agent immediately inaccessible; all read endpoints return `404`. Deletion cascade queued.
Phase 1	`phase_1_complete`	Cross-turn advisory history and cryptographic verdict proofs deleted.
Phase 2	`phase_2_complete`	Integrity and reasoning deleted — integrity checkpoints, webhook registrations, containment logs, disagreement reviews.
Phase 3	`phase_3_complete`	Cards and policies deleted — the agent’s alignment card, protection card, policies, policy evaluations.
Phase 4	`phase_4_complete`	Reputation and trust deleted — reputation scores, reputation events, trust edges, reputation snapshots.
Phase 5	`phase_5_complete`	On-chain mapping deleted — off-chain Merkle tree state and score-publication records.
Phase 6	`phase_6_complete`	Detection configs, drift alerts, session records, agent-authored content, and agent-filed feedback deleted.
Phase 7	`phase_7_complete`	Behavioral traces and Safe House evaluations deleted, then the agent record itself — which also removes its composed/canonical card and any exemptions.
Cache cleared	`kv_cleared`	All cached data associated with the agent is cleared.
Pseudonymized	`pseudonymized`	Retained records scrubbed of agent identifiers. See Retained in pseudonymized form below.
Complete	`complete`	Full cascade complete. All agent-identifiable data removed except the Article 17(3) carve-outs above.
Failed	`failed`	Cascade halted at a phase. The `failed_phase` field identifies where. Automatic retries apply.

Retained in pseudonymized form

When the status transitions to pseudonymized, the records listed under Pseudonymized (person stripped, record retained) above have had agent and person identifiers replaced with a one-way hash. The pseudonym is irreversible — no re-identification from retained records is possible. See Legal basis for retained data below for the applicable Article 17(3) carve-outs.

Data export (access & portability)

Before deleting an agent, you can export its full compliance record — checkpoints, reclassification history, card amendments, and score history:

curl -H "X-Mnemom-Api-Key: $MNEMOM_API_KEY" \
  "https://api.mnemom.ai/v1/agents/{agent_id}/compliance-export?format=json"

Supports format=json or format=csv, and an optional from/to time window. This is the self-service path for the GDPR right of access (Art. 15) and data portability (Art. 20) — export before you erase.

Verification

After deletion completes, you can verify:

API verification: GET /v1/agents/{agent_id} returns 404.
Status verification: GET /v1/agents/{agent_id}/deletion-status returns { "status": "complete", "completed_at": "..." }.
Audit trail: The deletion request record is retained indefinitely as proof of compliance (Art. 30 record of processing activities).

Legal basis for retained data

GDPR Article 17(3) permits continued processing where erasure conflicts with other legal obligations:

Carve-out	Article 17(3) paragraph	Mnemom application
Legal claims	(e)	Governance audit log — retained as a pseudonymized record for legal defense
Tamper-evidence	(e)	Card amendments — the signed correction record is retained with the person stripped and the agent identifier pseudonymized
Legal obligation	(b)	Billing and usage records — retained verbatim, including the agent identifier, under tax/accounting law
Record of processing	Art. 30	Deletion request record itself — retained as proof that the erasure was performed

For data protection officers

If you are an enterprise customer’s DPO conducting a compliance review:

Technical specification: Full deletion cascade architecture documentation is available on request, including the complete table inventory, FK cascade analysis, retention carve-outs with legal citations, and partial failure handling.
Response time SLA: Tombstoning (agent inaccessible from every read endpoint) is immediate — under 1 second. The full cascade to complete is monitored internally against a 2-hour SLA, well inside the GDPR “without undue delay” obligation (Art. 17(1)); an interrupted cascade is automatically resumed by a cron sweep every 15 minutes.
Audit evidence: Every deletion request is logged in deletion_requests with timestamps, status transitions, and the requesting user’s identity.
Scope confirmation: To confirm that all agent data has been removed, request a deletion status check — the response confirms cascade completion across all stores.

EU AI Act Compliance — Article 50 transparency obligations (AI Act, separate regulation)
Security Trust Model — Mnemom’s security architecture
On-Chain Verification — How Merkle anchoring works

Identity & Cards

Posture & Policy

Detection & Safe House

Reputation & Risk

Lifecycle

GDPR Right to Erasure

Requesting deletion

Agent-level deletion

Org-level deletion

Checking deletion status

Idempotency

What gets deleted

Fully removed (hard delete)

Retained under a legal carve-out (Article 17(3))

Pseudonymized (person stripped, record retained)

Naturally expiring (external stores)

On-chain anchors

Deletion timeline

Cascade phase breakdown

Retained in pseudonymized form

Data export (access & portability)

Verification

Legal basis for retained data

For data protection officers

​Requesting deletion

​Agent-level deletion

​Org-level deletion

​Checking deletion status

​Idempotency

​What gets deleted

​Fully removed (hard delete)

​Retained under a legal carve-out (Article 17(3))

​Pseudonymized (person stripped, record retained)

​Naturally expiring (external stores)

​On-chain anchors

​Deletion timeline

​Cascade phase breakdown

​Retained in pseudonymized form

​Data export (access & portability)

​Verification

​Legal basis for retained data

​For data protection officers

​Related

Requesting deletion

Agent-level deletion

Org-level deletion

Checking deletion status

Idempotency

What gets deleted

Fully removed (hard delete)

Retained under a legal carve-out (Article 17(3))

Pseudonymized (person stripped, record retained)

Naturally expiring (external stores)

On-chain anchors

Deletion timeline

Cascade phase breakdown

Retained in pseudonymized form

Data export (access & portability)

Verification

Legal basis for retained data

For data protection officers

Related