GDPR Data Subject Rights

Mnemom supports GDPR Article 17 (right to erasure) through a documented, auditable deletion cascade. When a deletion request is issued, all agent-identifiable data is removed from Mnemom’s data stores within minutes, 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.

Org-level deletion

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

Deletes the organization and cascades deletion to all agents belonging to the org. Returns 202 Accepted with the count of affected agents.

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.

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
Identity & cards	Agent record, alignment cards, protection cards, canonical composed cards, policies, exemptions
Integrity & reasoning	Integrity checkpoints, verdict proofs, enforcement nudges, containment logs
Reputation & trust	Reputation scores, reputation events, trust edges, reputation snapshots
Detection & analysis	Safe House evaluations, threat training traces, sideband analyses
Configuration	Safe House configs, policy evaluations, card amendments, tool registrations
Webhooks	Webhook registrations and delivery history
Cryptographic state	Merkle tree state, score publication records
Cache	All cached data across Cloudflare KV namespaces

Pseudonymized (agent identity removed, structure retained)

Certain records are retained for regulatory compliance but have all agent-identifying information replaced with an irreversible pseudonym:

Data category	Legal basis	What is retained
Governance audit log	SOC 2 audit trail, Art. 17(3)(e) legal claims	Timestamps, action types, actor IDs. Card snapshots scrubbed.
Usage and billing records	Art. 17(3)(b) tax/accounting	Amounts, dates, plan types. Agent identifier replaced with pseudonym.
API audit log	Art. 17(3)(e) security	Request metadata (method, path, status). Request/response bodies scrubbed.

Naturally expiring (external stores)

Store	Retention	Treatment
Observability traces	30 days (configurable via `audit_commitment.retention_days`)	A deletion denylist prevents traces from being surfaced in queries or API responses during the residual retention window. Traces expire naturally.
AI Gateway logs	Per Cloudflare retention policy	Same denylist mechanism. Logs expire per platform policy.

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 (< 60 seconds typical)	Async	Database rows deleted across all tables; KV keys cleared
Pseudonymization (< 60 seconds)	Async	Retained records scrubbed of agent identifiers
Complete	< 5 minutes	Deletion request status transitions to `complete`
Trace expiry	Up to 30 days	Observability traces age out naturally (denylist active)

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`	Identity and cards deleted — agent record, alignment cards, protection cards, canonical composed cards, policies, exemptions.
Phase 2	`phase_2_complete`	Integrity and reasoning deleted — integrity checkpoints, verdict proofs, enforcement nudges, containment logs.
Phase 3	`phase_3_complete`	Reputation and trust deleted — reputation scores, reputation events, trust edges, reputation snapshots.
Phase 4	`phase_4_complete`	Detection and analysis deleted — Safe House evaluations, threat training traces, sideband analyses.
Phase 5	`phase_5_complete`	Configuration deleted — Safe House configs, policy evaluations, card amendments, tool registrations.
Phase 6	`phase_6_complete`	Webhooks deleted — webhook registrations and delivery history.
Phase 7	`phase_7_complete`	Cryptographic state deleted — Merkle tree state, score publication records.
KV cleared	`kv_cleared`	All cached data cleared across Cloudflare KV namespaces.
Pseudonymized	`pseudonymized`	Retained records scrubbed of agent identifiers. See Retained in pseudonymized form below.
Complete	`complete`	Full cascade complete. All agent-identifiable data removed.
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 (agent identity removed, structure retained) above have had agent 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.

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, API audit log, admin audit log — retained as pseudonymized records for legal defense
Legal obligation	(b)	Billing and usage records — retained under tax/accounting law with agent identifier pseudonymized
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: Deletion requests are processed within 5 minutes (p99). The GDPR “without undue delay” obligation (Art. 17(1)) is satisfied by immediate tombstoning (< 1 second) and full cascade completion (< 5 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

​Requesting deletion

​Agent-level deletion

​Org-level deletion

​Checking deletion status

​Idempotency

​What gets deleted

​Fully removed (hard delete)

​Pseudonymized (agent identity removed, structure retained)

​Naturally expiring (external stores)

​On-chain anchors

​Deletion timeline

​Cascade phase breakdown

​Retained in pseudonymized form

​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)

Pseudonymized (agent identity removed, structure retained)

Naturally expiring (external stores)

On-chain anchors

Deletion timeline

Cascade phase breakdown

Retained in pseudonymized form

Verification

Legal basis for retained data

For data protection officers

Related