Authorize remote modules with bearer proofs

docs/architecture.md

@@ -271,8 +271,11 @@ as resource-scoped auth operations and rejects trust-mutation capabilities such
 as `auth.delegate`, `auth.revoke`, and `node.enroll`. Bearer challenge/proof
 commands derive deterministic BLAKE3 keyed responses from the bearer secret,
 resource, nonce, and requested capabilities, then verify them against active
-resource-scoped bearer grants. The daemon does not yet store payload key
-material, encrypt resource data, or distribute key envelopes.
+resource-scoped bearer grants. Remote resource operations can carry optional
+bearer proofs over the protected Iroh control path; a valid proof authorizes
+only the requested resource capability and does not create node trust. The daemon
+does not yet store payload key material, encrypt resource data, distribute key
+envelopes, or separate public bearer ids from private bearer tokens.
 
 ## Multi-User Direction
 

docs/roadmap.md

@@ -223,8 +223,12 @@ resource-scoped capability decisions.
   - `[x]` `geth secret bearer challenge/prove/verify` exercises
     resource-scoped bearer challenge-response proofs.
   - `[x]` Tests verify valid bearer proofs and capability-scoped proof denial.
-  - `[ ]` Future completion wires bearer proof verification into remote module
-    authorization paths.
+  - `[x]` Remote module authorization paths accept optional bearer proofs for
+    the requested resource capability without granting node identity.
+  - `[x]` Tests verify remote CAS fetch succeeds through a bearer proof before
+    the caller has a node grant.
+  - `[ ]` Future completion avoids sending bearer secret identifiers as proof
+    material by separating public bearer ids from private bearer tokens.
 
 - `[~]` SSH certificate and revocation lifecycle.
   Acceptance criteria: