glas-harness/history/2026-10-24-agent-session-identity-and-tool-boundary-assessment.md

Assessment: session-scoped agent identity and tool boundary

Date: 2026-10-24. Status: assessment only; no harness behavior changed. Request: net-kingdom hub message 14ea093a (standard service-identity-privilege_v0.1.md draft-3 SI-14, SI-15; companion section 7; SEC-DSM DSM-AGENT-002, -007, -008). key-cape assesses the issuing side in parallel. Plan: workplans/GLAS-WP-0018-session-agent-identity-and-tool-boundary.md.

Verdict

Feasible for the sessions glas-harness actually launches, in three separable steps. Glas is the right place for (a) carriage and (b) attribution, and for declaring (c); enforcement of (c) belongs to the rein, the sandbox and the token's audience. Glas cannot control a person's interactive Claude Code, Codex or Grok terminal session; for those it can only offer a shared contract and helper. Be explicit in the declaration that such sessions stay at SI-14's "holds the person's reach".

What exists today

Evidence is from src/glas_harness/{gateway,contract,hub}.py, the reins and profiles.

Need	Today	Gap
Actor type	ExecutionRequest.actor is adm/agt/atm, validated into sand-boxer Consumer; run_id is the request id. Docs state attribution is "not caller authentication".	A label, not an IAM principal. No principal_type=agent, no act.sub, no token.
Per-run identity	request_id (uuid) names the run and the sandbox consumer. Sandbox is per run and destroyed after.	Nothing binds request_id to an issuer-signed subject.
Credentials	credential_route_refs are labels passed to the sandbox owner (SandboxExecRequest.credential_route_refs), applied only to the workload command; secret-looking values are refused in profiles.	A KeyCape agent token is a new credential class with no route. The owner (sand-boxer / credential owner) must deliver it.
Tool boundary	Profile field tool_profile (for example green-commit-only) is passed as --tool-profile to rein-aharness / rein-openweights; the rein enforces it. Sandbox profile (bwrap, egress deny-by-default) bounds filesystem and network.	Glas does not know what a tool profile allows; it is an opaque string. No Glas-side check that the profile is narrower than the person's reach. Tool profiles do not name credentials or hub write scope.
Attribution record	ExecutionEvidence (actor, project, profile, rein, model, sandbox_id, commit_sha, timings, tool_events_count and completeness, refs to assignment/role/duty). Posted to the Hub as a gateway_run progress event with hard-coded author: agt-glas-harness.	Aggregate per run, not per state-changing action. Tool events are complete only when the rein streams them, parsed after the subprocess ends; unavailable for open-weight. No on_behalf_of, no session identity, no evidence location/hash. Hub author is unauthenticated free text (the declared net-kingdom gap). Hub post is best-effort, no outbox.
Commit trailers	Commits inside the sandbox are made by the rein.	Glas neither requires nor verifies Assistant, Assistant-Session, Assistant-Process.
Limits	Token, turn, USD budgets and per-command timeout passed to reins that support them.	No aggregate wall clock; nothing ties session lifetime to token lifetime (60 minute ceiling).
Readiness	No committed profile is ready.	Any identity feature starts on unverified/blocked profiles, so it cannot yet claim production assurance.

(a) Per-session agent identity

Design sketch (not implemented):

1. Add an optional identity section to ExecutionRequest / profile: required on_behalf_of (the person, becomes act.sub), mode (agent), requested ttl_seconds (profile ceiling 3600), audience list.
2. Before rein.start_session, the gateway asks a pluggable AgentIdentityIssuer (interface in Glas, KeyCape-backed adapter) for a token whose subject is the run (agent:<request_id>), principal_type=agent, act.sub the person, expiry min(profile ttl, remaining timeout, 3600). Fail closed: no token, no identity-requiring profile run (new failure_stage such as identity).
3. Deliver the token to the workload as a sandbox credential (stdin or a sandbox-owner delivery route), never in argv, task file, evidence, Hub detail or logs; never in the person's password safe (SI-9). Redaction of the token pattern in tool output before it enters ToolResult.
4. Carry through tool calls: Glas passes a token handle; the rein presents it to downstream services. Reins must accept and use it (a rein change), and downstream services must verify it (their change). Glas alone can only guarantee issue, scoped delivery, expiry and revocation at teardown.
5. Teardown: discard the token, request revocation if the issuer supports it (dependency on key-cape), record issuance and revocation in evidence by token id (jti) only.

Dependencies: KeyCape agent-token issuance (principal_type claim, act, 60 minute cap, per-run subject, revocation) and the sandbox/credential owner for delivery. Without them Glas can stub the issuer for tests but must not claim identity.

Effort: contract + issuer interface + fail-closed gateway wiring + tests, roughly 3 to 5 days in Glas; real issuer adapter and delivery 3 to 5 days after key-cape and sand-boxer land their sides; rein acceptance of the token is a separate rein-aharness task.

(b) Attribution per state-changing action

Today's evidence answers "which run, profile, model, sandbox, outcome, commit". SI-15 also wants "on whose authority" and "where the evidence is kept" per action.

Proposal:

• Add identity_ref (subject, act.sub, token jti, issuer, expiry; no token), session_id and authority_ref (assignment/role/duty already exist as refs) to ExecutionEvidence.
• Define an ActionRecord (actor, on_behalf_of, session, operation, target, result, evidence_location, evidence_sha256, timestamp). Glas emits one per commit it can see and one per tool event when the rein streams events; where the rein cannot report, the record says events_completeness: unavailable rather than implying coverage. This honestly keeps SI-15's "reconstructable" as partial.
• Write a hashed evidence receipt file (sandbox-external, append-only location chosen with the custodian), and put its hash in the Hub event. Use a durable local outbox so the Hub post is not best-effort only.
• Require and verify commit trailers (Assistant, Assistant-Session, Assistant-Process) on sandbox commits; refuse or flag a run whose commits lack them.
• Replace the hard-coded Hub author with the run identity once the Hub can authenticate it; until then record it in detail and keep the gap stated.

Effort: 4 to 6 days. Risk: tool-event coverage is rein-dependent; ActionRecords from parsed streams are after-the-fact, not tamper-evident, unless the receipt is stored outside the agent's reach.

(c) Session-scoped tool boundary

Facts: the boundary today is sandbox profile (filesystem, egress) plus rein tool_profile. For a harness-launched session the person's ambient reach is already mostly absent: the run is in a bwrap sandbox with a deny-by-default network and no person credentials; credential_route_refs: [] in the local profile. The risk SI-14 names is the interactive terminal session, which Glas does not launch.

Proposal for launched sessions:

• Make the boundary declarative and checkable: a boundary block in the profile (tool profile id and hash, sandbox profile, egress hosts, credential route refs, hub write scope, max lifetime) that Glas records in evidence, and a catalog validation that every profile with a non-empty credential route or identity requirement names a non-default tool profile.
• Resolve tool_profile against a rein-published manifest (rein-aharness profiles.py registry) so Glas can state, not just forward, what the tools can reach, and fail when the rein reports a different profile than requested (the rein already echoes tool_profile in its result; Glas currently does not compare).
• Effective authority statement: tools reachable x token audience x sandbox egress. Emit it per run as evidence (DSM-AGENT-008).
• Bind token audience and scopes to the boundary, so a tool that is callable but outside the boundary is rejected by the downstream service, not by the model's good manners (companion section 7 rule 2).

Effort: 3 to 4 days in Glas plus a rein-aharness manifest export. Risk: a tool profile that allows shell lets the agent reach whatever the sandbox network and credentials allow; the sandbox, not the profile name, is the real boundary.

Claude Code, Codex and Grok

Session type	Glas control	Identity	Tool boundary	Attribution
Harness-launched via rein-aharness (Claude CLI inside sandbox)	Full outer lifecycle	Feasible once KeyCape + delivery exist; rein must present the token	Sandbox + tool profile, enforced by sand-boxer and the rein	Run evidence now; per-action partial via streamed events
Harness-launched via rein-openweights	Full outer lifecycle	Same, if the rein accepts it	Same	Weaker: tool events unavailable
Interactive Claude Code in a person's terminal	None	Could use a helper script that requests a token at session start; person must run it	Claude Code permission and hook settings, set by the person; not Glas	Commit trailers and hub notes only
Codex	No rein exists. Needs a new rein (CLI adapter) to be harness-launched	As above once a rein exists	Codex sandbox/approval modes, outside Glas	Trailers already used by Codex commits (Assistant: codex)
Grok	No rein exists	Same	Not known; unverified	Not verified

Honest scope: Glas can only deliver SI-14 conformance for sessions it launches. For the rest it can publish a small, provider-neutral "session identity contract" (what a session must obtain, carry, record) that the person or a wrapper implements. Whether Codex and Grok expose hooks sufficient for per-call attribution is not established here and needs checking before any claim.

Risks and open questions

1. Token in the sandbox: the agent can read and exfiltrate its own token within its lifetime. Mitigation is narrow audience, short TTL, egress deny-by-default, revocation at teardown; it is not eliminated.
2. Identity over a still-blocked runtime: all profiles are non-ready, so this should be built behind unverified profiles and proven in isolation first.
3. Evidence that the agent can write is not independent evidence; the receipt location must be outside the sandbox and the verifier independent (SI-15 step 4).
4. Hub authorship stays unauthenticated until the Hub changes (owner: state-hub).
5. actor values adm/agt/atm predate this standard; mapping agt to IAM principal_type agent needs an agreed table with net-kingdom.
6. Scope creep: Glas must not become an identity provider or policy engine; it carries and records. Authorization stays with flex-auth and the issuer.

Recommended order

1. Contract fields and evidence (b, identity_ref placeholders) and the boundary declaration with tool-profile echo check (c): no external dependency, immediately useful.
2. Issuer interface with a test double; fail-closed gateway path.
3. Real KeyCape adapter and delivery once key-cape and sand-boxer agree.
4. Interactive-session contract and a Codex/Grok feasibility note.