GLAS-WP-0018: answer NK-WP-0056-T02 on agent executors; add T07 admission binding

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 994874@bnt-lap001
Assistant-Session: 6017c416-d619-47eb-bd1a-f670a02d7d87

WORK-RECORDS.md

@@ -97,6 +97,7 @@
 | task | GLAS-WP-0018-T04 | wait | — | workplans/GLAS-WP-0018-session-agent-identity-and-tool-boundary.md |
 | task | GLAS-WP-0018-T05 | todo | — | workplans/GLAS-WP-0018-session-agent-identity-and-tool-boundary.md |
 | task | GLAS-WP-0018-T06 | todo | — | workplans/GLAS-WP-0018-session-agent-identity-and-tool-boundary.md |
+| task | GLAS-WP-0018-T07 | wait | — | workplans/GLAS-WP-0018-session-agent-identity-and-tool-boundary.md |
 | intake | GLAS-IN-0001 | done | blue | docs/intakes/residuals.md |
 | intake | GLAS-IN-0002 | todo | red | docs/intakes/residuals.md |
 | intake | GLAS-IN-0003 | todo | green | docs/intakes/residuals.md |

docs/bounded-execution-agent-executor.md

@@ -0,0 +1,98 @@
+# Agent executors under Bounded Execution Admission
+
+Status: owner answer (proposal). Date: 2026-10-31.
+Request: NetKingdom NK-WP-0056-T02, hub message `8713a17b`, request document
+`net-kingdom/docs/proposals/2026-10-31-nk56-t02-owner-requests.md`.
+Standard: `net-kingdom/canon/standards/bounded-execution-admission_v0.1.md`
+(proposed), rule BEA-4, with SI-14 in `service-identity-privilege_v0.1.md`.
+Work: GLAS-WP-0018 (proposed, not yet founder-approved).
+
+Nothing here changes harness behaviour. The founder decision (hub `6d1adce9`)
+stands: the pilot executor is a non-agent runtime written by net-kingdom.
+
+## Short answers
+
+1. **When can a harness-launched agent present as `AGENT` with a verifiable
+   "harness-launched" assertion?** Not before GLAS-WP-0018-T04, and no date can
+   be given. T04 waits on key-cape (agent-token issuance with `act`, revocation)
+   and on the sand-boxer or credential owner (token delivery into the sandbox).
+   GLAS-WP-0018 is still `proposed` and needs founder approval first.
+   T01 to T03 have no external dependency. They would give a *recorded*
+   harness-launched claim in Glas evidence, and that claim is self-reported by
+   the gateway. It is enough for audit correlation. It is not enough for an
+   admission validator, which must not trust a claim the executor's own launcher
+   wrote. Verification needs an issuer signature, and Glas must not be the
+   issuer.
+2. **Does glas-harness want the agent-executor path later?** Yes, as a proposal
+   for the founder, limited to what Glas already does: launching the
+   session, binding it to a declared profile and boundary, requesting the
+   per-run identity, and recording evidence. Admission carriage, policy
+   decisions, credential lanes and receipt custody stay with approval-engine,
+   access-engine, secrets-engine and audit-core.
+
+## Current evidence (what exists today)
+
+- `ExecutionRequest` and `ExecutionEvidence` (`src/glas_harness/contract.py`)
+  carry `actor` (`adm`/`agt`/`atm`), profile ref, rein, sandbox profile and id,
+  `tool_profile`, and outcome. There is no identity reference, session id,
+  on-behalf-of or admission reference. Nothing is signed.
+- The tool profile is passed to the rein as an argument, and the rein's echo
+  is recorded. A mismatch does not fail the run yet (GLAS-WP-0018-T02).
+- Glas launches sessions only through reins (rein-aharness, rein-openweights)
+  inside sand-boxer sandboxes. Interactive sessions that Glas does not launch
+  stay at SI-14's "holds the person's reach" and can never satisfy BEA-4
+  through Glas.
+
+## What a verifiable assertion must carry
+
+The assertion is the per-run agent token from the identity issuer (key-cape),
+minted on the gateway's request after profile resolution and sandbox creation.
+Glas records a reference to it, never the token itself.
+
+Issuer-signed claims (key-cape owns the format, so this is a request):
+
+| Claim | Content | Why the admission needs it |
+| --- | --- | --- |
+| `sub` | Agent principal, `principal_type: AGENT` | BEA-4 executor class |
+| `act.sub` | Glas gateway service identity (the launcher) | Shows the session was launched by the harness, not by a person's terminal |
+| `launch_mode` | `harness` | The explicit harness-launched assertion |
+| `glas_run` | `request_id`, `session_id` | Joins token, evidence and receipts |
+| `glas_profile` | Profile ref `id@version` and its digest | Fixes what was launched |
+| `glas_boundary` | `sandbox_profile`, `tool_profile`, tool-profile manifest digest | Lets the validator check the session's reach against the admission plan |
+| `admission` | `admission_id`, `admission_digest` | Binds the session to one admission (BEA target) |
+| `on_behalf_of` | The requesting principal | SI-15 accountability |
+| `jti`, `iat`, `exp` | `exp` no later than the admission window or the run timeout, whichever comes first | Single use and time-bounded |
+
+Glas evidence additions (GLAS-WP-0018 T01, T02, T05, and the new T07):
+
+- `identity_ref`: issuer, `sub`, `act.sub`, `jti`, `exp`. No token.
+- `session_id`, `on_behalf_of`, `admission_ref {admission_id, admission_digest}`.
+- `boundary`: the declared sandbox and tool profile, the tool-profile manifest
+  digest, and the rein's echoed tool profile. The run fails on a mismatch.
+- A receipt location and sha256 stored outside the sandbox, so that audit-core
+  or the mediator can check the evidence independently.
+
+## How a validator or approval mediator would verify
+
+1. Verify the token's signature against the issuer, and check `jti`/`exp`.
+2. Require `principal_type: AGENT`, `launch_mode: harness`, and an `act.sub`
+   from the registered Glas gateway identity.
+3. Require that `admission` equals the admission under evaluation.
+4. Compare `glas_boundary` with the plan the admission allows. The tool-profile
+   manifest digest must be one the admission (or its policy) names.
+5. After the run, check the Glas evidence receipt digest and that its
+   `identity_ref.jti` and `admission_ref` match.
+
+Glas fails closed at step zero. It refuses to start the session when an
+admission-bound profile has no identity issuer, no admission reference, or a
+default tool profile.
+
+## Open items
+
+- Founder approval of GLAS-WP-0018 (still `proposed`).
+- key-cape: agent tokens with `act`, custom claims as above, revocation.
+- sand-boxer or the credential owner: delivery of the token into the sandbox
+  without argv, task file or logs.
+- rein-aharness: export the tool-profile manifest and its digest.
+- net-kingdom: the `actor` to IAM `principal_type` mapping, and whether BEA
+  will name the claim set above or a provider-neutral form of it.

workplans/GLAS-WP-0018-session-agent-identity-and-tool-boundary.md

@@ -9,7 +9,7 @@ flavor: implementation
 owner: claude
 topic_slug: session-agent-identity-tool-boundary
 created: "2026-10-24"
-updated: "2026-10-24"
+updated: "2026-10-31"
 state_hub_workstream_id: "4805066a-58f6-51c5-bc99-eabe9cd719d0"
 ---
 
@@ -106,3 +106,21 @@ Publish a provider-neutral session identity contract for sessions Glas does not
 launch. Check what hooks Codex and Grok offer; decide whether a rein for either
 is worth building. Record that interactive sessions remain at SI-14 "person's
 reach" until then.
+
+## Bounded-execution admission binding for agent executors
+
+```task
+id: GLAS-WP-0018-T07
+status: wait
+priority: low
+```
+
+Answer to net-kingdom NK-WP-0056-T02 (message 8713a17b):
+`docs/bounded-execution-agent-executor.md`. Carry `admission_ref`
+(`admission_id`, `admission_digest`) in the request and evidence, ask the issuer
+to put the harness-launch, profile, boundary and admission claims into the
+per-run token, and refuse an admission-bound run that lacks an issuer, an
+admission reference or a non-default tool profile. Glas does not validate the
+admission itself. Waits on T01 to T04 and on Bounded Execution Admission v0.1
+moving past `proposed`. The pilot executor is not an agent (founder decision
+6d1adce9), so this is not on the pilot path.