Problem
resolveOutboundHeaders decides whether to forward the full host identity header set — including X-Msh-Device-Id — by looking at the provider type alone:
const forwardsAll =
providerType !== undefined &&
getProviderDefinition(providerType)?.hostHeaders === 'full';
kimi declares hostHeaders: 'full' (kosong/provider/providers/kimi/kimi.contrib.ts), and the check never looks at the resolved endpoint. So a provider that speaks the Kimi protocol but points somewhere else:
[providers.myproxy]
type = "kimi"
base_url = "https://third-party.example.com/v1"
receives the complete X-Msh-* set, device id included.
The vendor definition answers "which protocol dialect and which header contract does this vendor use", which is the right question for protocol selection but the wrong one for "is this endpoint ours". Using a Kimi-compatible proxy or gateway is a legitimate configuration, and it is not obvious to the user that choosing type = "kimi" also opts their device identity into being sent there.
This predates the custom-identity work (#2573), but that feature makes it easier to hit: someone who configures [identity] expects third-party endpoints to see the configured product token, while a kimi-typed proxy still receives the original headers.
Suggested direction
Decide "official" from the resolved endpoint origin rather than the vendor type alone — e.g. forward the full set only when the resolved base URL matches the vendor's own endpoint, and fall back to the User-Agent-only layer otherwise.
Worth confirming first: whether any legitimate deployment intentionally points a kimi-typed provider at a non-official host and relies on the device headers reaching it (an enterprise gateway that proxies to the official API, say). That decides whether this is a straight fix or needs an opt-in.
Problem
resolveOutboundHeadersdecides whether to forward the full host identity header set — includingX-Msh-Device-Id— by looking at the provider type alone:kimideclareshostHeaders: 'full'(kosong/provider/providers/kimi/kimi.contrib.ts), and the check never looks at the resolved endpoint. So a provider that speaks the Kimi protocol but points somewhere else:receives the complete
X-Msh-*set, device id included.The vendor definition answers "which protocol dialect and which header contract does this vendor use", which is the right question for protocol selection but the wrong one for "is this endpoint ours". Using a Kimi-compatible proxy or gateway is a legitimate configuration, and it is not obvious to the user that choosing
type = "kimi"also opts their device identity into being sent there.This predates the custom-identity work (#2573), but that feature makes it easier to hit: someone who configures
[identity]expects third-party endpoints to see the configured product token, while akimi-typed proxy still receives the original headers.Suggested direction
Decide "official" from the resolved endpoint origin rather than the vendor type alone — e.g. forward the full set only when the resolved base URL matches the vendor's own endpoint, and fall back to the User-Agent-only layer otherwise.
Worth confirming first: whether any legitimate deployment intentionally points a
kimi-typed provider at a non-official host and relies on the device headers reaching it (an enterprise gateway that proxies to the official API, say). That decides whether this is a straight fix or needs an opt-in.