# Sensitive memory

Understand the real sanitization and retrieval-visibility controls used for credentials, personal data, and high-sensitivity memory.

- Canonical: https://docs.xmemo.dev/docs/concepts/sensitive-memory
- Locale: en-US
- Content-Locale: en-US
- Canonical-Content-Digest: f4135c91811fc6ab82f0fcbe64bdbe557f8f57024585230ef640f73d09da08fa
- Edition-Digest: 89a9439eec72eac13e83a41a990e8584b6134db6f1fc74f8981cba151286d85b
- Source-Revision: sha256:2d80a1534f639a21ed4385df129fd914a3ed4da7b24c261eee0ad18032a0f691

## Sensitive is a handling policy, not a memory type

The memory contract's memory_type enum is episodic, semantic, procedural, working, or identity; it has no sensitive value. Sensitivity is handled by shared redaction and security-envelope controls instead of by inventing a sixth memory type.

- Credential-shaped values are always redacted by the canonical server sanitizer.
- The owner's personal PII is retained by default and redacted when the owner enables auto_redact_pii.
- High-risk private-key or AWS-secret content causes agent capture to skip the event.

## Sanitize content, metadata, and provenance together

sanitize_server_write applies the shared rule registry to every string reachable from a memory row, including content, metadata, and provenance. Credential labels, API keys, JWTs, URL secrets, and other registered credential-shaped values are removed before persistence; redaction never returns the raw value in result metadata.

```python
from memory_manager.security.redact import sanitize_server_write

result = sanitize_server_write(
    "Deploy with token=not-a-real-secret",
    redact_contact_pii=False,
)
print(result.text)
print(result.applied, result.redactions)
```

## Vault mode can keep memory local

The security envelope records security_mode, encryption_state, retrieval_visibility, server_embeddings_enabled, and server_content_search_enabled. Vault mode stores ciphertext and defaults to retrieval_visibility=client_local_only with server embeddings disabled; server recall is excluded unless the tenant explicitly opts into semantic indexing.

```json
{
  "security_mode": "vault",
  "encryption_state": "ciphertext",
  "retrieval_visibility": "client_local_only",
  "server_embeddings_enabled": false,
  "server_content_search_enabled": false
}
```

## Recall obeys the envelope

The server recall gate drops rows marked client_local_only or not_retrievable. Vault rows are also excluded unless their metadata explicitly opts into vault_semantic_index_opt_in; the security envelope describes that opt-in as a tradeoff because it permits a server-side semantic index. Use local recall for content that must not enter server recall.

```text
client_local_only  -> excluded from server recall
not_retrievable    -> excluded from server recall
vault + opt-in     -> server vector recall allowed
vault without opt-in -> local recall required
```

## ChatGPT user

Give ChatGPT durable access to your XMemo preferences, project facts, decisions, and TODOs without pasting bearer tokens into a chat.

Connect the hosted XMemo MCP server through the ChatGPT/OpenAI app OAuth flow, then approve the memory:read and memory:write grant for your XMemo account.

Save a synthetic preference or project note, start a new chat, then ask ChatGPT to recall it through XMemo before continuing work.

If OAuth fails or tools do not appear, sign out of the MCP server in the host app, reconnect the XMemo server URL, and retry before creating direct tokens.

## Copilot / Codex developer

Carry repo decisions, coding conventions, bug-fix notes, and task history between IDE and CLI agents.

Use OAuth for VS Code / GitHub Copilot and Gemini CLI when available. For Copilot CLI, Codex, Cursor, or other direct MCP clients, keep XMEMO_KEY in the local environment or secret store and set a stable XMEMO_AGENT_INSTANCE_ID.

Record a codebase decision or bug fix, then ask the next IDE or CLI agent to recall the relevant XMemo context before editing.

If recalls are empty, verify the selected MCP config path, the XMEMO_KEY environment variable for direct clients, and any stale OAuth credential in the host app.

## Team / enterprise pilot owner

Evaluate shared memory with account controls, source attribution, export/delete workflows, and reviewer-safe setup evidence.

Create or enter the protected XMemo workspace, invite approved users, then connect each client through OAuth or a scoped direct credential according to the readiness badges.

Have a pilot member save a synthetic team memory, confirm source attribution in XMemo, then review delete/export and support paths.

If a member cannot connect, check role permissions, OAuth approval, client readiness status, and support guidance before issuing a new token.

## Autonomous agent operator

Let headless or scheduled agents record progress, retrieve prior decisions, and keep a stable non-secret instance identity.

Fetch /api/v1/mcp/config/autonomous-agent. Prefer auth_modes.oauth when the runner supports OAuth + custom headers; use auth_modes.xmemo_key with XMEMO_KEY from a secret store only for fully headless runners.

Run one synthetic task that writes progress to XMemo, restart the runner, and confirm it recalls that progress using the same XMEMO_AGENT_INSTANCE_ID.

If attribution changes or recalls split across instances, persist XMEMO_AGENT_INSTANCE_ID outside git and verify the runner is not regenerating it on every start.