glas-harness/docs/bounded-execution-agent-executor.md

# 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.