@CryogenicPlanetchecks…fix/proxy-user-api-key-bypass-org-allowlist-executeproxy → master1 files · +9 −3review: @rohanprabhureview: @sarthakreview: @acsrujanreview: @anshugarg15updated 4d agoFollow-up to #10590. That PR special-cased user API keys (uak_*) only in the direct /tools/execute/proxy handler. But the SDK/CLI composio proxy command actually goes through the tool-router session path (POST /api/v3.1/tool_router/session/{id}/proxy_execute), which calls executeProxy() directly and hit the deeper org-allowlist gate (isProxyExecuteAllowedForOrg / LD proxyExecuteOrgAllowlist) → 403 ExternalProxy_OrgNotAllowed ("Proxy execute is not enabled for this API key…").
This moves the user-key bypass into executeProxy() — the single chokepoint all proxy surfaces funnel through (direct, tool-router session, internal) — so a uak_ key is approved everywhere. Implemented right next to the existing trusted-internal-scoped-key bypass, reading apiKeyType === 'user' from the same request-context auth method.
All other SSRF controls (registrable-domain origin check, SSRF validation + DNS pinning, no-open-proxy) still apply unchanged.
pnpm check-types passes clean on master with this change. Traced the failing path from the CLI (ts/packages/cli/src/commands/proxy.cmd.ts → client.toolRouter.session.proxyExecute) to the server handler (tool_router/session/[session_id]/proxy_execute.ts → proxyExecuteForSessionRPC → executeProxy) and confirmed the 403 message string originates at executeProxy/index.ts:502, which is the gate this change bypasses for user keys.
🤖 Generated with Claude Code