fix: execute local reins through the sandbox owner

Assistant: codex
Assistant-Model: gpt-6-astra
Assistant-Session: 01a0726e-5232-73f2-aaca-2c05ceb62efb

docs/evidence/GLAS-WP-0005-owner-boundary-2026-09-05.md

@@ -0,0 +1,68 @@
+# GLAS-WP-0005 sandbox owner boundary proof
+
+Date: 2026-09-05. Sand-boxer revision:
+`b6655d88590e03820675719d6dd574e5f5a9f82e`.
+
+The Glas gateway now binds same-host execution to the creating manager's
+`execute` operation. Each request repeats the exact actor/project identity and
+resolved request id as `consumer.run_id`, forwards the selected profile's
+value-free credential route references, and caps execution at the profile
+timeout. Local descriptors without that process-local binding fail closed.
+There is no direct `nsenter` or host task-file write path.
+
+Generated task files travel through bounded stdin to an exclusive mode-0600
+writer inside the sandbox's `.git` directory. Removal uses owner execution.
+Timeouts, owner refusals, and truncated output fail closed; gateway teardown
+still runs when session initialization fails.
+
+## Live non-secret proof
+
+Command: `.venv/bin/python scripts/prove-owner-boundary.py`.
+
+This reproducible fixture exercises the real gateway, real sand-boxer manager,
+real bwrap owner broker, and the rein-aharness adapter's session setup, commit
+verification, and cleanup. Its dispatch is a deterministic Python/Git probe,
+not an installed agent CLI or model call. Only the fixture's in-memory profile
+is made unverified; the committed profile catalog is unchanged.
+
+Successful sandbox: `e3907e55`, workspace `/tmp/sandboxer-bwrap/e3907e55`.
+
+- Source checkout was absent inside the sandbox; a source write was refused.
+- The sandbox copy was readable and accepted a new committed file.
+- Host source sentinel and Git HEAD remained unchanged; no proof file appeared
+  in the source checkout.
+- Actor `agt`, project `glas-boundary-proof`, and run id
+  `glas-wp-0005-boundary-proof` matched inside the child environment.
+- Task content arrived through stdin and its file mode was `0600`.
+- Only `lo` appeared in the network namespace.
+- The generated task was removed before teardown. Final state was `destroyed`
+  and the workspace was absent.
+
+An initial fixture run (`78be8886`) encountered a Python quoting error in the
+probe itself. It failed during dispatch, removed its generated task, preserved
+the source, and destroyed the workspace. The fixture quoting was corrected
+before the successful run above.
+
+## Validation and limits
+
+`.venv/bin/python -m pytest tests/ -q`: **81 passed**. Coverage includes exact
+create/exec identity with supplied and generated request ids, unchanged route
+references, timeout caps, stdin-only task content, no local subprocess or host
+file fallback, and teardown on owner refusal, timeout, truncation, and writer
+failure. Both concrete adapters' session and cleanup tests pass.
+
+`.venv/bin/glas-harness profiles`: catalog validation passed. Both local
+profiles remain **blocked**; the remote profile remains **unverified**.
+
+This closes the boundary-hardening acceptance in GLAS-WP-0005. It does not
+prove an installed production rein runtime, credential delivery, required
+outbound connectivity, or the remote SSH runtime. Registered residual
+`GLAS-IN-0002` (`01a02b76-f020-7d60-a3ce-12a34c13ebce`) remains live for the
+local production requirements and was refreshed before workplan closure.
+Sand-boxer owns runtime/credential/egress provision; Glas owns the subsequent
+real-rein acceptance and profile readiness review. The prior GLAS-WP-0004
+lifecycle-only evidence remains explicitly withdrawn as an isolation proof.
+
+Earlier T03 package and T04 Forgejo CI evidence remains historical; this
+session validates the changed code locally and does not claim a new published
+Forgejo run.