Le profil de l'opérateur et la liste de sites

Un seul fichier JSON, relu à chaque appel : les sites que le serveur peut lire et sur lesquels il peut agir, ceux où chaque changement vous demande d'abord, le navigateur, et les plafonds. Rien dedans ne peut désactiver une confirmation.

Où il se trouve

~/.config/mcp-server-diwall-browser/profile.json, ou sous $XDG_CONFIG_HOME quand elle est définie, ou le chemin absolu donné dans MCP_DIWALL_BROWSER_PROFILE. Le fichier est à vous d’écrire, en mode 600, dans un répertoire en mode 700 ; sinon le serveur le refuse et son message donne le chmod à lancer. Il ne contient aucun secret. Le serveur le relit à chaque appel : un changement prend effet sans redémarrage.

Une clé hors du schéma est refusée. Une clé qui configurerait les actions verrouillées, comme payment ou deletion, est refusée avec redlist_in_profile : seul le code décide de ce qui attend votre confirmation.

Les trois listes de sites

"allowed_origins": ["https://account.example.invalid", "https://*.shop.example.invalid"],
"confirm_each_change": ["https://account.example.invalid"],
"local_model_origins": []

allowed_origins : les sites que le serveur lit et sur lesquels il agit, 200 au plus. Avec strict, de toute autre page le modèle reçoit l’origine et rien d’autre.
confirm_each_change : les sites où chaque clic, remplissage, choix dans une liste, touche Entrée et boîte de dialogue acceptée demande votre confirmation, et pas seulement les paiements, les suppressions et les changements de secret.
local_model_origins : les origines exactes que vous voulez voir traitées par un modèle qui tourne sur cette machine. Le serveur les liste dans status et ne fait rien de plus, puisqu’il n’a aucun moyen de savoir où tourne un modèle.

Une entrée est une origine (schéma, hôte, port) ou un joker de sous-domaine. https://*.shop.example.invalid couvre tous les sous-domaines de shop.example.invalid, d’un niveau ou davantage, avec le même schéma et le même port, et pas shop.example.invalid lui-même, qui demande une entrée à part. Un joker seul (*), sans schéma, à une autre place que le premier libellé, ou devant un nom d’un seul niveau (https://*.test) rend le profil invalide. Un joker élargit la lecture et l’action, jamais la saisie : un identifiant n’est saisi que sur l’origine exacte que nomme son fichier (Identifiants). Le serveur ne tient aucune liste des suffixes publics ; un joker devant un suffixe de deux niveaux, comme celui qui se termine par co.uk, est à vous d’éviter.

La politique d’origines

La liste de sites borne ce que le modèle lit et sur quoi il agit, jamais où il navigue. La clé origin_policy dit ce que fait le serveur d’une origine que la liste ne contient pas. Vous la choisissez dans le profil ; le serveur la relit à chaque appel, et aucun outil du modèle ne la change.

strict (le défaut, et ce que fait un profil sans la clé) : l’origine est refusée, et le modèle reçoit l’origine et rien d’autre.
discovery : le serveur vous interroge dans une fenêtre, une fois par origine : Refuser (la réponse par défaut), Cette séance (lue jusqu’à l’arrêt du serveur, rien n’est écrit) ou Ajouter à la liste (cette origine exacte est écrite dans allowed_origins). Cinq fenêtres au plus par processus du serveur ; un refus, ou l’absence de réponse en 90 secondes, n’est pas redemandé.
open : tout site public est lu et agi, et ce que le modèle lit part chez son fournisseur. C’est la politique la plus libre et la plus risquée, et le choix vous appartient. localhost, les noms qui finissent par .local et les adresses non routables sur Internet restent sur la liste.

Dans les trois politiques, un paiement, une suppression et un changement de secret gardent leur fenêtre de confirmation, et un identifiant n’est saisi que sur l’origine exacte que nomme son fichier. Pour ajouter une origine à la main, mettez-la dans allowed_origins. Le détail est dans la section 5 du guide de l’opérateur.

Le reste du fichier

secrets_dir et secrets_crypt_dir : l’endroit où le répertoire chiffré est ouvert, et l’endroit où ses fichiers chiffrés sont gardés. Avec le second, status distingue un répertoire fermé d’un répertoire jamais créé.
browser : family (chrome, chromium ou brave), profile_dir (le --user-data-dir du profil dédié) et debug_port (le --remote-debugging-port, 9222 par défaut).
limits : au moins 250 ms entre deux actions, 200 actions et 50 pages par processus du serveur, par défaut. Une action compte quand elle démarre, une fois le serveur rattaché ; relancer le client remet les comptes à zéro.
declarations : deux affirmations de votre part, que le modèle du client tourne sur cette machine et que le client ne répond jamais seul à une confirmation. Le serveur ne peut pas les vérifier et les montre dans status telles qu’écrites. Seule la seconde lui permet de demander une confirmation par le client, quand aucune fenêtre ne peut être affichée.

Un exemple complet, que le serveur accepte tel quel, est dans la section 5 du guide de l’opérateur.

Ce que laisse un changement des listes

Quiconque peut écrire le fichier peut y ajouter un site, et le serveur ne peut pas l’empêcher. Il laisse une trace : quand l’une des trois listes, ou origin_policy, diffère de ce que le serveur a vu à l’appel précédent, ou, à son premier appel, de ce que la dernière exécution a enregistré, une ligne profile_changed va au journal dans le répertoire chiffré et status porte le changement dans server.notices :

"notices": ["profile_changed : allowed_origins +https://shop.example.invalid"]

C’est une détection après coup : elle n’ajoute aucune confirmation, et quiconque a un shell sous votre compte peut aussi modifier le journal. Après une session où un client doté d’un shell était connecté, lisez le journal :

grep profile_changed \
  ~/Vaults/Main/mcp-server-diwall-browser/journal/operations.jsonl