# Memória sensível

Entenda os controles reais de sanitização e visibilidade na recuperação usados para credenciais, dados pessoais e memórias de alta sensibilidade.

- Canonical: https://docs.xmemo.dev/pt-br/docs/concepts/sensitive-memory
- Locale: pt-BR
- Content-Locale: pt-BR
- Canonical-Content-Digest: f4135c91811fc6ab82f0fcbe64bdbe557f8f57024585230ef640f73d09da08fa
- Edition-Digest: a17f19f20a7785a0db74315702d8684c15bffefcbc49641cc8a9b7e76bc75343
- Source-Revision: sha256:2d80a1534f639a21ed4385df129fd914a3ed4da7b24c261eee0ad18032a0f691

## Sensível é uma política de tratamento, não um tipo de memória

O enum memory_type do contrato de memória é episodic, semantic, procedural, working ou identity; não há um valor sensitive. A sensibilidade é tratada por controles compartilhados de redação e envelope de segurança, e não pela invenção de um sexto tipo de memória.

- Valores com formato de credencial sempre são redigidos pelo sanitizador canônico do servidor.
- Os dados pessoais do proprietário são mantidos por padrão e redigidos quando o proprietário habilita auto_redact_pii.
- Conteúdo de alto risco com chave privada ou segredo AWS faz a captura do agente ignorar o evento.

## Sanitize conteúdo, metadados e proveniência juntos

sanitize_server_write aplica o registro de regras compartilhado a toda string alcançável em uma linha de memória, incluindo conteúdo, metadados e proveniência. Rótulos de credencial, chaves de API, JWTs, segredos em URLs e outros valores registrados com formato de credencial são removidos antes da persistência; a redação nunca retorna o valor bruto nos metadados do resultado.

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

## O modo Vault pode manter a memória local

O envelope de segurança registra security_mode, encryption_state, retrieval_visibility, server_embeddings_enabled e server_content_search_enabled. O modo Vault armazena texto cifrado e usa por padrão retrieval_visibility=client_local_only, com embeddings do servidor desabilitados; a recuperação no servidor é excluída, a menos que o tenant opte explicitamente pela indexação semântica.

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

## A recuperação obedece ao envelope

O bloqueio de recuperação do servidor descarta linhas marcadas como client_local_only ou not_retrievable. As linhas Vault também são excluídas, a menos que seus metadados optem explicitamente por vault_semantic_index_opt_in; o envelope de segurança descreve essa opção como um compromisso porque ela permite um índice semântico no servidor. Use a recuperação local para conteúdo que não deve entrar na recuperação do servidor.

```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
```

## Usuário do ChatGPT

Dê ao ChatGPT acesso duradouro às suas preferências do XMemo, fatos do projeto, decisões e TODOs sem colar tokens bearer no chat.

Conecte o servidor MCP hospedado do XMemo pelo fluxo OAuth do app ChatGPT/OpenAI e aprove a concessão memory:read e memory:write para sua conta do XMemo.

Salve uma preferência de teste ou anotação de projeto, inicie um novo chat e peça ao ChatGPT para recuperá-la via XMemo antes de prosseguir.

Se o OAuth falhar ou as ferramentas não aparecerem, saia do servidor MCP no app host, reconecte a URL do servidor XMemo e tente novamente antes de criar tokens diretos.

## Desenvolvedor Copilot / Codex

Transfira decisões do repositório, convenções de código, notas de correção de bugs e histórico de tarefas entre agentes de IDE e CLI.

Use OAuth para VS Code / GitHub Copilot e Gemini CLI quando disponível. Para Copilot CLI, Codex, Cursor ou outros clientes MCP diretos, mantenha XMEMO_KEY no ambiente local ou cofre de segredos e defina um XMEMO_AGENT_INSTANCE_ID estável.

Registre uma decisão da base de código ou correção de bug e peça ao próximo agente de IDE ou CLI para recuperar o contexto relevante do XMemo antes de editar.

Se as recuperações estiverem vazias, verifique o caminho da configuração MCP selecionada, a variável de ambiente XMEMO_KEY para clientes diretos e eventuais credenciais OAuth desatualizadas no app host.

## Líder de piloto de equipe / corporativo

Avalie a memória compartilhada com controles de conta, atribuição de origem, fluxos de exportação/exclusão e evidências de configuração seguras para revisores.

Crie ou acesse o espaço de trabalho protegido do XMemo, convide usuários aprovados e conecte cada cliente via OAuth ou credencial direta com escopo de acordo com os selos de disponibilidade.

Peça para um membro do piloto salvar uma memória de equipe de teste, confirme a atribuição de origem no XMemo e revise os caminhos de exclusão/exportação e suporte.

Se um membro não conseguir se conectar, verifique as permissões de função, aprovação OAuth, status de prontidão do cliente e orientações de suporte antes de emitir um novo token.

## Operador de agentes autônomos

Permita que agentes headless ou agendados registrem progresso, recuperem decisões anteriores e mantenham uma identidade estável e não secreta de instância.

Obtenha /api/v1/mcp/config/autonomous-agent. Prefira auth_modes.oauth quando o executor suportar OAuth + cabeçalhos personalizados; use auth_modes.xmemo_key com XMEMO_KEY de um cofre de segredos apenas para executores totalmente headless.

Execute uma tarefa de teste que grave progresso no XMemo, reinicie o executor e confirme se ele recupera esse progresso usando o mesmo XMEMO_AGENT_INSTANCE_ID.

Se a atribuição mudar ou as recuperações se dividirem entre instâncias, persista XMEMO_AGENT_INSTANCE_ID fora do git e verifique se o executor não o está gerando a cada início.