LiteLLM currently supports customer/end-user attribution through headers such as `x-litellm-customer-id` and `x-litellm-end-user-id`. This is useful when LiteLLM is called by a trusted application that knows which customer should be charged.

However, in a multi-tenant deployment where regular customers also have their own LiteLLM virtual keys, these headers should be treated as privileged attribution headers, not ordinary caller-controlled input.

## Use case

We have two classes of LiteLLM callers:

1. **Regular customer virtual keys**

These are normal customer keys. The customer should be charged according to their own LiteLLM virtual key, team, user, budget, or existing LiteLLM attribution model.

These keys should not be allowed to send `x-litellm-customer-id` or `x-litellm-end-user-id`.

2. **Trusted SaaS / internal app virtual keys**

These are also LiteLLM virtual keys, but they are used by trusted SaaS applications or internal services.

A SaaS app may know which downstream customer should be charged for a request. For example:

```http id="09jzq8" Authorization: Bearer sk-litellm-saas-app-key x-litellm-customer-id: customer_acme ```

This shoul…