/v1/models does not respect Team member allowed_models restrictions

Summary

GET /v1/models can return models which the authenticated virtual key cannot invoke because the User's membership-level allowed_models restriction for its Team is not applied during model discovery.

This creates a discovery-versus-inference mismatch for deployments that use:

• a Team with broad models access, for example all-proxy-models;
• Users who are Team members with narrower allowed_models, including model access-group names;
• virtual keys associated with that User and Team.

Expected behaviour

When a Team member has an explicit allowed_models restriction, /v1/models should return only models that are permitted by the effective request-time policy for that virtual key, User, Team, and Team membership.

The same effective visibility should apply to:

• GET /v1/models
• GET /models
• GET /v1/models/{model_id}
• GET /models/{model_id}
• relevant model-info discovery endpoints

Actual behaviour

A virtual key can receive the Team's broad model list from /v1/models, including models outside the Team member's allowed_models.

A subsequent inference request for one of those models is correctly rejected by Team-member authorisation.

This is confusing for OpenAI-compatible clients, which use /v1/models to populate model selectors, and exposes names of models that the caller cannot use.

Minimal reproduction

1. Configure multiple proxy models and model access groups.
2. Create a Team whose models includes all-proxy-models.
3. Add a User as a Team member with allowed_models restricted to one or more model access groups, for example ["standard", "power"].
4. Generate a virtual key associated with that User and Team.
5. Call GET /v1/models using the virtual key.

Actual: models outside standard and power are returned.

Expected: only models expanded from the member's permitted groups are returned.

1. Invoke an out-of-scope model using the same key.

Actual: the request is rejected due to the Team member's allowed-model restriction.

Suggested approach

After the normal virtual-key/Team model-list resolution, apply the authenticated Team member's allowed_models as a narrowing filter, using the same model access-group, wildcard, sentinel, and alias semantics as request-time authorisation.

The implementation should preserve current behaviour when no member-level restriction is configured, and should use the key's Team context (or an explicitly validated requested Team context).

Related, but not the same

• #26420 identifies the equivalent discovery gap for LiteLLM_UserTable.models.
• #29748 proposes filtering discovery endpoints using user.models.

Those address User-level personal model restrictions. This issue concerns the separate Team-membership allowed_models restriction, which is enforced at inference time but does not appear to be consulted by the model-listing path.

If this is already supported through another configuration or endpoint, clarification would be appreciated.