Безопасность MCP-инструментов: права, подтверждение и журнал

Что именно нужно защитить?

MCP-клиент получает список инструментов (tools/list), а для исполнения отправляет tools/call с именем и аргументами. Инструменты могут быть вызваны моделью; протокол не закрепляет единственный пользовательский интерфейс. Видимое «модель обещала ничего не удалять» не является серверной политикой доступа. Спецификация требует от сервера проверки входа, контроля доступа, ограничения частоты вызовов и очистки результатов, а клиенту рекомендует показывать входные параметры, спрашивать согласие на чувствительные операции и вести журнал. s2

Маршрут: тестовые данные и роль → список инструментов → изолированный сервер → разрешённый и запрещённый вызовы → журнал и сверка состояния. Не путайте безопасность интерфейса вызова с качеством ответа модели или общесистемной проверкой изоляции. Даже у сервера без сетевого порта локальный процесс получает права своей ОС-учётной записи; документация MCP отдельно предупреждает о вредоносной команде запуска и рекомендует песочницу и минимум привилегий. s1 s5

Чек-лист перед подключением

1. Источник и команда. Проверьте репозиторий, закреплённую версию, точную команду запуска, аргументы и переменные окружения. Не устанавливайте неизвестную сборку по подсказке из чата: локальный MCP-сервер исполняет код от имени запускающего пользователя. Официальные практики требуют показывать команду целиком и получать согласие при автоматическом подключении; они также рекомендуют ограничивать доступ к файлам, сети и секретам. s1
2. Граница данных. Подготовьте синтетические записи и отдельную учётную запись с доступом лишь к нужной тестовой папке или тестовому API. Выдайте только требуемое право чтения для инструмента чтения; право записи должно иметь отдельное обоснование и независимую серверную проверку. Ограничение набора доступных инструментов в клиенте снижает экспозицию модели, но само по себе не заменяет прав в сервере и целевой системе. s1 s2
3. Транспорт. Для одного локального процесса stdio использует stdin/stdout и не требует HTTP-адреса. Если нужен Streamable HTTP, проверьте сетевой bind: стандарт рекомендует локальную привязку к 127.0.0.1, требует проверять Origin и рекомендует аутентификацию соединений. Открытый 0.0.0.0 без отдельного периметра не равен «локально и безопасно». s5 s6
4. Права и токены для защищённого HTTP. OAuth-авторизация в MCP описана для HTTP, не превращайте её в обязательное требование для учебного stdio. Для защищённого ресурса сервер должен валидировать токен и его назначение именно этому MCP-серверу; не принимайте и не пересылайте чужой bearer-токен как есть в последующий API. Клиент должен запрашивать минимально необходимые scopes и передавать токен в заголовке, а не в URL. s1 s3 s4
5. Клиент и подтверждение. Выясните на конкретной версии хоста, показывает ли он название инструмента и аргументы до вызова и можно ли отклонить чувствительную операцию. Спецификация это рекомендует, но не гарантирует интерфейс подтверждения в каждой реализации; для высокорисковых действий отсутствие такой функции — причина не включать инструмент, пока нет компенсирующего контроля. s2
6. Журнал. Включите запись идентификатора операции, роли, имени инструмента, решения политики (allow/deny), факта согласия и результата без секретов и полного содержимого документа. Сверьте запись клиента с серверным журналом/состоянием. Это рекомендуемая конструкция стенда, а не обещание встроенного аудита MCP: спецификация рекомендует клиентам вести логи, но сервер или приложение должны реализовать их собственное хранение, защиту и сроки. Токены могут быть украдены из логов, поэтому маскируйте их до записи. s2 s4

Как проверить разрешённый и запрещённый вызовы?

Создайте на тестовом сервере только read_sample с доступом к одной синтетической записи и, если тестируете контроль записи, отдельный write_sample с политикой «только роль editor, только тестовый объект». Это схема испытания, не утверждение, что готовый сервер имеет такие имена. Выделите роль viewer и роль editor в целевой системе; запрет должен действовать в сервере даже если клиент ошибочно покажет write_sample. Проверяйте идентификатор и область объекта до модификации, затем независимо считывайте запись. Требование серверного контроля доступа и проверки входа содержится в спецификации инструментов. s2

• Допустимое чтение: viewer → read_sample(test-001); ожидайте возвращённую тестовую метку и строку allow в журнале. Само появление read_sample в tools/list не доказывает успешный вызов — нужна трасса tools/call и ответ. Официальный Inspector CLI умеет оба метода. s2 s8
• Запрещённая запись: viewer → write_sample(test-001, changed); даже при прямом вызове без окна клиента ожидайте отказ на сервере, запись deny и неизменённую тестовую запись. Если «отказ» существует только в ответе модели или UI, испытание не пройдено. Сервер обязан проверять права сам. s2
• Подтверждаемая запись: editor → write_sample(test-001, changed) в клиенте с подтверждением; сначала отклоните действие и проверьте отсутствие изменения, затем отдельно разрешите и проверьте изменение и пару журналов. Если клиент не показывает аргументы или не умеет остановить вызов, не объявляйте этот шаг пройденным. Наличие подтверждения у вашего клиента проверяется экспериментом, не выводится из стандарта. s2
• Неверный объект или данные: вызовите read_sample для объекта вне разрешённой области и write_sample с недопустимым полем; ожидайте отказ и отсутствие эффекта. Для HTTP дополнительно проверяйте соединение без надлежащей авторизации и нежелательный Origin на отдельном тестовом endpoint, не подвергая рабочий сервер намеренному внешнему сканированию. s2 s3 s6

В отчёте стенда запишите время, версии клиента/сервера, транспорт, учётную роль, входной аргумент без чувствительных данных, ответ инструмента, решение политики и снимок тестовой записи до/после. Чистый текст ответа модели без трассы не подтверждает выполненное действие; отсутствие изменения без записи отказа тоже не объясняет, где возник запрет. Здесь «успех» — наблюдаемый допуск по правилам и воспроизводимый отказ. s2 s8

Как развести права сервера и настройки Open WebUI?

На зафиксированной документации Open WebUI регистрацию MCP-серверов выполняет администратор в Settings → Admin → Integrations; обычным пользователям доступна отдельная настройка OpenAPI, не регистрация MCP. Администратор ограничивает доступ к подключению по пользователям или группам через Access Control. WebUI работает с MCP через Streamable HTTP, поэтому локальную stdio-команду нельзя просто вставить вместо HTTP URL. s7

Поле Function Name Filter List ограничивает видимые модели инструменты; пустое значение по документации открывает все. Используйте фильтр как дополнительный контроль выдачи, но проверяйте серверный отказ отдельным вызовом без фильтра: доступность в UI, серверная авторизация и право целевого API — разные границы. Авторизация None у закрытого локального тестового endpoint не означает, что публично доступному endpoint она не нужна; для защищённого HTTP действуют условия токенов и scopes выше. s7 s2 s3

Что делать при провале проверки?

• Отклонение в UI, но запись всё же поменялась: остановите инструмент и выясните, какой путь обошёл подтверждение; добейтесь серверного deny. Нельзя считать UI-подтверждение единственной линией защиты. s2
• Неизвестный инструмент в tools/list: отключите сервер или ограничьте публикацию набора инструментов и исследуйте происхождение команды/пакета до нового теста. Не полагайтесь на обещание модели игнорировать имя. s1 s2
• Успешный вызов без нужного токена или с токеном чужого ресурса: закрывайте HTTP-доступ и исправляйте валидацию audience; token passthrough официально запрещён. Не сохраняйте сами токены в снимках расследования. s1 s3 s4
• Журнал содержит секреты: ограничьте доступ к журналу, удалите или ротируйте скомпрометированные секреты по процедуре владельца системы, после исправления повторите тест; защищённость лога не менее важна, чем его наличие. s4

Следующий шаг: начните с безвредного локального MCP-сервера и подтвердите прямой вызов инструмента; только затем примените матрицу allow/deny к своему тестовому инструменту с настоящей серверной политикой. Без сохранённого отрицательного теста и сравнения состояния публикация инструмента для рабочих данных преждевременна. s2 s8