Проблема: отсутствие авторизации в спецификации MCP
Спецификация Model Context Protocol (MCP) определяет механизмы обнаружения и вызова инструментов, но не предусматривает встроенных полей разрешений или авторизации на уровне схемы. В текущих реализациях список инструментов, попадающих в контекст модели, фактически выполняет роль слоя авторизации. Это приводит к тому, что любой запрос, имеющий доступ к серверу, получает доступ ко всем его инструментам, что создает уязвимости для атак типа "steering" (перенаправление внимания модели) и увеличивает стоимость инференса.
Метрики и риски: стоимость и безопасность
Исследование компании Bifrost выявило критические проблемы при масштабировании. В бенчмарке с 508 инструментами на 16 серверах для набора из 65 запросов потребовалось 75,1 млн входных токенов, что оценивается примерно в $377. Кроме того, исследования Invariant Labs показали, что описания инструментов с одного сервера могут манипулировать моделью на вызов инструментов с других серверов, если они находятся в контексте. Отсутствие фильтрации делает систему уязвимой к несанкционированному доступу.
Решение: Tool Groups и виртуальные ключи
Bifrost предлагает архитектуру, где политика доступа привязывается к «группам инструментов» (Tool Groups), которые затем прикрепляются к шести точкам: виртуальным ключам, командам, клиентам, пользователям, провайдерам LLM и API-ключам. В отличие от простой привязки к серверам, группировка позволяет гранулярно управлять доступом на уровне отдельных инструментов (например, разрешить read_file, но запретить write_file в рамках одного клиента).
Техническая реализация и семантика
Система использует виртуальные ключи, каждый из которых содержит конфигурацию MCP-клиентов с явным указанием разрешенных инструментов. Проверка прав выполняется дважды: при сборке набора инструментов для инференса и при поступлении запроса на выполнение. Это предотвращает расширение прав через заголовки запросов (например, x-bf-mcp-include-tools). Семантика разрешений строго определена:
| Конфигурация | Значение | Поведение |
|---|---|---|
tools_to_execute: ["*"] |
Массив со звездочкой | Разрешает все текущие и будущие инструменты клиента |
tools_to_execute: ["read_file"] |
Массив с конкретным именем | Разрешает только указанный инструмент |
tools_to_execute: [] |
Пустой массив | Блокирует все инструменты клиента |
| Отсутствие клиента в конфиге | Не указано | Полная блокировка доступа к клиенту |
Преимущества перед традиционными ключами
Традиционный подход с привязкой политик к каждому ключу (per-key filtering) становится неуправляемым при большом количестве пользователей. Например, правило «поддержка может читать тикеты, но не закрывать их» приходилось дублировать в каждом ключе сотрудника, что требовало десятков правок при изменении политики. Tool Groups позволяют создать именованный пакет прав, который применяется ко всей команде или роли, обеспечивая централизованное управление и валидацию конфигурации на этапе создания (fail-fast при опечатках в именах инструментов).
Источник: Towards AI pub ↗