LiteLLM nested routing field could send provider credentials to a foreign destination

The proxy correctly restricted some direct routing fields but allowed the same routing direction to arrive through a nested user_config object. A fresh Router then sent the provider call, including credentials held by the proxy, to an attacker-controlled destination. This is distinct from the administrative configuration weakness and illustrates how gateway-authenticated requests can cross provider-secret boundaries without compromising a model.

The nested user_config route matters because a rule blocking only the obvious top-level destination field misses an equivalent destination selected later by the Router. Authorization must be evaluated on the resolved provider endpoint before proxy credentials are attached.