Security and privacy

How Palim protects content, where the trust boundary sits, and which controls you retain.

Encryption at rest

Supported content fields are encrypted on the server with AES-256-GCM before they are stored in the database. Palim uses scrypt to derive a separate key for each user from a server-managed master key.

Data class	Encrypted content	Readable operational metadata
Sessions	Messages, summary text, and structured summary fields	Session ID, title, status, tool source, timestamps, project, tags, source URLs, and a `summary_preview` of up to 280 characters for context checkpoints
Memories	Content; encrypted copies of tags and additional memory metadata also exist	ID, type, user association, timestamps, and the tags and additional metadata in fields that are currently readable as well
Brain	Markdown content of a topic	Slug, title, hook, entry count, source-session IDs, and timestamps. The hook can contain a short summary excerpt.
User modeling	Encrypted copies are created for user context, rules, and profiles	The corresponding content or profile fields are currently also stored in readable form. These features depend on deployment configuration; profiles are staff-only in production.

This metadata remains readable for association, filtering, navigation, and operation. “Encrypted” therefore does not mean that every database value is encrypted.

Not end-to-end or zero-knowledge encryption

The Palim server can decrypt content to provide search, retrieval, and export. The server runtime and master key are therefore part of the trust boundary.

Account isolation

Authentication and database policies associate stored data with one user. OAuth clients do not receive shared credentials. API keys are user-specific and should be rotated immediately if exposed.

Your controls

Connected agents create proactive context checkpoints after substantial results by default. These contain a compact summary, not the complete message transcript automatically.
You can prohibit storage of individual content; secrets and trivial conversations should not be stored.
Sessions can be inspected, changed through MCP metadata tools, and deleted. Their messages and summary are not generally editable.
Memories can be inspected, edited, and permanently deleted.
Individual sessions can be exported in open formats.
The Brain view can be exported as a Markdown vault.
Palim does not use your stored conversations to train models.

A single complete export covering every data class is not currently available. Contact privacy@usepalim.com for account deletion or privacy requests.

Processing by connected AI tools

Palim returns decrypted search results and stored content to the AI client that calls the tool. From that point, the data-processing terms of the connected AI provider also apply.

Normal Brain distillation runs deterministically on the Palim server and uses stored session summaries. There is an optional step that has a language model rewrite an oversized Brain topic, which would transmit that topic's decrypted content to the model provider. This step is switched off. It is enabled solely through the server setting PALIM_BRAIN_CONSOLIDATION — a stored API key explicitly does not enable it. The active state is publicly visible at /health under brain_consolidation; none means this transfer is not happening.

Work securely

Prefer OAuth over API keys when your client supports it.
Store API keys only in secret or connector configuration.
Do not share connection URLs; their token is an access credential.
Review exported files before sharing them.
Delete or rotate credentials after a possible leak.

See Manage data and credentials for the exact differences between status deletion, permanent dashboard deletion, API keys, and connection URLs.

Where your data lives

Storage location, the full subprocessor list, and GDPR accountability are documented on the EU data residency page.