Governance

GDPR Data Erasure

Open Astra supports the GDPR Right to Erasure (Article 17). A single API call purges all user data across every data tier in the system. Users can only delete their own data.

Purging user data

bash
# GDPR Right to Erasure — purge all data for a user
curl -X DELETE http://localhost:3000/memory/user/uid_alice \
  -H "Authorization: Bearer ${JWT_TOKEN}"

# Response
{
  "purged": true,
  "tiers": [
    "session_messages",
    "sessions",
    "daily_memory",
    "user_profiles",
    "graph_edges",
    "graph_entities",
    "procedural_memory",
    "embedding_cache",
    "semantic_cache",
    "refresh_tokens",
    "revoked_tokens",
    "login_attempts",
    "agent_traces",
    "billing_usage",
    "audit_log"
  ]
}

Data tiers purged

The purge deletes data from 15 tables in dependency order (child rows first, then parent rows):

#TableDescription
1session_messagesAll conversation messages
2sessionsSession records
3daily_memoryTier 2 daily notes
4user_profilesTier 3 user profile
5graph_edgesTier 4 knowledge graph edges
6graph_entitiesTier 4 knowledge graph entities
7procedural_memoryTier 5 procedural memory
8embedding_cacheCached embeddings
9semantic_cacheSemantic response cache
10refresh_tokensActive refresh tokens
11revoked_tokensRevoked token records
12login_attemptsLogin attempt history
13agent_tracesAgent execution traces
14billing_usageBilling and usage records
15audit_logAudit entries (purge event is recorded before deletion)
ℹA gdpr.data_purge audit event is recorded before the audit log entries are deleted, ensuring there is always a record that a purge occurred.

Safety

  • Users can only purge their own data — the :uid parameter must match the authenticated user
  • Tables that don't exist yet (e.g., before first migration) are skipped gracefully
  • The operation is transactional — if any tier fails, the entire purge is rolled back