fix(proxy): expand config-defined model access groups when resolving team models for /v2/model/info

[ryan-crabbe-berri]

TLDR

Problem this solves:

• Teams granted a config model access group saw empty Models + Endpoints
• A model sharing a group's name was hidden from listings yet callable

How it solves it:

• Resolve team.models through the same resolver runtime auth uses
• Listings keep a literal model whose name collides with a group

User Flow

Before: a team member whose team is granted a model access group sees an empty Models + Endpoints page

1. The proxy admin tags two deployments with access group team-models-group in the config and creates a team whose only model grant is team-models-group
2. A member of that team sends GET http://localhost:4000/v1/models with their team key and gets both models back
3. The same member opens http://localhost:4000/ui/?page=models and selects their team: the table is empty, and the raw call behind it, GET /v2/model/info?include_team_models=true&teamId=..., returns {"data": [], "total_count": 0}
4. POST /v1/chat/completions with either model returns 200, so the page contradicts what the key can actually do

After: the models page lists exactly what the team can call

1. Same config, team, and key
2. GET /v2/model/info?include_team_models=true&teamId=... returns both group members with the team's id attached, and the UI table shows them
3. A deployment that happens to share the group's name now also appears in both GET /v1/models and the models page instead of silently disappearing while still being callable

Relevant issues

Linear ticket

Resolves LIT-4433

Pre-Submission checklist

Please complete all items before asking a LiteLLM maintainer to review your PR

• I have added meaningful tests
• My PR passes all CI/CD checks (e.g., lint, format, unit tests)
• My PR's scope is as isolated as possible; it only solves 1 specific problem
• I have received a Greptile Confidence Score of at least 4/5 before requesting a maintainer review (Greptile reviews automatically once the PR is opened; only comment @greptileai to re-request a review after pushing changes)

Delays in PR merge?

If you're seeing a delay in your PR being merged, ping the LiteLLM Team on Slack (#pr-review).

Screenshots / Proof of Fix

Captured live against a DB-backed local proxy on :44331. The config tags two deployments with the config-defined access group lit4433-team-models, adds a third deployment literally named lit4433-team-models (the collision case), and a fourth deployment in a different group. The team's only grant is the string lit4433-team-models

model_list:
  - model_name: lit4433-allowed-model-a
    litellm_params: {model: openai/gpt-4o-mini, mock_response: "allowed model a"}
    model_info: {access_groups: ["lit4433-team-models"]}
  - model_name: lit4433-allowed-model-b
    litellm_params: {model: openai/gpt-4o-mini, mock_response: "allowed model b"}
    model_info: {access_groups: ["lit4433-team-models"]}
  - model_name: lit4433-team-models
    litellm_params: {model: openai/gpt-4o-mini, mock_response: "collision literal model"}
  - model_name: lit4433-outside-model
    litellm_params: {model: openai/gpt-4o-mini, mock_response: "outside model"}
    model_info: {access_groups: ["lit4433-other-models"]}

Setup, identical on every run

$ curl -s -X POST $BASE/team/new -H "Authorization: Bearer sk-1234" -d '{"team_id": "lit4433-repro-team", "models": ["lit4433-team-models"]}'
$ curl -s -X POST $BASE/user/new -d '{"user_id": "lit4433-repro-user", "user_role": "internal_user", "teams": ["lit4433-repro-team"]}'
$ curl -s -X POST $BASE/key/generate -d '{"team_id": "lit4433-repro-team", "user_id": "lit4433-repro-user", "models": []}'

Main bug, before, captured at 422d925 (latest litellm_internal_staging without this PR)

/v1/models resolves the group but the Models + Endpoints endpoint returns nothing

$ curl -s $BASE/v1/models -H "Authorization: Bearer $TEAM_KEY"
"id":"lit4433-allowed-model-a"
"id":"lit4433-allowed-model-b"

$ curl -s "$BASE/v2/model/info?include_team_models=true&page=1&size=50" -H "Authorization: Bearer $TEAM_KEY"
{"data":[],"total_count":0,"current_page":1,"total_pages":0,"size":50}

$ curl -s "$BASE/v2/model/info?include_team_models=true&teamId=lit4433-repro-team&page=1&size=50" -H "Authorization: Bearer $TEAM_KEY"
{"data":[],"total_count":0,"current_page":1,"total_pages":0,"size":50}

Main bug, after, captured at 740f75b

Both /v2 queries return the group members and runtime enforcement is unchanged

$ curl -s "$BASE/v2/model/info?include_team_models=true&page=1&size=50" -H "Authorization: Bearer $TEAM_KEY"
"model_name":"lit4433-allowed-model-a"
"model_name":"lit4433-allowed-model-b"
"total_count":2

$ curl -s "$BASE/v2/model/info?include_team_models=true&teamId=lit4433-repro-team&page=1&size=50" -H "Authorization: Bearer $TEAM_KEY"
"model_name":"lit4433-allowed-model-a"
"model_name":"lit4433-allowed-model-b"
"total_count":2

$ curl -s -w '%{http_code}' -X POST $BASE/v1/chat/completions -d '{"model": "lit4433-allowed-model-a", ...}'
200
$ curl -s -w '%{http_code}' -X POST $BASE/v1/chat/completions -d '{"model": "lit4433-outside-model", ...}'
403 team not allowed to access model. This team can only access models=['lit4433-team-models']. Tried to access lit4433-outside-model

Collision hardening, before, captured at 740f75b

The deployment named lit4433-team-models is callable but hidden from every listing

$ curl -s $BASE/v1/models -H "Authorization: Bearer $TEAM_KEY"
"id":"lit4433-allowed-model-a"
"id":"lit4433-allowed-model-b"

$ curl -s "$BASE/v2/model/info?include_team_models=true&page=1&size=50" -H "Authorization: Bearer $TEAM_KEY"
"model_name":"lit4433-allowed-model-a"
"model_name":"lit4433-allowed-model-b"
"total_count":2

$ curl -s -w '%{http_code}' -X POST $BASE/v1/chat/completions -d '{"model": "lit4433-team-models", ...}'
200

Collision hardening, after, captured at c773891

Listings now match runtime access exactly: the literal deployment and both group members are visible, the outside model stays denied

$ curl -s $BASE/v1/models -H "Authorization: Bearer $TEAM_KEY"
"id":"lit4433-team-models"
"id":"lit4433-allowed-model-a"
"id":"lit4433-allowed-model-b"

$ curl -s "$BASE/v2/model/info?include_team_models=true&page=1&size=50" -H "Authorization: Bearer $TEAM_KEY"
"model_name":"lit4433-allowed-model-a"
"model_name":"lit4433-allowed-model-b"
"model_name":"lit4433-team-models"
"total_count":3

$ curl -s "$BASE/v2/model/info?include_team_models=true&teamId=lit4433-repro-team&page=1&size=50" -H "Authorization: Bearer $TEAM_KEY"
"model_name":"lit4433-allowed-model-a"
"model_name":"lit4433-allowed-model-b"
"model_name":"lit4433-team-models"
"total_count":3

$ curl -s -w '%{http_code}' -X POST $BASE/v1/chat/completions -d '{"model": "lit4433-team-models", ...}'
200
$ curl -s -w '%{http_code}' -X POST $BASE/v1/chat/completions -d '{"model": "lit4433-outside-model", ...}'
403

Type

🐛 Bug Fix

Caveats (if any)

• /v1/models now also lists a literal model colliding with a group name; strictly additive and matches what runtime auth already allowed
• A colliding name still widens the grant to group members at runtime; pre-existing behavior, the real fix is typed group grants (follow-up)
• No validation stops an admin from reusing a model name as a group name; same follow-up

Final Attestation

• The tests check the right things, including the edge cases, and regressions in the respective real-world customer use-cases are not possible after this PR

[greptile-apps]

Greptile Summary

This PR aligns model listings with runtime authorization semantics.

• Expands config-defined model access groups when resolving team models for /v2/model/info.
• Preserves a literal deployed model when its name also identifies an access group.
• Adds regression coverage for group expansion, mixed grants, name collisions, and team-scoped deployments.

Confidence Score: 5/5

The PR appears safe to merge.

No blocking failure remains.

Important Files Changed

Filename	Overview
litellm/proxy/auth/model_checks.py	Access-group expansion now preserves colliding literal deployments, matching the authorization helper’s union semantics.
litellm/proxy/proxy_server.py	Team model metadata now resolves config-defined access groups before mapping deployments while retaining team-scoped router filtering.
tests/test_litellm/proxy/auth/test_model_checks.py	Adds focused coverage for literal model and access-group name collisions.
tests/test_litellm/proxy/proxy_server/test_team_model_name_translation.py	Adds endpoint-level regression coverage for teams granted only a config-defined access group.
tests/test_litellm/proxy/test_proxy_server.py	Covers group expansion, mixed grants, collision behavior, unrelated groups, and cross-team deployment filtering.

_{Reviews (2): Last reviewed commit: "fix(proxy): keep a literal model whose n..." | Re-trigger Greptile}

[greptile-apps]

Model And Group Name Collision

When a literal model name is also used as an access-group name, get_team_models removes that literal grant and replaces it with the group's members. A team granted only the literal model can therefore receive incorrect /v2/model/info access metadata, including unrelated group members, while losing the intended model

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[codspeed-hq]

Merging this PR will not alter performance

✅ 31 untouched benchmarks

---

_{Comparing litellm_lit_4433_team_access_group_model_visibility (fe3a234) with litellm_internal_staging (40cd969)}

[ryan-crabbe-berri]

@greptileai please re-review: the rebase plus the new listing-side collision fix address the model and group name collision finding