NotariumDokumentation
Dokumentationsversion: latest
DE

Sicherheit und Sichtbarkeit

Einem Agenten direkten Zugriff auf die Storage-Engine zu geben, heißt, die „lethal trifecta“ zusammenzubauen: private Daten × nicht vertrauenswürdiger Notizinhalt × ein ausgehender Kanal. Jede Achse für sich ist harmlos, doch zusammen ermöglichen sie es einer Injektion in einer Notiz, deine Daten nach draußen zu tragen. Das MCP-Gateway von Notarium durchbricht jede Achse durch Konstruktion, nicht durch Konfiguration. Das ist kein Wrapper aus Bequemlichkeit — es ist eine Vertrauensgrenze.

Die Trifecta konstruktiv durchbrochen

  • Kein ausgehender Kanal. Jedes Tool wird mit openWorldHint:false ausgeliefert — kein Tool erreicht das Netz. Es gibt kein Verschieben oder Kopieren zwischen Spaces, damit ist auch das interne Datenleck geschlossen. Es gibt keinen Ort, an den man Daten tragen könnte.
  • Nicht vertrauenswürdiger Inhalt entschärft. Die Anweisungen des Servers sind statisch und werden niemals mit Notizinhalt vermischt: Nichts aus einer Notiz fließt in Tool-Beschreibungen oder in die server-instructions ein. So wird eine Injektion im Notiztext nie zum Befehl an den Agenten.
  • Destruktive Aktionen sind immer umkehrbar. delete_note schickt eine Notiz in den Papierkorb; das Wiederherstellen und das endgültige Löschen erledigt ein Mensch, nicht der Agent. Das ist die Linie „der Agent tut nichts Unumkehrbares“.

Berechtigungsprüfung bei jedem Aufruf

Berechtigungen werden zweimal geprüft. Zuerst wird tools/list durch die Obergrenze des Tokens gefiltert — ein read-Token sieht die schreibenden Tools schlicht nicht. Dann prüft jeder tools/call zusätzlich den Zugriff auf den konkreten Space (can(principal, action, {space})). Die Berechtigungsformel lautet effective = scopes(token) ∩ grants(principal): der Scope des Tokens (seine Obergrenze an Aktionen) geschnitten mit der aktiven Mitgliedschaft in Spaces. Der Entzug einer Zugriffsgewährung verengt das Token augenblicklich.

Management-Aktionen (Tokens ausstellen, Mitglieder verwalten) liegen über write — ein geleaktes Token auf write-Ebene kann kein neues Token ausstellen und keinen Zugriff gewähren.

Ablehnung = 404, nicht 403

Eine Zugriffsverweigerung wird als 404 („so etwas gibt es nicht“) zurückgegeben, nicht als 403 („nicht erlaubt“). So lässt sich über die Antwortcodes nicht durch Ausprobieren ermitteln, welche Notizen oder Spaces jenseits der dir gewährten Berechtigungen existieren. Der Space eines anderen ist schlicht nicht erreichbar und nicht von einem unterscheidbar, der gar nicht existiert.

flowchart TD
  call[tools/call] --> listed{Tool innerhalb der<br/>Obergrenze des Tokens?}
  listed -->|nein| gone[Tool fehlt in tools/list]
  listed -->|ja| acl{can principal,<br/>action, space?}
  acl -->|nein| notfound[404 · Anti-Enumeration]
  acl -->|ja| exec[ausführen · Provenienz ins Protokoll]

Nicht vertrauenswürdigen Inhalt entschärfen

Alles, was an den Agenten geht — Titel, Snippet, Inhalt, Frontmatter — wird vor dem Versand bereinigt: bei Pseudo-Control-Tags (<system>, <instructions> und dergleichen) werden die spitzen Klammern entschärft. Eine Notiz, in die jemand eine „Systemanweisung“ getippt hat, erreicht den Agenten als gewöhnlicher Text, nicht als Befehl.

Der Bearbeitungsverlauf ist sichtbar

Jede Bearbeitung hält fest, wer sie vorgenommen hat — eine bestimmte Person oder ein Agent — im Bearbeitungsverlauf. get_note und recall können zurückgeben, wer eine Notiz bearbeitet hat: ein Mensch oder ein Agent, und welcher genau. Eine Injektion, die durch einen Agenten gelaufen ist, bleibt sichtbar und nachverfolgbar.

Was das in der Praxis bedeutet

Selbst ein durch einen Prompt vollständig kompromittierter Agent bleibt durch sein Token eingegrenzt: Er erreicht das Netz nicht, erreicht keinen fremden Space, führt keine unumkehrbare Löschung aus und gewährt sich keine Berechtigungen selbst. Das Schlimmste, was er tun kann, ist eine umkehrbare Bearbeitung im Rahmen seiner eigenen Berechtigungen, mit vollständiger Provenienz im Protokoll.

Die Grenze: kein E2EE

Notarium verzichtet bewusst auf Ende-zu-Ende-Verschlüsselung. Ein smarter Server — Suche, Semantik, Verlauf, Agenten — braucht Zugriff auf den Klartext. Privatsphäre baut hier auf Self-Hosting und dem Besitz deiner Dateien auf, nicht auf E2EE. Das Bedrohungsmodell des Gateways schützt vor einem kompromittierten Agenten, nicht vor einem kompromittierten Host, dem du deine Dateien ohnehin schon anvertraust.

Weiter