Issue Station
Sign In
Tools hereToolbox

litellm - ✅(Solved) Fix [Bug]: Access Groups not working as described [1 pull requests, 1 participants]

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…
GitHub stats
BerriAI/litellm#23850•Fetched 2026-04-08 00:48:47
View on GitHub
Comments
0
Participants
1
Timeline
6
Reactions
2
Author
DanielQ-CVDanielQ-CV
Participants
DanielQ-CVDanielQ-CV
Timeline (top)
referenced ×4cross-referenced ×1labeled ×1

Fix Action

Fixed

PR fix notes

PR #25196: fix: access group model restrictions ignored for virtual keys (#23850)

Description (problem / solution / changelog)

When a key had models=[] and access_group_ids set, get_key_models() returned an empty list, causing get_complete_model_list() to fall back to team_models and grant full team-level access — ignoring the access group restriction entirely.

Add get_key_models_with_db_access_groups() (async) that calls the existing sync get_key_models() and, only when it returns empty and the key carries access_group_ids, fetches the allowed models from the DB access group table. Callers in proxy_server.py and utils.py are updated to await this function.

Three unit tests cover: restriction enforced, no-access-group fallback preserved, and native model list takes precedence over access_group_ids.

Relevant issues

<!-- e.g. "Fixes #000" -->

Pre-Submission checklist

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

  • I have Added testing in the tests/test_litellm/ directory, Adding at least 1 test is a hard requirement - see details
  • My PR passes all unit tests on make test-unit
  • My PR's scope is as isolated as possible, it only solves 1 specific problem
  • I have requested a Greptile review by commenting @greptileai and received a Confidence Score of at least 4/5 before requesting a maintainer review

Delays in PR merge?

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

CI (LiteLLM team)

CI status guideline:

  • 50-55 passing tests: main is stable with minor issues.
  • 45-49 passing tests: acceptable but needs attention
  • <= 40 passing tests: unstable; be careful with your merges and assess the risk.

  • Branch creation CI run
    Link:

  • CI run for the last commit
    Link:

  • Merge / cherry-pick CI run
    Links:

Type

<!-- Select the type of Pull Request --> <!-- Keep only the necessary ones -->

🆕 New Feature 🐛 Bug Fix 🧹 Refactoring 📖 Documentation 🚄 Infrastructure ✅ Test

Changes

Changed files

  • litellm/proxy/auth/auth_checks.py (modified, +9/-0)
  • litellm/proxy/proxy_server.py (modified, +9/-0)
  • litellm/proxy/utils.py (modified, +16/-2)
  • tests/proxy_unit_tests/test_auth_checks.py (modified, +53/-0)
  • tests/test_litellm/proxy/auth/test_model_checks.py (modified, +116/-0)
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?

Access Groups do not seem to restrict model access for virtual keys as documented.

Use Case / Steps to Reproduce

  1. Created a Team with "All Proxy Models" access.
  2. Created a Virtual Key as a Service Account with no models selected in the model dropdown.
  3. Under "Access Groups", selected a group with a limited model selection.

Actual Result

The virtual key has access to all models from the team. The restriction defined in the Access Group has no effect.

Expected Result

The virtual key should only have access to the models defined in the Access Group, as described in the official documentation: 📄 https://docs.litellm.ai/docs/proxy/access_groups

Environment

  • LiteLLM Version: 1.82.3 (non-root / stable)
  • Deployment type (Docker / pip / Kubernetes): Kubernetes
  • Enterprise License

Steps to Reproduce

  1. Created a Team with "All Proxy Models" access.
  2. Created a Virtual Key as a Service Account with no models selected in the model dropdown.
  3. Under "Access Groups", selected a group with a limited model selection.

Relevant log output

What part of LiteLLM is this about?

No response

What LiteLLM version are you on ?

v1.82.3

Twitter / LinkedIn details

No response

extent analysis

Fix Plan

To fix the issue with Access Groups not restricting model access for virtual keys, we need to update the access control logic.

  • Update the VirtualKey model to include a foreign key referencing the AccessGroup model.
  • Modify the VirtualKey creation logic to apply the AccessGroup restrictions.
  • Implement a check to ensure the virtual key's access is limited to the models defined in the AccessGroup.

Example code snippet:

# models.py
from django.db import models

class VirtualKey(models.Model):
    # ...
    access_group = models.ForeignKey('AccessGroup', on_delete=models.CASCADE)

# views.py
from rest_framework import status
from rest_framework.response import Response
from .models import VirtualKey, AccessGroup

def create_virtual_key(request):
    # ...
    access_group = AccessGroup.objects.get(id=request.data['access_group_id'])
    virtual_key = VirtualKey.objects.create(
        # ...
        access_group=access_group
    )
    # Apply access group restrictions
    virtual_key.models = access_group.models
    # ...
    return Response(status=status.HTTP_201_CREATED)

# permissions.py
from rest_framework import permissions

class VirtualKeyPermission(permissions.BasePermission):
    def has_object_permission(self, request, view, obj):
        # Check if the virtual key's access is limited to the models defined in the access group
        if request.user.is_authenticated and obj.access_group:
            return obj.access_group.models.filter(id=request.data['model_id']).exists()
        return False

Verification

To verify the fix, create a new virtual key with an access group that has limited model selection. Then, try to access a model that is not included in the access group. The virtual key should not have access to that model.

Extra Tips

  • Ensure that the AccessGroup model is properly configured and has the correct model selections.
  • Test the fix with different access group configurations to ensure the virtual key's access is correctly restricted.
  • Consider adding additional logging to track access group restrictions and virtual key access attempts.

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…
#api#ssr#installation#tensor shape#autograd error#GPU compatibility#latency issue#model loading#dependency error#configuration error

Still need to ship something?

×6

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

Back to top recommendations

TRENDING