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.

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

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 — tokens, permissões e a fachada OAuth.
• Auditoria de recuperação — observabilidade sobre o que o agente buscou.
• Ferramentas de intenção — por que o conjunto de ferramentas é exatamente este.