Перейти к содержимому
PD
MCP-серверы

Разработка MCP-серверов: безопасность и разрешения

Почему инструмент MCP - это реальное действие, а не запрос к модели, что не стоит отдавать агенту, как устроены подтверждения и почему секреты не должны попадать в контекст.

Все статьи гида MCP-серверы · 11

MCP-сервер отличается от промпта одним свойством: его инструменты делают реальные вещи. Ошибка в промпте даёт неверный текст; ошибка в правах даёт неверное действие в вашей системе.

Инструмент - это действие

Модель выбирает инструмент вероятностно. Она может выбрать неверно из-за похожих описаний, из-за неоднозначного запроса или из-за того, что нужного инструмента нет и она берёт ближайший.

Отсюда основное правило проектирования: исходите из того, что любой доступный инструмент однажды будет вызван не вовремя. Вопрос не в том, случится ли это, а в том, что произойдёт, когда случится. Если ответ «ничего страшного» - инструмент спроектирован верно.

Отдельно про чужие серверы: подключая сервер, вы запускаете чужой код с вашими правами. Это установка зависимости, а не нажатие кнопки. Смотрите, что за пакет, кто издатель и живой ли проект - см. каталог серверов.

Что не отдавать агенту

Короткий список, который стоит соблюдать:

Удаление. Особенно массовое. Если удаление необходимо, оно должно быть мягким и обратимым.

Прод без ограничений. Боевая база с правами на запись - самая частая и самая дорогая ошибка. Начинайте с реплики или с прав только на чтение.

Деньги. Платежи, возвраты, изменение цен - только с подтверждением человеком.

Рассылки. Отправка сообщений клиентам необратима. Ошибка масштабируется мгновенно.

Массовые операции. Инструмент, который может изменить одну запись, безопаснее инструмента, который может изменить все. Если массовость нужна, ставьте жёсткий предел на число затронутых записей.

Секреты в ответах. Инструмент не должен возвращать ключи, токены и пароли. То, что вернулось агенту, ушло провайдеру модели.

Подтверждения

Не всё можно запретить, поэтому необратимые действия оформляются через подтверждение.

Как это должно быть устроено:

  • Подтверждение отдельным шагом, а не предупреждением в описании инструмента. Описание агент прочитает и всё равно вызовет.
  • Человеку показывается, что именно произойдёт: какие записи, сколько их, какое действие. «Подтвердите операцию» без деталей не является подтверждением.
  • Подтверждение не обходится агентом. Если он может вызвать инструмент, минуя шаг подтверждения, шага нет.

Отдельный уровень - проверка после действия. Отчёт агента о том, что действие выполнено, не является доказательством. Проверять надо факт: существует ли запись, изменилось ли состояние. Подробно - в статье про внедрение и верификацию агентов.

Права доступа

Правило: минимальные права, расширяемые по необходимости.

Практический порядок:

  1. Отдельная учётная запись для сервера. Не ваша личная и не администратор.
  2. Только нужные объекты. Доступ к трём таблицам, а не ко всей базе.
  3. Только чтение на старте. Запись добавляется, когда вы уже видели поведение сервера.
  4. Ограничение каталогов для файловых серверов. Рабочий проект, а не домашний каталог, где лежат ключи.
  5. Отдельные токены на среды. Локальная работа, CI и прод не должны делить один ключ.

Секреты

Три правила, которые закрывают почти все утечки:

Секреты живут в переменных окружения. Не в конфиге, особенно не в проектном конфиге, который лежит в репозитории.

Секреты не возвращаются агенту. Инструмент, отдающий содержимое файла окружения, - это утечка по построению.

Попавший в контекст секрет считается скомпрометированным. Отзывайте, а не надейтесь. Удалить его из контекста провайдера вы не можете.

Отдельно про файловые серверы: ограничьте корневой каталог. Файл с ключами в корне проекта агент прочитает при первом же поиске по файлам, и это произойдёт без злого умысла - просто в ходе выполнения задачи.

Минимальный чек-лист

  • Отдельная учётная запись с минимальными правами.
  • Только чтение на старте.
  • Нет инструментов удаления и массового изменения.
  • Подтверждение человеком для необратимого.
  • Секреты в окружении и никогда в ответах.
  • Ограниченный корень для файловых серверов.
  • Чужие серверы проверены перед подключением.
  • Вызовы логируются.

Если агент подключается к внутренним системам и нужен разбор, что именно ему можно отдать в вашем контуре, - это часть работ, описанных на странице услуг. Общая картина - гид по MCP.

Вопросы и ответы

Насколько опасно подключать MCP-серверы?

Опасен не протокол, а права. Сервер выполняет реальные действия с теми правами, которые вы ему дали, и агент может вызвать любой его инструмент. Отдельный риск - чужие серверы: подключая сервер, вы запускаете чужой код в своём окружении.

Можно ли запретить агенту опасные действия через промпт?

Промпт задаёт поведение по умолчанию, но не гарантирует его. Настоящий запрет - это отсутствие инструмента или отсутствие права в системе. Если единственная защита от удаления данных написана словами, защиты нет.

Что делать, если секрет попал в контекст агента?

Считать его скомпрометированным и отзывать. Контекст уходит провайдеру модели, и удалить его оттуда нельзя. Поэтому секреты передаются серверу через окружение и никогда не возвращаются агенту в ответах инструментов.

Ещё по теме