Seguridad y visibilidad

Darle a un agente acceso directo al motor de almacenamiento significa reunir la «trifecta letal»: datos privados × contenido no confiable de las notas × un canal de salida. Cada eje por separado es inofensivo, pero juntos permiten que una inyección dentro de una nota saque tus datos por la puerta. La pasarela MCP de Notarium rompe cada eje por diseño, no por configuración. No es un envoltorio pensado para la comodidad: es una frontera de confianza.

La trifecta rota por diseño

• Sin canal de salida. Todas las herramientas se entregan con openWorldHint:false: ninguna herramienta llega a la red. No hay forma de mover ni copiar entre espacios, así que la fuga interna de datos también queda cerrada. No hay a dónde sacar los datos.
• Contenido no confiable desactivado. Las instrucciones del servidor son estáticas y nunca se mezclan con el contenido de las notas: nada de una nota se incorpora a las descripciones de las herramientas ni a las instructions del servidor. Así, una inyección en el cuerpo de una nota nunca se convierte en una orden para el agente.
• Las acciones destructivas siempre son reversibles. delete_note envía una nota a la papelera; restaurarla y purgarla de forma definitiva lo hace una persona, no el agente. Esa es la línea de «el agente no hace nada irreversible».

Comprobación de permisos en cada llamada

Los permisos se comprueban dos veces. Primero, tools/list se filtra por el techo del token: un token read simplemente no ve las herramientas de escritura. Luego, cada tools/call comprueba además el acceso al espacio concreto (can(principal, action, {space})). La fórmula de permisos es effective = scopes(token) ∩ grants(principal): el alcance del token (su techo de acciones) intersecado con la membresía activa en los espacios. Revocar una concesión restringe el token al instante.

Las acciones de gestión (emitir tokens, gestionar miembros) están por encima de write: un token de nivel write filtrado no puede emitir un nuevo token ni conceder acceso.

Denegación = 404, no 403

Una denegación de acceso se devuelve como 404 («no existe tal cosa»), no como 403 («no permitido»). Así, los códigos de respuesta no sirven para enumerar qué notas o espacios existen más allá de los permisos que se te han concedido. El espacio de otra persona es sencillamente inalcanzable e indistinguible de uno que no existe.

flowchart TD
  call[tools/call] --> listed{¿herramienta dentro del<br/>techo del token?}
  listed -->|no| gone[herramienta ausente de tools/list]
  listed -->|sí| acl{can principal,<br/>action, space?}
  acl -->|no| notfound[404 · anti-enumeración]
  acl -->|sí| exec[ejecutar · procedencia al registro]

Desactivación del contenido no confiable

Todo lo que va al agente —title, snippet, content, frontmatter— se sanea antes de enviarse: los corchetes angulares de las pseudoetiquetas de control (<system>, <instructions> y similares) quedan desactivados. Una nota en la que alguien escribió una «instrucción de sistema» llega al agente como texto corriente, no como una orden.

El historial de ediciones es visible

Cada edición registra quién la hizo —una persona o un agente concretos— en el historial de ediciones. get_note y recall pueden devolver quién editó una nota: una persona o un agente, y cuál. Una inyección que pasó a través de un agente permanece visible y rastreable.

La frontera: no es E2EE

Notarium deliberadamente no hace cifrado de extremo a extremo. Un servidor inteligente —búsqueda, semántica, historial, agentes— necesita acceso al texto en claro. Aquí la privacidad se construye sobre el autoalojamiento y la propiedad de tus archivos, no sobre E2EE. El modelo de amenazas de la pasarela protege frente a un agente comprometido, no frente a un host comprometido, al que de todos modos ya confías tus archivos.

Siguiente

• Conectar un agente — tokens, permisos y la fachada OAuth.
• Auditoría de recuperación — observabilidad de lo que buscó el agente.
• Herramientas de intención — por qué el conjunto de herramientas es exactamente este.