Tin Chi Lo ec91056fcb feat(mcp): thread inbound identity into the v2 resolver (Subject edge) ... Adds _to_subject(user_api_key_auth, subject_token) -> Subject, the single isolated mapping from v1's authenticated principal onto the v2 Subject (so it can later swap to auth_v2's Principal): subject_id <- user_id, tenant_id <- org_id (falling back to team_id), inbound_token <- subject_token; an unauthenticated caller yields empty ids. resolve_mcp_auth and resolve_v2_auth_value now accept user_api_key_auth and thread it (plus subject_token) through, and _create_mcp_client passes its auth context in. This is foundational for the per-user arms (BYOK api_key, token_exchange, authorization_code), which must reject an empty subject_id rather than share one credential slot across callers. The identity-free modes already grafted (none, api_key shared, client_credentials, aws_sigv4) ignore the subject, so threading it is additive and backward-compatible; the params default to None. Tests cover the mapping (org-over-team precedence, team fallback, missing user -> empty, anonymous when no auth) and that threading identity doesn't change the grafted static modes. 87 tests pass; the bridge typechecks clean and no new errors land on the manager or token cache.		2026-06-18 17:32:40 -07:00
..
mcp_server	feat(mcp): thread inbound identity into the v2 resolver (Subject edge)	2026-06-18 17:32:40 -07:00