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.