CLI de bureau et MCP sans surveillance

L'accès sans surveillance est une capacité explicite, exclusivement locale et en lecture seule, pour des coffres actifs sélectionnés. Il inclut les mémoires/cartes ordinaires et privées, les fichiers binaires originaux, l'historique des révisions et les identifiants en clair explicitement demandés. Activez-le uniquement si vous confiez au client destinataire chaque ressource et chaque secret de ces coffres. Ce n'est ni une autorité MCP ordinaire ni une session sudo permanente.

Inscrire et sélectionner la garde des clés

Démarrez le démon dans un terminal distinct, en utilisant le même répertoire personnel absolu dédié pour chaque commande. Initialisez d'abord normalement votre bibliothèque et créez ses coffres. Les chemins ci-dessous sont des exemples ; utilisez votre propre répertoire privé sur chaque plateforme.

memories --home /absolute/private/home daemon

Choisissez explicitement un backend dans votre terminal interactif :

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

L'inscription avertit que les clients peuvent lire les mots de passe stockés, vous demande de saisir ENABLE, puis demande votre mot de passe local pour déverrouiller, et à nouveau pour sudo. Cette configuration du consentement et du mot de passe est nécessaire une seule fois à l'inscription, pas à chaque lecture sans surveillance. Ne transmettez pas les mots de passe par arguments ou variables d'environnement. La gestion ultérieure exige toujours un terminal ordinaire déverrouillé par mot de passe et autorisé par sudo.

Par exemple, le choix délibéré de l'option moins protégée utilise unattended enable --backend owner-file. Il n'existe aucun repli automatique lorsqu'un backend natif est indisponible ou nécessite une interaction. Secret Service repose sur la frontière locale compte système/D-Bus ; le client ne peut pas contrôler les comportements d'interface arbitraires propres au fournisseur. Le backend se choisit uniquement à la création. Ne modifiez pas ses métadonnées pour en changer. La garde lie le chemin canonique du stockage et l'identité actuelle de l'en-tête ; la copier vers un autre stockage ne constitue donc pas une inscription.

L'enveloppe par mot de passe reste disponible pour le déverrouillage normal et la restauration. L'inscription ajoute une enveloppe distincte de la clé maîtresse dont la clé d'enveloppement reste hors de la base de données ; elle ne remplace pas l'authentification par mot de passe.

Émettre un fichier client

Dans le même terminal autorisé, émettez une autorisation pour les coffres nécessaires au client :

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.

Le répertoire parent doit déjà exister et être privé au propriétaire. L'émission publie le fichier atomiquement sans écraser un fichier existant et refuse les propriétés, permissions ou liens non sûrs. En cas d'échec de publication, elle tente de révoquer la nouvelle autorisation et signale tout échec de révocation. La sortie contient l'ID de l'autorisation et le chemin du fichier, jamais le jeton bearer. Conservez l'ID pour la révocation.

Ce fichier client est distinct des fichiers d'autorisation MCP ordinaires. Protégez-le comme un mot de passe ; n'affichez pas son contenu, ne le commitez pas et ne placez pas son jeton dans les arguments de commande. Les lectures CLI/MCP exigent une sélection explicite par --client-file et le même répertoire personnel/stockage. La portée est read_only_all_assets pour les coffres sélectionnés, et non une autorisation par ressource ou limitée au contenu ordinaire. Chaque lecture revérifie l'appartenance actuelle de l'appareil local et la portée des coffres.

Démarrage et lectures

Redémarrez le démon après l'inscription pour utiliser le démarrage avec les seules clés. Arrêtez-le sans exécuter memories lock, puis redémarrez-le avec le même répertoire personnel. Un démarrage réussi charge les clés sans surveillance mais indique normalement unlocked: false : les lectures ordinaires, les écritures, sudo, les opérations cloud et RAG restent verrouillés jusqu'au déverrouillage par mot de passe. Un échec du backend laisse les clés sans surveillance non chargées, sans repli sur le mot de passe ni sur l'authentification ambiante.

Sous Unix, une terminaison forcée peut laisser service.sock dans le répertoire personnel. Ne supprimez ce socket périmé qu'après avoir confirmé l'arrêt de son démon.

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

La liste renvoie les métadonnées des ressources, y compris les ressources privées, fichiers et identifiants, mais pas leur contenu ; les marqueurs de suppression sont omis. L'historique renvoie les métadonnées des révisions, dont les indicateurs de tête/suppression/quarantaine, pas le contenu des identifiants. Une ressource actuelle en conflit exige une révision correspondante explicite. Les révisions historiques et supprimées peuvent être lues explicitement, mais celles en quarantaine sont refusées. Cette voie lit l'historique des coffres actifs, pas les archives de restauration.

read renvoie les octets JSON Content d'une mémoire/carte ou les octets originaux d'un fichier. Il refuse les identifiants. credential-bytes n'accepte que les identifiants et renvoie les octets UTF-8 du contenu stocké, y compris les valeurs historiques explicitement sélectionnées. Cela n'ajoute pas le stockage arbitraire d'identifiants binaires. Les références de secrets des cartes protégées et du wiki restent des références ; demandez séparément l'identifiant référencé si nécessaire.

Reconstituer l'intégralité des octets

Les réponses utilisent data contenant du base64url sans remplissage, avec offset commençant à zéro, total en octets, next (null lorsque terminé), la revision effective et encoding (content_json ou raw_bytes). Pour récupérer le contenu complet :

1. Demandez le décalage 0 avec --limit entre 1 et 65536 octets (65536 par défaut).
2. Décodez séparément le data de chaque réponse en base64url sans remplissage.
3. Utilisez next comme prochain --offset et fixez la première révision renvoyée avec --revision REVISION_ID pour chaque requête suivante.
4. Continuez jusqu'à ce que next soit null, puis concaténez les plages d'octets décodées dans l'ordre. Décodez ensuite seulement UTF-8/JSON si nécessaire ; une plage peut couper un caractère UTF-8.

Par exemple, une plage suivante utilise :

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

Utilisez les mêmes options avec credential-bytes. Ne concaténez pas les chaînes encodées et ne considérez pas la première plage comme la ressource complète. La liste et l'historique utilisent --offset et --limit entre 1 et 100 éléments (100 par défaut) ; leurs pages reflètent l'état actuel, pas un instantané, donc les changements entre requêtes peuvent modifier l'ordre et les totaux.

Connecter un client d'IA via MCP

Configurez une commande de serveur stdio distincte avec le même répertoire personnel et le même fichier client :

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

Il n'annonce que unattended_list, unattended_history, unattended_read et unattended_credential_bytes. Les arguments des outils sont vault, asset (sauf pour la liste), revision facultatif (lectures d'octets), offset et limit. Les résultats contiennent le même JSON paginé/par plages dans le contenu texte MCP ; les téléchargements complets suivent le contrat de plages d'octets ci-dessus. Aucun outil ne permet la modification des ressources, l'exécution, l'administration, la synchronisation, l'export de sauvegarde, la recherche/l'exécution de modèles ou l'avancement du compteur OTP. Les lectures enregistrent des intentions de livraison signées avant de renvoyer la sortie ; les échecs d'audit/stockage entraînent un refus.

Le serveur ordinaire mcp serve --grant-file reste inchangé et exclut toujours le contenu privé, les fichiers et la lecture des identifiants. Aucun des deux serveurs n'hérite du sudo du terminal. Les stockages gérés par Center refusent l'inscription, le démarrage et l'utilisation sans surveillance. HTTP/WebSocket, RPC par relais, FFI mobile/partage et WebUI ne peuvent pas utiliser l'autorité sans surveillance. Ces commandes refusent les options distantes, les options de connexion par environnement et les paramètres distants par défaut enregistrés, même si les options distantes globales apparaissent dans l'aide de l'exécutable.

Le base64 des identifiants est un encodage, pas un chiffrement. Le MCP sans surveillance fournit délibérément au client destinataire les octets secrets. Les fournisseurs d'IA, transcriptions, journaux d'outils, caches ou plugins peuvent conserver ou transmettre la valeur encodée ou le texte en clair décodé. La portée en lecture seule empêche les modifications par cette capacité, pas la divulgation ni l'utilisation ailleurs d'un secret copié. Utilisez des secrets synthétiques pour les tests.

Verrouiller, reprendre, révoquer et désactiver

memories --home /absolute/private/home lock

Le verrouillage manuel efface les clés et inhibe durablement le démarrage sans surveillance, même après redémarrage. Le seul déverrouillage par mot de passe ne le rétablit pas. Si les écritures durables échouent, le verrouillage renvoie une erreur ; ne supposez pas que l'inhibition a persisté sur un appareil non inscriptible. Le nettoyage à l'inactivité/à l'arrêt n'est pas une inhibition manuelle.

La gestion exige le déverrouillage par mot de passe et sudo dans votre terminal local :

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

L'état indique l'activation/inhibition et les ID d'autorisation, pas les jetons. Après reprise, redémarrez le démon sans verrouillage manuel pour revenir à l'état avec les seules clés. Pour supprimer un client ou désactiver tout accès sans surveillance :

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

La révocation est durable et idempotente. La désactivation retire durablement l'autorité et révoque toutes les autorisations avant le nettoyage du backend. Supprimer seulement un fichier client ne constitue pas une révocation si quelqu'un l'a copié. Le verrouillage, la révocation et la désactivation ne peuvent pas rappeler le texte en clair déjà livré ; renouvelez les identifiants exposés auprès de leur fournisseur.

Limites de restauration et de validation

Les enregistrements d'enveloppe/d'autorité sans surveillance ne sont pas inclus dans les sauvegardes logiques exportées, l'association d'appareils ou la synchronisation des coffres. Restaurer une sauvegarde logique ne restaure pas l'inscription sans surveillance. Une copie brute complète de la base locale inclut toujours la table auxiliaire, et les sauvegardes du système de fichiers peuvent copier les fichiers clients ou le matériel de garde. Les processus du même compte, les administrateurs système, la mémoire des processus, le retour arrière de tout l'appareil et l'effacement sécurisé restent hors des garanties de SECURITY.md.

Les adaptateurs implémentés couvrent Windows DPAPI, le trousseau macOS, Linux Secret Service et la garde owner-file. La validation Linux de bout en bout utilise la garde owner-file avec le véritable démon, une mémoire privée, un fichier binaire original et un identifiant UTF-8 synthétique. Elle couvre le redémarrage avec les seules clés, la CLI/le MCP par entrée-sortie standard, le refus des accès ordinaires/cloud/RAG, l'inhibition manuelle persistant après redémarrage, la reprise, la révocation et la désactivation. Les tests de garde Linux et un dispositif isolé de protocole D-Bus apportent une couverture supplémentaire, mais ce dispositif n'est pas un test de trousseau de bureau réel.

Les allers-retours natifs Windows/macOS, les comportements natifs en état verrouillé, avec approbation requise et sans interface, ainsi que la vérification d'un trousseau de bureau réel restent des contrôles de publication. Les compilations croisées ou les tests de traduction d'erreurs n'établissent pas ces comportements natifs. La revue indépendante est en attente ; la réussite des tests n'est pas un audit de sécurité. Consultez les notes d'implémentation CLI et le contrat du cœur pour les commandes de validation ciblées.