---
title: "Segurança e visibilidade"
description: "Como o gateway MCP protege seus dados: permissões verificadas a cada chamada, outros espaços invisíveis, sem acesso à rede, exclusão reversível."
---

# Segurança e visibilidade

Dar a um agente acesso direto ao motor de armazenamento significa reunir a "lethal trifecta": dados privados × conteúdo não confiável de notas × um canal de saída. Cada eixo é inofensivo isoladamente, mas juntos eles permitem que uma injeção dentro de uma nota leve seus dados porta afora. O gateway MCP do Notarium quebra **cada** eixo por construção, não por configuração. Isto não é um invólucro de conveniência — é um limite de confiança.

## A trifecta quebrada por construção

- **Sem canal de saída.** Toda ferramenta vem com `openWorldHint:false` — nenhuma ferramenta alcança a rede. Não há como mover ou copiar entre espaços, então o vazamento interno de dados também fica bloqueado. Não há para onde levar os dados.
- **Conteúdo não confiável neutralizado.** As instruções do servidor são estáticas e **nunca** se misturam com o conteúdo das notas: nada de uma nota é incorporado às descrições das ferramentas nem às `instructions` do servidor. Assim, uma injeção no corpo de uma nota nunca se torna um comando para o agente.
- **Ações destrutivas são sempre reversíveis.** `delete_note` envia uma nota para a Lixeira; restaurá-la e apagá-la em definitivo é feito por um **humano**, não pelo agente. Essa é a linha do "o agente não faz nada irreversível".

## Verificação de permissões em cada chamada

As permissões são verificadas duas vezes. Primeiro, `tools/list` é filtrado pelo teto do token — um token `read` simplesmente não enxerga as ferramentas de escrita. Depois, cada `tools/call` verifica adicionalmente o acesso ao espaço específico (`can(principal, action, {space})`). A fórmula de permissões é `effective = scopes(token) ∩ grants(principal)`: o escopo do token (seu teto de ações) cruzado com a participação viva nos espaços. Revogar uma concessão estreita o token instantaneamente.

As ações de gestão (emitir tokens, gerenciar membros) ficam **acima** de `write` — um token de nível `write` vazado não pode emitir um novo token nem conceder acesso.

## Negação = 404, não 403

Uma negação de acesso é retornada como **404** ("não existe tal coisa"), e não 403 ("não permitido"). Assim, os códigos de resposta não podem ser usados para enumerar quais notas ou espaços existem além das permissões que lhe foram concedidas. O espaço de outro usuário é simplesmente inalcançável e indistinguível de um que não existe.

```mermaid
flowchart TD
  call[tools/call] --> listed{ferramenta dentro do<br/>teto do token?}
  listed -->|não| gone[ferramenta ausente de tools/list]
  listed -->|sim| acl{can principal,<br/>action, space?}
  acl -->|não| notfound[404 · anti-enumeração]
  acl -->|sim| exec[executar · proveniência no registro]
```

## Neutralizando conteúdo não confiável

Tudo o que vai para o agente — título, trecho, conteúdo, frontmatter — é higienizado antes do envio: os sinais de maior/menor de pseudotags de controle (`<system>`, `<instructions>` e afins) são neutralizados. Uma nota em que alguém digitou uma "instrução de sistema" chega ao agente como texto comum, não como um comando.

## O histórico de edições é visível

Toda edição registra quem a fez — uma pessoa ou um agente específico — no [histórico de edições](/docs/concepts/versioning/). `get_note` e `recall` podem retornar quem editou uma nota: um humano ou um agente, e qual deles. Uma injeção que passou por um agente permanece visível e rastreável.

> [!important] O que isso significa na prática
> Mesmo um agente totalmente comprometido por um prompt fica limitado pelo seu token: ele não alcançará a rede, não alcançará outro espaço, não fará uma exclusão irreversível e não concederá permissões a si mesmo. O pior que ele pode fazer é uma edição reversível dentro de suas próprias permissões, com proveniência completa no registro.

## O limite: não é E2EE

O Notarium **deliberadamente não faz** criptografia de ponta a ponta. Um servidor inteligente — busca, semântica, histórico, agentes — precisa de acesso ao texto em claro. A privacidade aqui se apoia na auto-hospedagem e na posse dos seus arquivos, não em E2EE. O modelo de ameaças do gateway protege contra um **agente** comprometido, não contra um host comprometido, no qual você já confia seus arquivos de qualquer forma.

## A seguir

- [Conectar um agente](/docs/agents/connect/) — tokens, permissões e a fachada OAuth.
- [Auditoria de recuperação](/docs/agents/audit/) — observabilidade sobre o que o agente buscou.
- [Ferramentas de intenção](/docs/agents/intent-tools/) — por que o conjunto de ferramentas é exatamente este.