PR Custody

fix(apollo): bind playground keys to session users

@kaavee315checks n/achecks…codex/fix-playground-key-authorization-flaw → master4 files · +141 −2review: @sohamganatrareview: @anshugarg15updated 2d ago

GitHub

▸Description· 1 comment

Motivation

Prevent INTERNAL_PLAYGROUND project API keys from accessing or operating on existing tool-router sessions belonging to other users within the same project, closing an authorization gap introduced by adding the playground key kind.

Description

Add a shared guard assertPlaygroundKeyCanAccessSession that returns 403 when an INTERNAL_PLAYGROUND key's metadata.userId does not match the target session's userId (apps/apollo/src/lib/toolRouterV2/features/session/authorization.ts).
Enforce the guard after the project-scoped session lookup for tool listing and tool execution handlers so playground keys cannot use another session's ID (apps/apollo/src/lib/toolRouterV2/features/tools/listToolsRPC.ts and apps/apollo/src/lib/toolRouterV2/features/execution/executeForSessionRPC.ts).
Add unit tests that cover non-playground keys, matching playground-key/session pairs, and mismatched playground-key/session pairs (apps/apollo/src/lib/toolRouterV2/features/session/authorization.test.ts).

Testing

Ran package build for helper library with pnpm --dir packages/lib build, which succeeded.
Verified formatting with pnpm --dir apps/apollo exec oxfmt --check against the modified files, which passed.
Attempted to run the new unit test via SKIP_VALIDATION=true pnpm --dir apps/apollo with-env vitest run src/lib/toolRouterV2/features/session/authorization.test.ts, but test execution was blocked by missing generated Prisma client and environment requirements (.prisma client not found and env validation), preventing full runtime verification in this checkout.
Attempts to generate Prisma client (pnpm --dir packages/db db:generate:ci) failed due to a remote Prisma engine download error (HTTP 403), and repository-wide check-types/lint runs were blocked by existing workspace type/lint issues unrelated to this fix.

Codex Task

@CryogenicPlanet2d ago

The playground-key → user binding is already enforced at session creation (session.ts — body.user_id must equal metadata.userId for INTERNAL_PLAYGROUND keys, added in #10452), so any session created via the playground flow already belongs to the key's bound user. We likely don't need to re-check on list-tools/execute.

The only scenario this guards is a playground key replaying a session_id from a session created by a different (e.g. DEVELOPER) key in the same project — but the playground key only ever lives in a dashboard member's vault, and that member already has full project access, so it isn't an escalation.

loading diff…