Guest lease-claim scoping (PR #131) is advisory only — needs per-sandbox claim tokens

[haasonsaas]

Problem

PR #131 added sandbox_id/kinds filters to ClaimLeaseRequest so a well-behaved guest agent only claims work for its own sandbox. The API enforces these filters, but the guest agent and the worker it runs under still share one worker-scoped bearer token — the filters are request parameters the guest agent chooses to send, not a credential the server can independently verify. A compromised or malicious guest can simply omit sandbox_id/kinds and claim any lease its shared token's capabilities allow, including run_command jobs destined for a different sandbox.

The doc comment on ClaimLeaseRequest in sandboxwich-core says this plainly:

This is advisory, not a security boundary: the guest agent and the worker it runs under share one worker-scoped token ... The server-side filtering below narrows the default blast radius of a well-behaved agent claiming the wrong job; it does not stop an adversarial one. A real fix needs per-sandbox claim tokens.

Evidence

• crates/sandboxwich-core/src/lib.rs:1710-1723 — ClaimLeaseRequest struct and doc comment stating the advisory-only scoping and calling for per-sandbox claim tokens.
• docs/capabilities.md:16 — "Guest-agent lease claim scoping" is listed as Experimental for this reason.
• PR feat(api,agent): scope guest lease claims to sandbox and job kind #131 description explicitly flags this as "a good follow-up issue."

Suggested approach

Mint a distinct, sandbox-bound claim credential (separate from the existing sandbox-bound guest token used for other guest routes) that the API can verify server-side when a lease claim comes in, rather than trusting a client-supplied sandbox_id/kinds filter. This closes the gap between "guest agent claims only its own sandbox's work by convention" and "guest agent claims only its own sandbox's work because the server enforces it."

Relationship to ROADMAP promotion gates

Blocks the Authorization promotion gate in ROADMAP.md, which requires "Tenant, operator, worker, and guest principals have separate credentials and route permissions" — today the guest and worker principals share a credential for lease claiming.

Status

A PR addressing this is in progress today (parallel effort) — not yet numbered.

[haasonsaas]

Scope update after implementation (PR #163): the server-side enforcement (per-sandbox guest tokens: minting, auth resolution, claim/renew/complete/fail scoping, revocation, expiry) already landed on main in 5abdbd3, so this issue's premise was partly stale. The live gaps were operational: sandboxwich-agent never obtained a guest token (all guest-facing calls used the shared worker-wide token, so the enforcement path was never exercised), and the doc comments still described the scoping as advisory-only. PR #163 addresses both plus the missing cross-sandbox contract test.

Remaining after #163 (suggest keeping this issue open until done):

• Kubernetes provider minting/mounting a guest token into sandbox pods instead of the shared worker token (touches provider.rs — deferred to avoid the documented hot-file merge hazard)
• Automatic guest-token rotation before expiry in long-running daemons (currently mints once at startup, default TTL 3600s)