What probably matters to youSection of the release
What
Anthropic upstreams in gateway config accept a new forward_user_identity option. With it set, requests carry the signed-in developer's identity-provider subject and email as x-litellm-end-user-id, x-claude-gateway-user-id and x-claude-gateway-user-email, for a proxy you run yourself. Config validation refuses the option when the upstream base_url host is anthropic.com, any subdomain of it, or the AWS external-Anthropic pattern, so user emails never reach Anthropic.
Details
When an oidc block is present alongside it, a warning names exactly which fields get forwarded.
Off unless you add the option to an upstream.
Evidence
forward_user_identity is for identifying users to a proxy you run at base_url; it is refused for
Strings lifted out of the shipped bundle, so the claim above can be checked against them.
Read from
Names in the bundleforward_user_identity
Since it was published
The entry above is what we published on the day. These lines were added later, as Anthropic's own pages caught up, and they sit beside the original rather than replacing it.
Confirmed sinceAnthropic's documentation has since written up forward_user_identity, on Claude apps gateway configuration.If you set `forward_user_identity: true` on an upstream, a `429` it returns to a request that carried the developer's email doesn't fail over. See [how a per-user limit denial reaches the developer](#per-user-identity-headers-for-a-proxy-y…claude-apps-gateway-configsee the edit
How sure we are
Two sources agreeTwo things we can check say the same as this entry.
Anthropic's documentation agreesAnthropic's documentation has since written up forward_user_identity, on Claude apps gateway configuration.
Anthropic's release notes agreeAdded an opt-in forward_user_identity apps gateway setting on Anthropic upstreams that sends the signed-in user's identity as headers, so a…
