Ce que Diwall ne fait pas dans votre dos

Vous envisagez de donner un navigateur à un agent. C’est une décision sérieuse. Voici ce sur quoi elle repose, avec le fichier qui le garantit à chaque fois — pas notre parole.

Diwall ne met jamais vos identifiants dans un terminal

Ils ne passent jamais par votre shell, votre historique de commandes ou les journaux de Diwall.

→ lib/repertoire_chiffre.py — comment un identifiant arrive vraiment dans un formulaire →

La même règle vaut à l’intérieur d’evaluer : une action de scénario qui porte une valeur en clair sur un champ ressemblant à password/secret est rejetée — action_secret_en_clair, vérifié avant que le scénario n’atteigne Playwright, jamais audité après coup.

Ce que Diwall écrit lui-même est neutralisé par défaut. Les valeurs de retour, les URL et les messages d’erreur qui transitent par la sortie standard ou le journal des opérations sont expurgés, sauf demande explicite contraire (--no-filtre-evaluer, que la sortie JSON signale alors elle-même). Les captures et les archives de preuves sont écrites en 600/700, jamais laissées aux permissions par défaut du système de fichiers.

→ lib/sanitisation.py

Ce que cela ne couvre pas : l’agent qui pilote Diwall a, lui, ses propres accès à votre machine. Si vous lui donnez un terminal, il peut lire votre répertoire monté comme n’importe quel fichier. Diwall protège le chemin qu’il contrôle — pas celui que vous ouvrez à côté.

Ce que Diwall signale, il n'en décide pas

pret_a_agir: false signifie une friction a été perçue — une signature de WAF, une dérive de session, un plafond de navigation. Cela ne signifie pas je refuse de m’exécuter. Diwall signale ce qu’il a remarqué et vous laisse la décision.

La détection de WAF repose sur des mots-clés et peut se tromper. Elle est rapportée sous forme de compteur, jamais levée comme une exception qui interrompt l’exécution, et --ignorer-waf existe pour le jour où vous avez vérifié et où elle avait tort.

La distinction compte plus qu’il n’y paraît. Un outil qui fait la morale sur l’accès devient un outil que l’on contourne, et un outil que l’on contourne cesse de signaler quoi que ce soit.

L'agent ne décide pas de ce qu'il fait

Chaque clic, chaque saisie, chaque navigation est une ligne que vous avez écrite dans un fichier de scénario. Diwall exécute cette liste ; il ne l’invente pas et ne la complète pas.

→ scenarios/schema.json

Ce qui quitte votre machine, et par où

Les captures, les analyses, les résultats sont écrits sur le disque où Diwall tourne. Ce qui quitte ce disque dépend de qui les lit.

Le modèle qui pilote Diwall lit tout ce qu’on lui montre. La capture, l’arbre d’accessibilité, les libellés Set-of-Mark et les résultats d’evaluer sont la sortie de Diwall, écrite pour que ce modèle la lise. S’il est hébergé, son fournisseur reçoit ce que la page affichait : des données, des noms, les tableaux d’une interface authentifiée. Pour une interface dont le contenu ne doit pas quitter votre machine, le modèle qui pilote Diwall doit être local lui aussi — tout modèle capable de lancer une commande shell peut le piloter.

Deux choses n’atteignent jamais ce modèle. Les identifiants sont résolus dans la mémoire du processus Playwright, à l’instant de la frappe — jamais dans le scénario, le shell, le journal ni une URL. Les champs qui semblent sensibles (type password, ou un nom ou un identifiant qui évoque un mot de passe, un jeton, un secret ou un code à usage unique) sont floutés dans chaque capture, et leurs valeurs sont retirées de l’arbre d’accessibilité. Si l’une de ces deux étapes échoue, la sortie JSON le dit (capture_masquage_echoue, a11y_redaction_echouee), et un arbre d’accessibilité qui n’a pas pu être expurgé est retenu plutôt qu’envoyé tel quel.

→ lib/repertoire_chiffre.py, shot.py

Diwall lui-même fait sortir quelque chose dans trois cas, chacun derrière une option que vous activez.

• diwall-shot --llm claude envoie à une API distante la capture qu’utilise cliquer_visuel. Ce n’est jamais le défaut, et le module Python anthropic dont il a besoin n’est pas installé avec Diwall : c’est vous qui l’ajoutez. Sans cette option, l’analyse d’image se fait sur votre machine — --llm local, une instance Ollama sur localhost, avec qwen3-vl:2b.
• diwall-watch --llm claude (depuis la 1.24.2) envoie à la même API les deux captures qu’il compare, la référence et l’actuelle, réduites à 1 568 pixels sur leur plus grand côté. Mêmes conditions : jamais le défaut, même module à ajouter vous-même.
• diwall-watch --ntfy-url envoie une notification quand il détecte un changement : l’URL surveillée et une description du changement, toutes deux expurgées, au serveur ntfy que vous avez indiqué.

→ lib/vision.py, watch.py

Vous pouvez tout revoir après coup

Chaque exécution produit une capture par étape et un journal daté. Ce que l’agent a vu, vous pouvez le regarder — pas seulement le résumé qu’il vous en fait.

→ journal.py

Et pour finir, ce que Diwall ne prétend pas

Il n'est pas plus prudent que le scénario que vous lui donnez. Un scénario mal écrit fait des dégâts réels, à la vitesse d'une machine.