daemon (remote): client-declared tenant is trusted when the auth hook does not attest tenantId (header on aux routes, meta on RPC) #2095

Severity: security (tenant isolation). Surface: shared remote/proxy daemon HTTP, not the local loopback CLI.

Problem

When an auth hook is configured but does not attest a tenantId, the daemon falls back to a client-declared tenant as identity. This is exploitable in shared-token multi-tenant deployments: a holder of one valid token can present any tenant id and act as that tenant on the auxiliary routes (diagnostics, uploads, downloadable artifacts) and on /rpc.

The audit framed this as an aux-routes-only header issue. It is broader: the RPC path has the identical hole via the request body.

Evidence (at 848c6ea733)

• Aux routes trust the header: authorizeAuxiliaryHttpRequest returns authResult.tenantId ?? tenantId, where tenantId is normalizeTenantId(x-agent-device-tenant) read straight off the request. The comment there documents this as intentional parity with RPC.
• RPC trusts the body: toDaemonRequest copies params.meta verbatim — including a client-supplied meta.tenantId — into daemonRequest.meta. On the RPC path the hook result only overrides tenant when the hook returns one; when the hook is silent, the client's meta.tenantId survives untouched into handleRequest.
• The existing diagnostics test only checks a mismatched header against an attesting hook; it does not cover impersonation with the same valid token when the hook does not attest.

So header (aux) and body-meta (RPC) are two faces of one posture: client-declared tenant is trusted whenever the hook is silent.

Why this is the keystone

The audit's "tenant-less artifacts in every inventory" item was correctly rejected as by-design (canReadArtifact: no tenantId ⇒ public bucket). But that means isolation depends entirely on tenantId being trustworthy — which is exactly what this issue is about. Fix this and that rejection stays sound; leave it and the public-bucket model is impersonable.

Design: one trusted-tenant seam, one posture

Both paths currently derive tenant ad hoc. Introduce a single resolver used by both the RPC handler and authorizeAuxiliaryHttpRequest:

resolveTrustedTenant({ hookConfigured, hookAttestedTenant, clientDeclaredTenant }) -> tenantId | undefined

Posture (fail-closed when a hook exists):

• Hook configured, hook attests tenant → use the attested tenant (unchanged).
• Hook configured, hook silent → ignore the client-declared tenant. A deployment that installed a hook opted into attestation; a request that needs a tenant and has no attested one is unauthorized (or runs untenanted per the public-bucket rules — pick one and pin it in a test).
• No hook configured (loopback / trusted single-tenant) → keep the client-declared tenant as today. This preserves the current local/dev behavior.
• Optional escape hatch for deployments that legitimately derive tenant outside the hook: an explicit daemon config flag (e.g. trustClientDeclaredTenant: true) that re-enables the fallback deliberately, so it is a choice and not a default.

Refactor required

1. Extract resolveTrustedTenant and call it from both authorizeAuxiliaryHttpRequest and the /rpc handler.
2. Stop treating body meta.tenantId as identity: in toDaemonRequest, carry a client-declared tenant separately (or strip it from meta) so the posture resolver is the only place that promotes a client value to identity. Today the value slips in through meta before any policy runs.
3. Flip the intentional-fallback comment to describe the new posture.

Acceptance criteria

• With a hook configured that returns { ok: true } (no tenantId): a request presenting x-agent-device-tenant: victim (aux) and a request presenting meta.tenantId: victim (RPC), both with a valid token, are refused / untenanted — not run as victim. New tests on both surfaces.
• With no hook configured: existing loopback behavior unchanged (regression test).
• The trustClientDeclaredTenant opt-in (if added) restores the old behavior and is documented in the auth-hook docs and CHANGELOG as a deliberate multi-tenant footgun.

Effort / risk

S (few lines + tests), LOW risk — but it is a behavior change for any deployment that runs a hook and relies on the header/body fallback today. Call it out in the auth-hook docs and CHANGELOG.

Blocks #S1PLACEHOLDER (the provider-session ownership check is only meaningful once leaseScope.tenantId is trustworthy).