What Diwall does not do behind your back

You are considering giving a browser to an agent. That is a serious decision. Here is what it rests on, with the file that enforces it each time — not our word.

Diwall never puts your credentials in a terminal

They never pass through your shell, your command history, or Diwall’s logs.

→ lib/repertoire_chiffre.py — how a credential actually reaches a form →

The same rule holds inside evaluer: a scenario action carrying a plaintext value on a password/secret-looking field is rejected — action_secret_en_clair, checked before the scenario ever reaches Playwright — not audited after the fact.

What Diwall itself writes is redacted by default. Return values, URLs and error messages that pass through stdout or the operations log are neutralized unless you explicitly ask otherwise (--no-filtre-evaluer, which the JSON output then reports on itself). Captures and proof archives are written 600/700, not left at whatever default the filesystem hands out.

→ lib/sanitisation.py

What this does not cover: the agent driving Diwall has its own access to your machine. If you give it a terminal, it can read your mounted directory like any other file. Diwall protects the path it controls — not the one you open beside it.

What Diwall reports, it does not decide

pret_a_agir: false means a friction was perceived — a WAF signature, a session drift, a navigation cap. It does not mean I refuse to run. Diwall reports what it noticed and hands you the decision.

The WAF detection is keyword-based and can be wrong. It is reported as a count, never raised as an exception that halts execution, and --ignorer-waf is there for when you have checked and it was wrong.

The distinction matters more than it looks. A tool that moralises about access becomes a tool you work around, and a tool people work around stops reporting anything at all.

The agent does not decide what it does

Every click, every keystroke, every navigation is a line you wrote in a scenario file. Diwall executes that list; it does not invent it and does not extend it.

→ scenarios/schema.json

What leaves your machine, and by which path

Captures, analyses and results are written to the disk where Diwall runs. What leaves that disk depends on who reads them.

The model driving Diwall reads everything it is shown. The capture, the accessibility tree, the Set-of-Mark labels and the evaluer results are Diwall’s output, written for that model to read. If the model is hosted, its provider receives whatever the page displayed: data, names, the tables of an authenticated interface. For an interface whose content must not leave your machine, the model driving Diwall has to be local as well — any model that can run a shell command can drive it.

Two things never reach that model. Credentials are resolved in the memory of the Playwright process at the moment they are typed — never in the scenario, the shell, the log or a URL. Sensitive-looking fields (type password, or a name or id that suggests a password, token, secret or one-time code) are blurred in every capture, and their values are removed from the accessibility tree. If either step fails, the JSON output says so (capture_masquage_echoue, a11y_redaction_echouee), and an accessibility tree that could not be redacted is withheld rather than sent as is.

→ lib/repertoire_chiffre.py, shot.py

Diwall itself sends something out in three cases, each behind a flag you set.

• diwall-shot --llm claude sends the capture used by cliquer_visuel to a remote API. It is never the default, and the anthropic Python module it needs is not installed with Diwall: you add it yourself. Without the flag, image analysis runs on your machine — --llm local, an Ollama instance on localhost, with qwen3-vl:2b.
• diwall-watch --llm claude (since 1.24.2) sends both captures it compares, the reference and the current one, to the same API, reduced to 1568 pixels on their longest side. Same conditions: never the default, same module to add yourself.
• diwall-watch --ntfy-url sends a notification when it detects a change: the watched URL and a description of the change, both redacted, to the ntfy server you named.

→ lib/vision.py, watch.py

You can review everything afterwards

Each run produces a capture per step and a dated log. What the agent saw, you can look at — not only the summary it gives you.

→ journal.py

And what Diwall does not claim

It is no more careful than the scenario you give it. A badly written scenario does real damage, at machine speed.