[Feature]: Add provider-scoped access control for Virtual MCPs

Prerequisites

• I have searched existing issues and discussions to avoid duplicates

Problem to solve

We use Bifrost with both internally hosted and cloud LLM providers and expose MCP servers containing internal data, such as Confluence.

We need to restrict some Virtual MCPs to specific LLM providers while allowing users to use the same Virtual Key with all providers.

For example:

vllm/*       -> Confluence MCP allowed
sgl/*        -> Confluence MCP allowed
openai/*     -> Confluence MCP denied
anthropic/*  -> Confluence MCP denied
vertex/*     -> Confluence MCP denied

This prevents internal MCP data from being exposed to cloud LLM providers.

The deprecated MCP Tool Groups supported provider scoping through provider_names, but Virtual MCPs do not appear to provide an equivalent restriction.

Proposed solution

Add provider-based access control to Virtual MCPs, equivalent to the former provider_names functionality of MCP Tool Groups.

For example:

virtual_mcps:
  - name: internal-confluence
    tools:
      - mcp_client_name: confluence
        tool_names: ["*"]
    provider_names:
      - vllm
      - sgl

When the request is handled by another provider, that Virtual MCP should not be available or executable.

The restriction must also apply when Code Mode is enabled. Provider authorization should be enforced on the actual MCP tools executed through executeToolCode, so Code Mode cannot bypass the restriction.

For example:

vllm/*   -> executeToolCode -> confluence.search() -> allowed
openai/* -> executeToolCode -> confluence.search() -> denied

If routing or fallback changes the provider handling the request, MCP authorization should be evaluated against the actual provider used.

Alternatives considered

Separate Virtual Keys for internal and cloud providers

This provides isolation but unnecessarily complicates usage. Users should be able to use one Virtual Key and select any authorized provider/model.

Custom plugin

This could potentially enforce the restriction, but provider-scoped MCP access seems like a generally useful authorization feature that should be supported natively.

Area(s)

Core (Go), Framework, UI (React)

Additional context

The goal is to preserve the provider-scoped MCP authorization capability that existed with MCP Tool Groups when migrating to Virtual MCPs.

A common enterprise use case is:

Internal providers -> internal MCP data allowed
Cloud providers    -> internal MCP data denied

without requiring different Virtual Keys for different providers.