Say that the modules' own checks are the only line before root, since sudo grants the account everything

modules/mounts/README.md

@@ -167,3 +167,10 @@ service manager's tools do; a refusal by sudo is said as one.
 | `node-mounts.mount` | a | mount one share or source now |
 | `node-mounts.unmount` | a | release one now; its automount stays armed |
 | `node-mounts.adopt` | a | take over one hand-written fstab line, as above |
+
+## Root acts and sudo
+
+The tools run as the operator account and act as root through `sudo -n`. The `sudo` module grants that
+account every command, so **this module's code is the only line** between a tool call and root: each act
+checks again what it may touch before it runs a command, and a test holds each check. Narrowing what sudo
+grants the account to the commands these modules need is a separate decision, not made here.

modules/nfs-server/README.md

@@ -102,3 +102,10 @@ shares go. A plain restart, a push or a shutdown leaves the config file in place
   own dataset.
 - **Exports that are not the mesh's** (`/etc/exports`, a ZFS dataset's `sharenfs`) are left as found and
   shown, until `adopt` takes one over on a person's word.
+
+## Root acts and sudo
+
+The tools run as the operator account and act as root through `sudo -n`. The `sudo` module grants that
+account every command, so **this module's code is the only line** between a tool call and root: each act
+checks again what it may touch before it runs a command, and a test holds each check. Narrowing what sudo
+grants the account to the commands these modules need is a separate decision, not made here.