Research 039: the login shell's execute is the first case, and narrow read tools must come first or approvals become noise
mesh/merge-gate pass: the change touches no module of the mesh's graph
mesh/repo-check pass: its merge-check.sh passed
mesh/delivery delivered

This commit is contained in:
jochen
2026-10-09 00:01:47 +02:00
parent c31a76cac5
commit ccb54450ea
@@ -44,10 +44,26 @@ agent on any node could run a command there as an account that can (ADR 0259 §8
ADR 0266, hq pull request 225, not yet merged). Once agents run without root, **the tools are the
boundary**, and a tool that can do lasting harm needs a person behind each call.
## The first case: the login shell's `execute`
The operator decided on 2026-10-08 that the login shell seat's verb `execute` is the first tool to
need approval, on every node, once the mark exists. It runs any command it is given as the node's
operator account, and that account has passwordless sudo, so one call is root on that node. Until the
mark exists, the verb is removed on the control-node.
The calls it carried (about 300 across the four nodes, counted on 2026-10-08): about a third ran
something with sudo; most of the rest were reads, such as reading or searching a file, listing
containers, asking a unit's state, listing sockets, or looking up a user or a name.
So **narrow read tools must replace the common reads first**, each a tool of the module that owns the
area. Otherwise nearly every approval asked is for a read, and the operator learns to approve without
reading, which makes the approval worth nothing.
## Candidates seen on 2026-10-08
| Tool or verb | Why a person |
|---|---|
| the login shell's `execute` | decided: see above |
| the new zfs module's `zfs_snapshot` | a snapshot of the media library holds its space; on a scratch dataset it does not matter |
| `mesh-controller.push` | sends builds to nodes outside a walk |
| the bus's upgrade, `mesh-controller.bus upgrade` | already a step a person starts ([ADR 0236](../../02-DECISIONS/0236-a-build-is-judged-on-its-first-machine-and-put-back-by-something-other-than-itself-and-so-it-rolls-out-unattended.md) rule 6); today "a person" is whoever calls it |
@@ -82,9 +98,12 @@ boundary**, and a tool that can do lasting harm needs a person behind each call.
with a handle the agent calls again?
6. **The answer before a verified channel exists.** The desk is `acknowledge` only; is the controller's
terminal the place, and how does it prove a person there?
7. **Audit.** Is a warranted call a hand-act, and where is a declined or expired one recorded?
7. **Per call, or per session or time window.** For a tool called as often as `execute`, does each
call need its own approval, or may one approval cover one agent session, or a stated span of time?
A wider approval is less noise and more reach for whoever holds it.
8. **Audit.** Is a warranted call a hand-act, and where is a declined or expired one recorded?
## How it will be checked
Nothing measured yet. The first evidence to gather: how many tools and verbs in the catalogue act on
Measured so far: only the login shell's calls, above. The next evidence to gather: how many tools and verbs in the catalogue act on
data or on other nodes, and of those, how many are guarded by anything but the caller's restraint.