Unbeaufsichtigte Desktop-CLI und MCP

Unbeaufsichtigter Zugriff ist eine ausdrücklich eingerichtete, ausschließlich lokale, schreibgeschützte Berechtigung für ausgewählte aktive Tresore. Sie umfasst gewöhnliche und private Erinnerungen/Karten, ursprüngliche Binärdateien, den Revisionsverlauf und ausdrücklich angeforderten Klartext von Zugangsdaten. Aktivieren Sie sie nur, wenn Sie dem empfangenden Client sämtliche Assets und Geheimnisse dieser Tresore anvertrauen. Sie entspricht weder gewöhnlicher MCP-Berechtigung noch einer dauerhaften sudo-Sitzung.

Registrieren und Schlüsselverwahrung auswählen

Starten Sie den Daemon in einem separaten Terminal und verwenden Sie für jeden Befehl dasselbe dedizierte absolute Home-Verzeichnis. Initialisieren Sie zunächst Ihre Bibliothek und erstellen Sie ihre Tresore wie gewohnt. Die folgenden Pfade sind Beispiele; verwenden Sie auf jeder Plattform Ihr eigenes privates Verzeichnis.

memories --home /absolute/private/home daemon

Wählen Sie in Ihrem interaktiven Terminal ausdrücklich ein Backend:

memories --home /absolute/private/home unattended enable --backend linux-secret-service

Die Registrierung warnt, dass Clients gespeicherte Passwörter lesen können, fordert Sie zur Eingabe von ENABLE auf und fragt anschließend Ihr lokales Passwort zum Entsperren und erneut für sudo ab. Diese Einrichtung mit Zustimmung und Passwort ist einmal für die Registrierung erforderlich, nicht bei jedem unbeaufsichtigten Lesezugriff. Übergeben Sie Passwörter weder als Argumente noch als Umgebungsvariablen. Spätere Verwaltung erfordert weiterhin ein gewöhnliches, mit Passwort entsperrtes und für sudo autorisiertes Terminal.

Die bewusste Wahl der weniger geschützten Option erfolgt beispielsweise mit unattended enable --backend owner-file. Es gibt keinen automatischen Rückfall, wenn ein natives Backend nicht verfügbar ist oder Interaktion benötigt. Secret Service beruht auf der lokalen Grenze zwischen Betriebssystemkonto und D-Bus; der Client kann beliebiges anbieterspezifisches Oberflächenverhalten nicht kontrollieren. Die Backend-Auswahl erfolgt nur bei der Erstellung. Ändern Sie seine Metadaten nicht, um das Backend zu wechseln. Die Verwahrung bindet den kanonischen Speicherpfad und die aktuelle Header-Identität; eine Kopie in einen anderen Speicher stellt daher keine Registrierung dar.

Der Passwort-Wrapper bleibt für gewöhnliches Entsperren und Wiederherstellung verfügbar. Die Registrierung ergänzt einen separaten Master-Key-Wrapper, dessen Verpackungsschlüssel außerhalb der Datenbank bleibt; sie ersetzt die Passwortauthentifizierung nicht.

Eine Client-Datei ausstellen

Stellen Sie im selben autorisierten Terminal eine Freigabe für die vom Client benötigten Tresore aus:

memories --home /absolute/private/home unattended mint --vault VAULT_ID --client-file /absolute/private/home/client.json
# Repeat --vault VAULT_ID to include another vault in this grant.

Das übergeordnete Verzeichnis muss bereits existieren und ausschließlich dem Eigentümer zugänglich sein. Die Ausstellung veröffentlicht die Datei atomar, ohne eine vorhandene Datei zu überschreiben, und weist unsichere Eigentumsverhältnisse, Berechtigungen oder Links zurück. Bei fehlgeschlagener Veröffentlichung wird versucht, die neue Freigabe zu widerrufen; ein gescheiterter Widerruf wird gemeldet. Die Ausgabe enthält Freigabe-ID und Dateipfad, niemals das Bearer-Token. Bewahren Sie die ID für den Widerruf auf.

Diese Client-Datei ist von gewöhnlichen MCP-Freigabedateien getrennt. Schützen Sie sie wie ein Passwort; geben Sie ihren Inhalt nicht aus, committen Sie ihn nicht und übergeben Sie ihr Token nicht als Befehlsargument. CLI/MCP-Lesezugriffe erfordern die ausdrückliche Auswahl mit --client-file und dasselbe Home bzw. denselben Speicher. Der Geltungsbereich ist read_only_all_assets für die ausgewählten Tresore, keine Freigabe pro Asset oder nur für gewöhnliche Inhalte. Jeder Lesezugriff prüft erneut die aktuelle lokale Gerätemitgliedschaft und den Tresor-Geltungsbereich.

Start und Lesezugriffe

Starten Sie den Daemon nach der Registrierung neu, um den Start nur mit Schlüsseln zu nutzen. Beenden Sie ihn, ohne memories lock auszuführen, und starten Sie ihn anschließend mit demselben Home erneut. Ein erfolgreicher Start lädt unbeaufsichtigte Schlüssel, meldet jedoch für den gewöhnlichen Zustand unlocked: false: gewöhnliches Lesen, Schreiben, sudo, Cloud-Arbeit und RAG bleiben bis zum Entsperren mit Passwort gesperrt. Bei einem Backend-Fehler bleiben unbeaufsichtigte Schlüssel ungeladen; es gibt keinen Rückfall auf Passwort oder Umgebungs-Authentifizierung.

Unter Unix kann erzwungenes Beenden service.sock im Home-Verzeichnis zurücklassen. Entfernen Sie diesen veralteten Socket erst, nachdem Sie bestätigt haben, dass sein Daemon beendet wurde.

memories --home /absolute/private/home unattended list VAULT_ID --client-file /absolute/private/home/client.json
memories --home /absolute/private/home unattended history VAULT_ID ASSET_ID --client-file /absolute/private/home/client.json
memories --home /absolute/private/home unattended read VAULT_ID ASSET_ID --client-file /absolute/private/home/client.json
memories --home /absolute/private/home unattended credential-bytes VAULT_ID CREDENTIAL_ID --client-file /absolute/private/home/client.json

List liefert Asset-Metadaten, einschließlich privater Assets, Dateien und Zugangsdaten, jedoch nicht deren Inhalte; Löschmarkierungen werden ausgelassen. History liefert Revisionsmetadaten einschließlich Head-/Gelöscht-/Quarantäne-Flags, keine Zugangsdaten-Inhalte. Ein aktuelles Asset mit Konflikt erfordert eine ausdrücklich passende Revision. Historische und gelöschte Revisionen können ausdrücklich gelesen werden, Revisionen in Quarantäne werden jedoch verweigert. Dieser Pfad liest den Verlauf aktiver Tresore, keine Wiederherstellungsarchive.

read liefert Content-JSON-Bytes von Erinnerungen/Karten oder die ursprünglichen Bytes einer Datei. Zugangsdaten werden zurückgewiesen. credential-bytes akzeptiert ausschließlich Zugangsdaten und liefert die UTF-8-Bytes des gespeicherten Inhalts, einschließlich historischer Werte bei ausdrücklicher Auswahl. Es ergänzt keine Speicherung beliebiger binärer Zugangsdaten. Geschützte Geheimnisreferenzen in Karten und Wikis bleiben Referenzen; fordern Sie die referenzierten Zugangsdaten bei Bedarf separat an.

Vollständige Bytes zusammensetzen

Antworten verwenden data mit base64url ohne Padding, dem bei null beginnenden offset, der Byteanzahl total, next (null bei Abschluss), der tatsächlichen revision und encoding (content_json oder raw_bytes). So rufen Sie den vollständigen Inhalt ab:

1. Fordern Sie Offset 0 mit --limit zwischen 1 und 65536 Bytes an (Standard 65536).
2. Dekodieren Sie data jeder Antwort separat als base64url ohne Padding.
3. Verwenden Sie next als nächsten --offset und fixieren Sie die zuerst zurückgegebene Revision mit --revision REVISION_ID bei jeder nachfolgenden Anfrage.
4. Fahren Sie fort, bis next null ist, und verketten Sie anschließend die dekodierten Bytebereiche in ihrer Reihenfolge. Dekodieren Sie erst danach gegebenenfalls UTF-8/JSON; ein Bereich kann ein UTF-8-Zeichen teilen.

Ein nachfolgender Bereich verwendet beispielsweise:

memories --home /absolute/private/home unattended read VAULT_ID ASSET_ID --client-file /absolute/private/home/client.json --revision REVISION_ID --offset NEXT_OFFSET --limit 65536

Verwenden Sie dieselben Optionen mit credential-bytes. Verketten Sie keine kodierten Zeichenfolgen und behandeln Sie den ersten Bereich nicht als vollständiges Asset. List/history verwenden --offset und --limit zwischen 1 und 100 Einträgen (Standard 100); ihre Seiten spiegeln den aktuellen Zustand wider, keinen Snapshot. Änderungen zwischen Anfragen können daher Reihenfolge und Gesamtzahlen verändern.

Einen KI-Client über MCP verbinden

Konfigurieren Sie einen separaten stdio-Serverbefehl mit demselben Home und derselben Client-Datei:

memories --home /absolute/private/home mcp serve-unattended --client-file /absolute/private/home/client.json

Er bietet ausschließlich unattended_list, unattended_history, unattended_read und unattended_credential_bytes an. Werkzeugargumente sind vault, asset (außer bei list), die optionale revision (Byte-Lesezugriffe), offset und limit. Werkzeugergebnisse enthalten dasselbe seiten-/bereichsweise JSON im MCP-Textinhalt; vollständige Downloads folgen dem oben beschriebenen Bytebereichsvertrag. Es gibt kein Werkzeug für Asset-Änderungen, Ausführung, Verwaltung, Synchronisierung, Backup-Dumps, Suche/Modellausführung oder Fortschreiben eines OTP-Zählers. Lesezugriffe speichern vor Rückgabe der Ausgabe signierte Zustellungsabsichten; Audit-/Speicherfehler verweigern sie.

Das gewöhnliche mcp serve --grant-file bleibt unverändert und schließt private Inhalte, Dateien und das Lesen von Zugangsdaten weiterhin aus. Keiner der Server übernimmt sudo des Terminals. Von Center verwaltete Speicher verweigern unbeaufsichtigte Registrierung, Start und Nutzung. HTTP/WebSocket, Relay-RPC, mobile FFI/Share und WebUI können unbeaufsichtigte Berechtigungen nicht nutzen. Remote-Flags, Verbindungsoptionen aus der Umgebung und gespeicherte Remote-Standards werden von diesen Befehlen zurückgewiesen, obwohl globale Remote-Optionen in der Hilfe des Programms erscheinen.

Base64 für Zugangsdaten ist Kodierung, keine Verschlüsselung. Unbeaufsichtigtes MCP gibt dem empfangenden Client absichtlich Geheimnis-Bytes. KI-Anbieter, Transkripte, Werkzeugprotokolle, Caches oder Plugins können den kodierten Wert oder dekodierten Klartext speichern oder übertragen. Der schreibgeschützte Geltungsbereich verhindert Änderungen über diese Berechtigung, nicht die Offenlegung oder anderweitige Verwendung eines kopierten Geheimnisses. Verwenden Sie synthetische Geheimnisse für Tests.

Sperren, fortsetzen, widerrufen und deaktivieren

memories --home /absolute/private/home lock

Manuelles Sperren löscht Schlüssel und verhindert unbeaufsichtigten Start dauerhaft über Neustarts hinweg. Entsperren mit Passwort allein setzt ihn nicht fort. Schlagen dauerhafte Schreibvorgänge fehl, meldet Sperren einen Fehler; nehmen Sie auf einem nicht beschreibbaren Gerät nicht an, dass die Unterbindung gespeichert wurde. Bereinigung bei Inaktivität oder Herunterfahren ist keine manuelle Unterbindung.

Verwaltung erfordert Entsperren mit Passwort und sudo in Ihrem lokalen Terminal:

memories --home /absolute/private/home unlock
memories --home /absolute/private/home sudo
memories --home /absolute/private/home unattended status
memories --home /absolute/private/home unattended resume

Status meldet aktiviert/unterbunden und Freigabe-IDs, keine Tokens. Starten Sie nach dem Fortsetzen den Daemon ohne manuelles Sperren neu, um wieder den Zustand nur mit Schlüsseln zu erreichen. So entfernen Sie einen Client oder deaktivieren sämtlichen unbeaufsichtigten Zugriff:

memories --home /absolute/private/home unattended revoke GRANT_ID
memories --home /absolute/private/home unattended disable

Widerruf ist dauerhaft und idempotent. Deaktivieren entzieht die Berechtigung dauerhaft und widerruft jede Freigabe vor der Backend-Bereinigung. Das bloße Löschen einer Client-Datei ist kein Widerruf, wenn jemand sie kopiert hat. Sperren, Widerrufen und Deaktivieren können bereits ausgelieferten Klartext nicht zurückholen; rotieren Sie offengelegte Zugangsdaten bei ihrem Anbieter.

Grenzen von Wiederherstellung und Validierung

Unbeaufsichtigte Wrapper-/Berechtigungsdatensätze sind nicht in logischen exportierten Backups, Gerätekopplung oder Tresorsynchronisierung enthalten. Die Wiederherstellung eines logischen Backups stellt die unbeaufsichtigte Registrierung nicht wieder her. Eine vollständige rohe Kopie der lokalen Datenbank enthält weiterhin die Hilfstabelle, und Dateisystem-Backups können Client-Dateien oder Verwahrungsmaterial kopieren. Prozesse desselben Kontos, Betriebssystemadministratoren, Prozessspeicher, das Zurücksetzen des gesamten Geräts und sicheres Löschen bleiben außerhalb der Garantien in SECURITY.md.

Die implementierten Adapter decken Windows DPAPI, macOS Keychain, Linux Secret Service und owner-file-Verwahrung ab. Die Linux-End-to-End-Validierung verwendet owner-file-Verwahrung mit dem echten Daemon, einer privaten Erinnerung, einer ursprünglichen Binärdatei und synthetischen UTF-8-Zugangsdaten. Sie deckt Neustart nur mit Schlüsseln, CLI/stdin-stdout-MCP, Verweigerung gewöhnlicher/Cloud-/RAG-Zugriffe, manuelle Unterbindung über Neustarts hinweg, Fortsetzen, Widerruf und Deaktivierung ab. Linux-Verwahrungstests und eine isolierte D-Bus-Protokoll-Fixture liefern zusätzliche Abdeckung; die Fixture ist jedoch kein Test mit einem aktiven Desktop-Schlüsselbund.

Native Windows/macOS-Roundtrips, natives Verhalten bei Sperrung/Genehmigungsbedarf und ohne Oberfläche sowie die Prüfung eines aktiven Desktop-Schlüsselbunds bleiben Freigabekriterien für Releases. Zielübergreifende Builds oder Tests der Fehlerübersetzung belegen diese nativen Verhaltensweisen nicht. Eine unabhängige Prüfung steht aus; bestandene Tests sind kein Sicherheitsaudit. Siehe die CLI-Implementierungshinweise und den Core-Vertrag für gezielte Validierungsbefehle.