litellm - 💡(How to fix) Fix [Bug]: Organization-level MCP server permissions not checked at runtime [1 comments, 2 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#26791Fetched 2026-04-30 06:19:47
View on GitHub
Comments
1
Participants
2
Timeline
2
Reactions
1
Timeline (top)
commented ×1labeled ×1

Error Message

The ObjectPermission table was introduced in PR #11277 for vector store permissions. Vector stores look like they check org permissions - (there isa dedicated org_vector_store_access_denied) error type and the _can_object_call_vector_stores() function handles all three entity types (key, team, org).

Fix Action

Workaround

(a) avoid this setting in the UI and instead (b) configure MCP permissions at the Team / Virtual Key level

Code Example

N/A
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?

The UI allows configuring MCP servers and toolsets at the Organization level, but AFAICT these permissions aren't actually checked when MCP requests come in.

Background

I noticed the Org Settings page has dropdowns for MCP Servers and Toolsets, so I assumed org-level MCP permissions would cascade down to teams/keys ... taking a peek at the runtime code in user_api_key_auth_mcp.py, the get_allowed_mcp_servers() function (line ~335) only calls these:

  • _get_allowed_mcp_servers_for_key()
  • _get_allowed_mcp_servers_for_team()
  • _get_allowed_mcp_servers_for_end_user()
  • _get_allowed_mcp_servers_for_agent()

I didn't see anything like _get_allowed_mcp_servers_for_org(). The org's object_permission_id links to ObjectPermission.mcp_servers in the database, but I don't think we are checking it at runtime.

Research

The ObjectPermission table was introduced in PR #11277 for vector store permissions. Vector stores look like they check org permissions - (there isa dedicated org_vector_store_access_denied) error type and the _can_object_call_vector_stores() function handles all three entity types (key, team, org).

When MCP permissions were added later, I don't think the implementation followed the same pattern, basically:

Permission TypeKeyTeamOrgEnd UserAgent
Vector Storesxxx--
MCP Serversxxxxx

Some relevant PRs that implement MCP permission resolution without org support:

  • #22311 - Added mcp_tool_permissions to allowed servers for key, team, end_user
  • #26338 - Name/alias resolution for key, team, end_user, agent
  • #24266 - MCP team management explicitly scoped to "team-level"

Expected behavior

If I configure MCP servers on an Organization, teams and keys under that org should have access to those servers (...subject to intersection logic if they have their own permissions configured; full disclosure here I am still kind of figuring the permissions model out tbh ... apologies to the maintainers if I've missed something here).

I think that doing this would match how vector stores work (+how the UI implies it should work).

Workaround

(a) avoid this setting in the UI and instead (b) configure MCP permissions at the Team / Virtual Key level

Steps to Reproduce

Mostly this was running a few tests locally and browsing through the code on the main branch.

Relevant log output

N/A

What part of LiteLLM is this about?

No response

What LiteLLM version are you on ?

v1.83.3

Twitter / LinkedIn details

No response

extent analysis

TL;DR

The issue can be addressed by implementing organization-level permission checks for MCP servers, similar to how vector stores are handled.

Guidance

  • Review the get_allowed_mcp_servers() function in user_api_key_auth_mcp.py to understand the current permission resolution logic.
  • Investigate adding an _get_allowed_mcp_servers_for_org() function to handle organization-level permissions, similar to _can_object_call_vector_stores() for vector stores.
  • Consider updating the MCP permission resolution to follow the same pattern as vector stores, which check permissions for key, team, and organization.
  • Verify that the updated permission logic correctly intersects with team and key-level permissions.

Example

No code example is provided due to the complexity of the issue and the need for a thorough review of the existing codebase.

Notes

The issue appears to be a missing feature rather than a bug, and implementing organization-level permission checks for MCP servers may require significant changes to the existing codebase. The provided workaround of configuring MCP permissions at the team or virtual key level may be a temporary solution.

Recommendation

Apply workaround: Configure MCP permissions at the Team or Virtual Key level until the organization-level permission checks are implemented, as this will allow for more fine-grained control over MCP server access.

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…

FAQ

Expected behavior

If I configure MCP servers on an Organization, teams and keys under that org should have access to those servers (...subject to intersection logic if they have their own permissions configured; full disclosure here I am still kind of figuring the permissions model out tbh ... apologies to the maintainers if I've missed something here).

I think that doing this would match how vector stores work (+how the UI implies it should work).

Still need to ship something?

×6

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

Back to top recommendations

TRENDING

litellm - 💡(How to fix) Fix [Bug]: Organization-level MCP server permissions not checked at runtime [1 comments, 2 participants]