litellm - 💡(How to fix) Fix [Bug]: Model access check ignores access_group_ids assigned directly to a Virtual Key

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…

Error Message

This causes a 403 error even though access_group_ids is correctly stored on the key and the access group contains the requested model. Step 3 — Observe the error: {"error":{"message":"team not allowed to access model. This team can only access models=['no-default-models']. Tried to access <model-name>","type":"team_model_access_denied","param":"model","code":"403"}}

Root Cause

Related issue (same root cause, different symptoms):

  • #23850 — Access Group on Virtual Key doesn't restrict model access (inverse symptom: team grants too much, key-level restriction is ignored)

Fix Action

Fix / Workaround

Expected behavior: The model authorization check should resolve the full permission chain:

key.access_group_ids → access_group.models → allowed models

When key.access_group_ids is set, the models in those access groups should be merged into the allowed models for that key — independent of the team's model list.

Workaround: Assign the Access Group to the Team instead of directly to the Virtual Key. In this case team_info.access_group_models is populated and the model call succeeds.

Code Example

key.access_group_ids → access_group.models → allowed models

---

curl -s "https://<litellm-host>/key/info?key=<VIRTUAL_KEY>" \
  -H "Authorization: Bearer <VIRTUAL_KEY>"

---

{
  "info": {
    "models": ["all-team-models"],
    "team_id": "<team-id>",
    "access_group_ids": ["<access-group-uuid>"]
  }
}

---

curl -s -X POST "https://<litellm-host>/v1/chat/completions" \
  -H "Authorization: Bearer <VIRTUAL_KEY>" \
  -H "Content-Type: application/json" \
  -d '{"model": "<model-name>", "messages": [{"role": "user", "content": "ping"}], "max_tokens": 5}'

---

{"error":{"message":"team not allowed to access model. This team can only access models=['no-default-models']. Tried to access <model-name>","type":"team_model_access_denied","param":"model","code":"403"}}
RAW_BUFFERClick to expand / collapse

Check for existing issues

  • I have searched the existing issues and checked that my issue is not a duplicate.

What happened?

When an Access Group is assigned directly to a Virtual Key (via the UI, resulting in a populated access_group_ids field on the key), the model authorization check ignores key.access_group_ids entirely and falls back to the team's models list instead.

This causes a 403 error even though access_group_ids is correctly stored on the key and the access group contains the requested model.

Expected behavior: The model authorization check should resolve the full permission chain:

key.access_group_ids → access_group.models → allowed models

When key.access_group_ids is set, the models in those access groups should be merged into the allowed models for that key — independent of the team's model list.

Actual behavior: The authorization check only evaluates team.models. The key's access_group_ids field is stored correctly but never consulted during model access validation. The team restriction (no-default-models) takes precedence and blocks the request.

Workaround: Assign the Access Group to the Team instead of directly to the Virtual Key. In this case team_info.access_group_models is populated and the model call succeeds.

Related issue (same root cause, different symptoms):

  • #23850 — Access Group on Virtual Key doesn't restrict model access (inverse symptom: team grants too much, key-level restriction is ignored)

Steps to Reproduce

Setup:

  1. A Team with models = ["no-default-models"]
  2. An Access Group containing one or more specific models
  3. A Virtual Key assigned to that team
  4. The Access Group assigned directly to the Virtual Key (not to the team) via the UI

Step 1 — Verify access_group_ids is stored on the key:

curl -s "https://<litellm-host>/key/info?key=<VIRTUAL_KEY>" \
  -H "Authorization: Bearer <VIRTUAL_KEY>"

Response confirms access_group_ids is populated:

{
  "info": {
    "models": ["all-team-models"],
    "team_id": "<team-id>",
    "access_group_ids": ["<access-group-uuid>"]
  }
}

Step 2 — Attempt a chat completion with a model from the access group:

curl -s -X POST "https://<litellm-host>/v1/chat/completions" \
  -H "Authorization: Bearer <VIRTUAL_KEY>" \
  -H "Content-Type: application/json" \
  -d '{"model": "<model-name>", "messages": [{"role": "user", "content": "ping"}], "max_tokens": 5}'

Step 3 — Observe the error:

Expected: 200 OK

Actual: 403 (see log output below)

Relevant log output

{"error":{"message":"team not allowed to access model. This team can only access models=['no-default-models']. Tried to access <model-name>","type":"team_model_access_denied","param":"model","code":"403"}}

What part of LiteLLM is this about?

Proxy

What LiteLLM version are you on ?

v1.85.1

Twitter / LinkedIn details

No response

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING