[Fix] Job tokens can no longer reassign their run's acting user

[mrubens]

Vulnerability (flagged in PR #80 review)

The job-scoped cloudJobs.update tRPC mutation (packages/sdk/src/server/routers/cloud-jobs.ts) accepted actingUserId: z.string().optional(). A run-scoped job token is held by the sandbox runtime, and resolveActorScopedUserContext (packages/sdk/src/server/lib/auth/resolve-actor-scoped-user.ts) — plus the MCP proxy's resolveActingUserId — prefer the run's live task_runs.actingUserId when resolving the effective user for actor-scoped credential routes (userApiKeys.getDecryptedKey, user-scoped mcpConnections).

Confused-deputy chain: a compromised/misbehaving sandbox → cloudJobs.update({ id, actingUserId: <victim> }) with its own job token → then userApiKeys.getDecryptedKey (or a user-scoped MCP connection lookup) resolves to the victim → reads the victim's decrypted API keys / connections.

Fix

Removed actingUserId from the job-token-writable update input schema. zod strips the field, so a job-token caller can never persist it. Acting-user reassignment remains available only to the trusted server-side writers, which write task_runs directly and are unchanged:

• web steer — apps/web/src/trpc/commands/sandbox-session/index.ts (sets it from the authenticated web user)
• follow-up delivery — apps/api/src/handlers/tasks/sendMessageToTask.ts syncActingUserIdAfterDelivery

The read-side model (PR #80) is unchanged: actingUserId is still the live-trusted attribution source and is still preferred over the token's mint-time userId.

Worker audit

The only worker path that wrote actingUserId through the job token was the SDK helper syncActingUserId (packages/sdk/src/cloud-jobs.ts), called during actor-scoped turn preparation to switch the actor to a queued follow-up sender before delivering that sender's turn. No code in apps/worker/src puts actingUserId into an update call directly.

This switch is a legitimate relay of a server-provided queued-sender id, but it cannot be safely preserved:

• the sandbox and worker host share one run-scoped token (createJobToken mints userId = actingUserId, no worker-vs-sandbox principal distinction), so the legit switch is indistinguishable from the attack at the server;
• the queued-message store is Redis, destructive-on-read (getCommunicationMessages deletes the key), so there is no durable record of pending senders to validate a target against.

Per the reviewer's stated intent ("the worker should never choose its own acting user"), syncActingUserId is now reconcile-only: it observes the server-authoritative value and never writes, logging a warning if the requested actor diverges.

Trade-off (reported, not a leak): in a rare multi-user snapshot-resume batch, a later sender's turn now runs under the earlier, server-set actor instead of switching mid-batch. Both are legitimate participants of the same run who already share its actor-scoped surface turn-by-turn, so this is a within-run mis-attribution, not a cross-user credential leak. A future server-authoritative per-turn actor sync could restore precise switching if desired.

Other job-token-writable fields audited

While in the update schema I checked the remaining fields for confused-deputy potential:

• taskId (worth a follow-up): writable by a job token but not sent by any worker update call (all taskId: references in the worker are reads). Re-pointing a run to another task would corrupt run→task attribution/visibility, but taskId does not feed resolveActorScopedUserContext, so it is a data-integrity risk, strictly lesser than credential theft. Left as-is to keep this PR scoped to the credential vector; recommend removing it from the job-token input in a follow-up.
• status / result / taskPhase / sleepAt: legitimate worker-written runtime/output fields, no auth/attribution role.
• Sibling job-token mutations (done, updateRuntimeState, stampMilestone, touchCloudJobHeartbeat): none write auth/attribution fields.

Tests

• packages/sdk/src/server/routers/cloud-jobs.test.ts: a job-token update carrying actingUserId is stripped (never reaches updateCloudJob); legitimate status/result fields still persist.
• packages/sdk/src/server/routers/user-api-keys.test.ts: end-to-end shape — a job token cannot pivot getDecryptedKey to a victim; the lookup is scoped only to the persisted (legitimate) actingUserId.
• packages/sdk/src/cloud-jobs.test.ts: syncActingUserId never writes on divergence and warns.
• Existing web-steer / follow-up-sync / worker actor-scoped tests still pass.

Validation

pnpm format + full pnpm check (lint, check-types, test, knip) all pass.

[roomote-roomote]

2 issues outstanding. See task

• High: Do not execute a mismatched sender's queued prompt as the server actor (apps/worker/src/run-task/prepare-actor-scoped-turn.ts:124-162, with callers such as apps/worker/src/run-task/polling/slack.ts:206-243). The distinct mismatch result detects the problem, but follow-server still delivers user B's prompt text while actor-scoped MCP and API-key routes resolve user A; replacing the prompt's userId metadata with A does not change who supplied the instructions. Concurrent pre-queue writes, the intentionally non-fatal inbound sync, and a failed direct delivery after its pre-delivery write all make this reachable. Block/requeue mismatched content or perform a trusted, per-message actor switch immediately before delivery.
• Medium: Restore or remove the now-unreachable updated contract (packages/sdk/src/cloud-jobs.ts:28,131-139). syncActingUserId can now return only unchanged or not-found, so the worker's syncResult === 'updated' branch and its only call to syncRuntimeGitAuthor are dead; commits after an actor switch can retain the previous user's git identity. Make git-author synchronization follow server-authoritative actor changes and update the worker test, or remove the dead contract and explicitly accept the behavior change.
• Medium: Retry git-author synchronization after a transient failure (apps/worker/src/run-task/prepare-actor-scoped-turn.ts:145-159). The catch logs syncRuntimeGitAuthor failures but still calls onActorSynced, advancing lastPreparedActorUserId; the next turn therefore receives unchanged and never retries the idempotent git-author update, so subsequent commits can retain the previous actor's identity for the rest of the run. Advance the local actor marker only after the author sync succeeds, or track the failed sync separately for retry.
• High: Keep skipped Slack question answers recoverable (apps/worker/src/run-task/polling/slack.ts:134-138). submitPendingSlackRequestUserInputAnswer atomically queues the answer and marks the pending request submitted; dropping that queued answer on an actor mismatch leaves the harness waiting, while the notice's suggested resend is rejected as “already received” by the Slack webhook. Perform the trusted actor sync before accepting the answer, or restore the pending request to a state in which the sender can answer again instead of permanently discarding it.
• High: Keep skipped Linear question answers recoverable (apps/worker/src/run-task/polling/linear.ts:104-108). The Linear webhook queues the answer and marks the request submitted, so dropping the queued answer on mismatch leaves the harness waiting and every later answer is rejected by the submitted guard. Perform the trusted actor sync before accepting the answer, or reset the pending request before asking the sender to resend.
• Medium: Retry a partially written git identity even after the actor switches back (apps/worker/src/run-task/prepare-actor-scoped-turn.ts:175-193). syncRuntimeGitAuthor writes user.email before user.name; if the second command fails during A→B and the server switches back to A before another turn, the marker still equals A, reconciliation returns unchanged, and the mixed B-email/A-name configuration is never repaired. Track a failed author sync independently of actor identity or update both fields atomically.
• High: Do not roll the actor back after an ambiguous sandbox RPC failure (apps/api/src/handlers/tasks/sendMessageToTask.ts:815-822,972-979). A timeout or lost response can occur after the sandbox accepted B's native-steered prompt; the unconditional B→A rollback then lets B's injected instructions continue while live actor-scoped credential routes resolve A. Roll back only deterministic pre-accept failures, or add an acceptance/idempotency protocol and revalidate native-steered turns before execution.
• High: Do not treat Redis answer claims as atomic with a PostgreSQL transaction (packages/db/src/lib/acting-user.ts:44-69). operation() commits the Redis queue/submitted side effects before the actor update and PostgreSQL commit; if the update or commit fails, the answer is permanently marked submitted while the actor stays unchanged, and the worker requeues the mismatch forever. Use a recoverable cross-store protocol such as compensation or an outbox instead of relying on the row lock as atomicity.
• Medium: Make the Linear answer claim reject concurrent losers (apps/api/src/handlers/linear/index.ts:586-603). — dismissed: every valid event in a Linear agent session derives userId from that session's fixed agentSession.creator, so concurrent claimants cannot race with different actors; duplicate same-actor answers do not create the reported actor mismatch.