Data handling

​

Where data lives

​

What we store

​

Identity

• A soul object summarizing the user’s core identity, values, and patterns.
• Social graph nodes for people the user has mentioned.

​

Activity

• Every /execute call’s message and the agent’s response, in conversation history.
• Tool calls and results.
• Permission decisions.

​

Inferences

• Episodes summarizing past events.
• Knowledge facts inferred from observations.
• Social graph edges inferred from conversations.

​

External access

• MCP server connections and their (encrypted) credentials.
• Active scopes per connection.

​

What we don’t store

• The raw data passing through MCP servers (e.g. the body of every Slack message the agent reads). Only what gets surfaced into context during a turn.
• LLM provider responses beyond what’s in conversation history. We don’t keep a separate “model call log.”
• User credentials for the Engine itself (we keep only the hash, if using ENGINE_KEY_HASH).
• Plaintext API keys for LLM providers (those live in env, not in data).

​

Retention

​

Per-user isolation

​

PII

• The user’s name, in the soul and in social-graph nodes.
• Names of people the user mentions, in social-graph nodes.
• Email addresses, phone numbers, addresses if the user shares them.
• Quotes from emails, messages, or documents the user processed through the agent.

• Encrypt the volume at rest.
• Restrict access to the brain volume to the Engine’s service account only.
• Don’t ship logs containing user content to third-party log pipelines.
• Consider redaction at the log level for sensitive fields.

​

Deletion

​

One user’s data

docker compose down --volumes  # if running per-user-engine in compose
# or
kubectl delete pvc engine-data-<user>  # if running in k8s

​

One conversation thread

DELETE FROM conversations WHERE thread_id = '...';
DELETE FROM working_memory_log WHERE thread_id = '...';
DELETE FROM trajectories WHERE thread_id = '...';
DELETE FROM channel_state_snapshots WHERE thread_id = '...';

​

One specific memory item

​

Right-to-erasure (GDPR / DPDP)

• The user’s brain.
• Backups containing their data.
• Log lines containing their data.

1. Wipe the brain volume.
2. Mark backup snapshots covering the user’s data for deletion at the next lifecycle cycle.
3. Submit a redaction request to the log pipeline (most providers support this; runs over hours-to-days).
4. Confirm deletion with the user via your application’s user-facing compliance flow.

​

Incident response

1. Take the affected Engine offline. Stop the container; preserve the volume for forensics.
2. Revoke MCP credentials. Delete every connection in the affected brain so the credentials in the volume become inactive.
3. Rotate all secrets that touched the affected environment.
4. Investigate. What was compromised? What was extracted?
5. Communicate. Notify the user and (if required by jurisdiction) regulators.
6. Restore from a clean snapshot if appropriate, or stand up a fresh Engine with a clean brain.

​

Compliance posture

• GDPR. Right-to-erasure flows above. Data minimization via retention policy. Encryption at rest.
• India DPDP. Same as GDPR plus data localization for Indian users (host the Engine in an Indian region).
• SOC 2. Volume encryption + secret management + audit logging (observability_events).
• HIPAA. Not a default fit; the Engine’s not designed for PHI. If required, additional controls would need to be added (BAA with the LLM provider, additional encryption, audit retention).

​

See also

• Threat model — what we defend against.
• Access control — who can do what.
• Database — backup, restore, cleanup.
• Secrets — handling sensitive config.