litellm - 💡(How to fix) Fix [Bug]: A2A agent access control bypass - any valid key can invoke agents regardless of Access Group [1 participants]

Check for existing issues

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

What happened?

When using the /a2a/{agent_id} endpoint with Access Groups configured to restrict which keys can invoke an agent, any valid API key can invoke the agent, even keys that are NOT in the assigned Access Group.

Expected: Only keys belonging to the Access Group assigned to the agent (or keys with direct agent access) should be able to call /a2a/{agent_id}. Keys outside the group should receive a 403.

Actual: Any valid API key can invoke any agent. Without an Authorization header it correctly returns 401, so authentication works — but authorization (access group enforcement) does not.

The root cause appears to be in agent_permission_handler.py:

allowed_agents = await AgentRequestHandler.get_allowed_agents(user_api_key_auth)

# Empty list means no restrictions - allow all
if len(allowed_agents) == 0:
    return True

return agent_id in allowed_agents

This has two problems:

1. Bi-directional config required but not documented: get_allowed_agents resolves agents from the key's object_permission and access_group_ids. If the key doesn't have these fields set (only the agent has the group assigned), get_allowed_agents returns [] → treated as "no restrictions" → allows all. The docs at https://docs.litellm.ai/docs/a2a_agent_permissions imply that assigning an agent to an Access Group is sufficient, but the key side must also declare group membership.

2. Fail-open on exceptions: _get_allowed_agents_for_key, _get_allowed_agents_for_team, and _get_agents_from_access_groups all have bare except Exception: return []. Any DB error, missing prisma_client, or schema mismatch silently returns an empty list, which is_agent_allowed interprets as "no restrictions" → allows all. This is the wrong fail-safe direction for a security gate — it should deny on error, not allow.

Steps to Reproduce

1. Create an agent via UI or API (not marked as public)
2. Create an Access Group (e.g. agent-users)
3. Assign the agent to the Access Group
4. Create API Key A — add it to the agent-users Access Group
5. Create API Key B — do NOT add it to any Access Group
6. Call the agent with Key A:

curl -X POST http://litellm:4000/a2a/my-agent \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer sk-key-A" \
  -d '{"jsonrpc":"2.0","id":"1","method":"message/send","params":{"message":{"role":"user","parts":[{"text":"hello"}],"messageId":"abc"}}}'

1. Call the agent with Key B (should be denied, but is allowed):

curl -X POST http://litellm:4000/a2a/my-agent \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer sk-key-B" \
  -d '{"jsonrpc":"2.0","id":"2","method":"message/send","params":{"message":{"role":"user","parts":[{"text":"hello"}],"messageId":"def"}}}'

1. Both requests succeed with 200. Key B should receive 403.

Relevant log output

No relevant error logs — the permission check silently falls through. Enabling verbose logging may show warnings from agent_permission_handler if exceptions are being swallowed.

What part of LiteLLM is this about?

Proxy

What LiteLLM version are you on?

v1.82.6

Twitter / LinkedIn details

No response