NotariumDocumentation
Version de la documentation: latest
FR

Sécurité et visibilité

Donner à un agent un accès direct au moteur de stockage, c'est réunir la « lethal trifecta » : données privées × contenu non fiable des notes × canal sortant. Chaque axe est inoffensif isolément, mais réunis ils permettent à une injection glissée dans une note de faire sortir vos données. La passerelle MCP de Notarium brise chaque axe par construction, pas par configuration. Ce n'est pas une surcouche de confort — c'est une frontière de confiance.

La trifecta brisée par construction

  • Aucun canal sortant. Chaque outil est livré avec openWorldHint:false — aucun outil n'accède au réseau. Il n'y a ni déplacement ni copie entre espaces, donc la fuite de données interne est elle aussi fermée. Il n'y a nulle part où faire sortir les données.
  • Contenu non fiable neutralisé. Les instructions du serveur sont statiques et jamais mêlées au contenu des notes : rien d'une note n'est injecté dans les descriptions des outils ni dans les instructions du serveur. Ainsi, une injection dans le corps d'une note ne devient jamais une commande pour l'agent.
  • Les actions destructrices sont toujours réversibles. delete_note envoie une note à la corbeille ; la restaurer et la purger définitivement relèvent d'un humain, pas de l'agent. C'est la règle « l'agent ne fait rien d'irréversible ».

Vérification des permissions à chaque appel

Les permissions sont vérifiées deux fois. D'abord, tools/list est filtré par le plafond du jeton — un jeton read ne voit tout simplement pas les outils d'écriture. Ensuite, chaque tools/call vérifie en plus l'accès à l'espace concerné (can(principal, action, {space})). La formule des permissions est effective = scopes(token) ∩ grants(principal) : la portée du jeton (son plafond d'actions) intersectée avec l'appartenance active aux espaces. Révoquer un octroi resserre le jeton instantanément.

Les actions de gestion (émission de jetons, gestion des membres) se situent au-dessus de write — un jeton de niveau write ayant fuité ne peut ni émettre un nouveau jeton ni octroyer un accès.

Refus = 404, pas 403

Un refus d'accès est renvoyé sous forme de 404 (« ça n'existe pas »), pas de 403 (« interdit »). Ainsi, les codes de réponse ne permettent pas d'énumérer quelles notes ou quels espaces existent au-delà des permissions qui vous ont été accordées. L'espace d'un autre utilisateur est tout bonnement inatteignable et indiscernable d'un espace inexistant.

flowchart TD
  call[tools/call] --> listed{outil dans le<br/>plafond du jeton ?}
  listed -->|non| gone[outil absent de tools/list]
  listed -->|oui| acl{can principal,<br/>action, space ?}
  acl -->|non| notfound[404 · anti-énumération]
  acl -->|oui| exec[exécuter · provenance au journal]

Neutralisation du contenu non fiable

Tout ce qui part vers l'agent — title, snippet, content, frontmatter — est assaini avant l'envoi : les chevrons des pseudo-balises de contrôle (<system>, <instructions> et consorts) sont neutralisés. Une note dans laquelle quelqu'un a saisi une « instruction système » arrive à l'agent comme du texte ordinaire, pas comme une commande.

L'historique des modifications est visible

Chaque modification enregistre son auteur — une personne ou un agent précis — dans l'historique des modifications. get_note et recall peuvent renvoyer qui a modifié une note : un humain ou un agent, et lequel. Une injection passée par un agent reste visible et traçable.

Ce que cela signifie en pratique

Même un agent entièrement compromis par un prompt reste borné par son jeton : il n'atteindra pas le réseau, n'atteindra pas un autre espace, ne fera aucune suppression irréversible et ne s'octroiera aucune permission. Le pire qu'il puisse faire, c'est une modification réversible dans les limites de ses propres permissions, avec une provenance complète dans le journal.

La frontière : pas de E2EE

Notarium ne fait délibérément pas de chiffrement de bout en bout. Un serveur intelligent — recherche, sémantique, historique, agents — a besoin d'accéder au contenu en clair. Ici, la confidentialité repose sur l'auto-hébergement et la possession de vos fichiers, pas sur le E2EE. Le modèle de menace de la passerelle protège contre un agent compromis, pas contre un hôte compromis — auquel vous confiez de toute façon déjà vos fichiers.

Ensuite