diff --git a/WORK-RECORDS.md b/WORK-RECORDS.md index e56f9b5..c98634f 100644 --- a/WORK-RECORDS.md +++ b/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 | diff --git a/docs/bounded-execution-agent-executor.md b/docs/bounded-execution-agent-executor.md new file mode 100644 index 0000000..2573014 --- /dev/null +++ b/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. diff --git a/workplans/GLAS-WP-0018-session-agent-identity-and-tool-boundary.md b/workplans/GLAS-WP-0018-session-agent-identity-and-tool-boundary.md index e0b9a20..f16ef73 100644 --- a/workplans/GLAS-WP-0018-session-agent-identity-and-tool-boundary.md +++ b/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.