Чек-лист безопасности MCP-сервера: 12 пунктов перед подключением рабочих данных

Безопасность MCP начинается с ограничений: проверьте сервер, сузьте доступ к данным и инструментам и оставьте человеку решение о чувствительных действиях. MCP prompt injection может прийти из найденного документа или ответа инструмента, поэтому успешная авторизация не делает содержащиеся там указания доверенными; перед подключением рабочих данных испытайте границы доступа.

Что это позволяет делать

MCP предоставляет инструменты, например для запросов к базе и вызова API; см. спецификацию инструментов, проверенную по состоянию на 30 октября 2026 года. Основная схема разобрана в статье что такое MCP.

Начните с узкой задачи: подготовить сводку разрешённых проектных обращений или ответить на вопрос по отчётному набору данных. Заранее определите источник и получателя результата. Например, помощник поддержки читает согласованную коллекцию знаний и возвращает черновик оператору; выгрузка клиентской базы и публичная публикация остаются за пределами задачи.

Проверять нужно всю цепочку: клиент, процесс сервера, внешнюю систему и решение человека. Для конкретных подключений пригодятся руководство по GitHub MCP и руководство по Postgres MCP. Связанные понятия собраны в разделе об ИИ-агентах.

Чек-лист безопасности MCP-сервера: 12 пунктов

Используйте эти пункты как условия допуска к рабочим данным. Для каждого сохраните подтверждение и назначьте ответственного. Ссылки на рекомендации проверены по состоянию на 30 октября 2026 года.

1. Проверьте программу и издателя. До запуска изучите полную команду, аргументы и источник пакета. Зафиксируйте согласованный выпуск, чтобы его замена требовала пересмотра. Локальный сервер исполняет код; рекомендации MCP по безопасности советуют минимальные привилегии и изоляцию.

2. Установите, от чьего имени выполняются действия. Запишите учётную запись во внешней системе и доступные ей данные. Для пилота выделите отдельную ограниченную запись. Убедитесь, что чтение тестовой записи другого проекта запрещено. Вход в редактор сам по себе не подтверждает реальные права сервера.

3. Сузьте права токена. Выдайте только разрешения, нужные задаче; по возможности начните с чтения. Точные названия scopes ищите в актуальной документации интеграции. Спецификация авторизации различает авторизацию через HTTP и получение учётных данных для stdio: единый сценарий входа для всех подключений предполагать нельзя.

4. Проверьте назначение токена и согласие. Для защищённого HTTP-подключения нужны токены, выпущенные именно для этого MCP-сервера. Изучите запрашиваемый доступ до подтверждения. Схему, которая просто пересылает чужой токен дальше, принимать нельзя. Проверку audience и запрет token passthrough описывают официальные рекомендации.

5. Составьте allowlist инструментов. Включайте только разрешённые операции и фиксируйте каждый инструмент вместе с его сервером. Не доверяйте аннотациям поведения от недоверенных серверов: таково требование спецификации инструментов.

6. Закрепите границы вне промпта. Ограничьте права внешней учётной записи, подключённую файловую область или права в базе данных разрешёнными ресурсами. В одноразовой тестовой среде попробуйте обратиться за пределы этой области и изучите результат. Просьба агенту не выходить из папки не подтверждает техническую защиту.

7. Ограничьте доступ по HTTP. Для локального Streamable HTTP проверьте привязку к loopback, аутентификацию и проверку Origin. Спецификация транспорта требует проверять Origin и рекомендует слушать localhost. Изучите и сетевые назначения, особенно если обнаружение конфигурации или загрузка содержимого могут обращаться к внутренним сервисам.

8. Не доверяйте указаниям из найденного содержимого. Документ, обращение или ответ инструмента с требованием получить пароль либо выгрузить данные не разрешает новую операцию. Рекомендации OWASP по prompt injection рассматривают косвенные инструкции из внешних источников. Не помещайте секреты в материалы, которые читает помощник.

9. Сделайте подтверждение содержательным. Перед чувствительным действием покажите человеку адрес назначения, затрагиваемые записи и предлагаемое изменение. Подтверждать следует конкретную операцию. Для клиентского сообщения сначала проверяют текст и получателя. Рекомендации OWASP по чрезмерным полномочиям предусматривают подтверждение человеком действий с серьёзными последствиями.

10. Сопоставьте установленный выпуск с уведомлениями об уязвимостях. Уведомление сопровождающих filesystem-сервера, опубликованное 25 октября и проверенное 30 октября 2026 года, описывает создание файлов за пределами разрешённых каталогов через симлинк и изменение регистра пути в файловых системах без учёта регистра. Сверьте затронутые и исправленные выпуски. Наличие allowlist ещё не доказывает корректность его реализации.

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

12. Испытайте отказ и восстановление. Добавьте в тестовый материал безвредное указание отправить фиктивную запись по неразрешённому адресу. Убедитесь, что передачи не было, затем проверьте отзыв доступа и остановку сервера. Подбирая дальнейшие испытания, используйте категории рисков OWASP для LLM: prompt injection, раскрытие чувствительной информации и чрезмерные полномочия агента.

Как безопасно подключить сервер

1. Подготовьте изолированный пилот. Возьмите синтетические записи, ограниченную учётную запись и письменное описание разрешённой задачи. Пройдите чек-лист до добавления рабочих учётных данных.
2. Добавьте проверенный сервер в VS Code. Откройте палитру команд и выполните MCP: Add Server. Для адреса издателя выберите HTTP, для команды запуска — Command (stdio). Следуйте официальной инструкции редактора, проверенной по состоянию на 30 октября 2026 года: место хранения конфигурации зависит от выбранной среды агента.
3. Изучите запросы доверия и входа. Проверьте команду либо адрес и запрашиваемые права учётной записи. Не отправляйте секреты в чат и не сохраняйте их в конфигурации репозитория. Оставьте только нужные пилоту инструменты.
4. Выполните разрешённое чтение. Запросите конкретную синтетическую запись. Раскройте вызов инструмента и посмотрите, какой сервер ответил и что вернул. Правдоподобный текст ответа ещё не подтверждает работающее подключение.
5. Проверьте запреты и расширяйте доступ осознанно. Сохраните результаты, назначьте владельца доступа и согласуйте процедуру отзыва. Повторяйте соответствующие испытания при изменении учётных данных, инструментов, выпуска сервера или настроек подтверждения.

Когда это не работает

Даже подключение только для чтения способно раскрыть чувствительные сведения в ответе. OAuth управляет авторизацией, но не определяет, следует ли выполнять указание из найденного текста. OWASP рекомендует многоуровневую защиту от prompt injection; успешное испытание не доказывает неуязвимость. Подробнее — в рекомендациях по prompt injection.

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

Где здесь Tvijo

По состоянию на 30 октября 2026 года документированный подход Tvijo связывает область задачи, allowlists, квитанции и этапы проверки. Разделяйте их назначение: allowlist задаёт разрешённые действия, токен с узкими правами ограничивает полномочия учётной записи, квитанция фиксирует наблюдаемое использование, а приёмка оценивает результат. Руководство по разрешениям предусматривает явное решение для удалённых изменений и денежных действий. Эти правила процесса не подтверждают наличие готового слоя принудительной проверки scoped tokens для любых MCP-подключений.

Расширение DSHREM для VS Code служит точкой входа из редактора; доступные локальные действия зависят от сборки и режима подтверждения. Сравнение продуктов отделяет его от управляемой оператором терминальной среды, где нужно проверять объявленный allowlist и фактическую изоляцию. TvijoCode остаётся тестовой сборкой с неподписанным дистрибутивом и ручным обновлением.

Запись о выпуске Tvijo MCP различает опубликованные консультации и подготовленную проверку переданного diff, ожидающую публикации. Подготовленная функция возвращает замечания и квитанции расходов; она не запускает тесты и не сливает изменения. Интеграция с редактором и безопасное делегирование остаются планами с отдельными условиями приёмки. Финансовая квитанция не подтверждает соблюдение прав внешним коннектором.

На сайте Tvijo по состоянию на 30 октября 2026 года указаны следующие предложения. Try стоит $0 и заканчивается при достижении первого из лимитов: 5 задач, 50 000 токенов или $0.05 спонсируемого использования. Доступ идёт из общего дневного пула $1, финансируемого TVIJO. Service credit показан за $10 как запрос предоплаченного кредита: учитывается фактическое использование провайдеров плюс сервисная наценка 8%. Приём платежей не активирован; создание заказа не означает списание денег.

Частые вопросы

Защищает ли аутентификация MCP от prompt injection?

Нет. Аутентификация и авторизация управляют доступом. Внешнее содержимое всё ещё может пытаться перенаправить агента; ограничивайте действия и проверяйте чувствительные операции.

Достаточно ли токена только для чтения рабочих данных?

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

Что должно остановить подключение к рабочим данным?

Неизвестная программа, избыточные права, непроверенная граница доступа или отсутствие ответственного за отзыв. До устранения этих проблем оставьте пилот на синтетических данных.