@sohambasu963draftchecks…fix/mcp-bearer-api-key-fallback → master2 files · +141 −1updated 9h agoProduction customers using Anthropic Managed Agents are fully blocked: that client can only inject credentials via Authorization: Bearer (vault credentials) and cannot set the custom x-api-key header. Since the May 26 hardening (cbf7bb8c14) made MCP auth unconditional, these clients have no way to authenticate at all — the dashboard's require_mcp_api_key toggle they tried to use is a dead control (loaded by validateMCPServerById, read by nothing).
pr_Rb4Jiskb5obe, waiting ~10 daysOne-line behavior change: withMcpAuth.ts now passes allowBearerApiKeyFallback: true to getProjectAuthInfoFromCredentials.
The helper already implements Bearer API-key auth — same getAuthInfoFromApiKey validation (key format, kind/route gating, IP allowlist, expiry) and same-project enforcement as the x-api-key path — and true is its default on every non-MCP route. The false came in with the authMiddleware file-move refactor preserving pre-refactor behavior; no rationale was recorded.
This does not weaken the May 26 hardening. Every MCP request still requires a valid project API key or JWT; only the accepted header location is extended (matching how OpenAI/Stripe-style APIs take keys).
@-less on purpose (draft) — needs sign-off from the hardening author before marking ready. Specific question: any reason MCP routes must reject Bearer ak_… while /api/v3/* accepts it?
Added resolveProjectAuthInfo.unit.test.ts covering: bearer ak_ accepted with fallback on, project mismatch rejected, fallback-off ignores bearer (legacy MCP behavior), x-api-key path unaffected, invalid bearer key surfaces as auth error.
⚠️ Not run locally (fresh worktree without installed deps) — relying on CI.
require_mcp_api_key dashboard toggle + fix the March 4 changelog that still documents the opt-out🤖 Generated with Claude Code