Подключай MCP-сервер так, будто выдаёшь новому приложению доступ к конкретному ресурсу: выясни, кто его поддерживает, что он получает и какие действия может совершать. Сам факт использования стандартного протокола не делает сервер доверенным. Сначала читай разрешения, потом подключай минимальный доступ, затем проверяй на тестовом ресурсе.
Официальная документация MCP описывает протокол соединения AI-приложений с внешними системами, а security guide перечисляет риски реализации, включая token passthrough, SSRF, ошибочную обработку OAuth URL и компрометацию локального сервера (MCP Security Best Practices). Это руководство адресовано разработчикам и операторам; конкретная поверхность риска зависит от клиента и сервера.
Чек-лист до подключения
1. Идентичность и происхождение
- Откуда взят сервер: официальный поставщик, известный проект или случайный репозиторий?
- Кто может менять исходный код и выпускать обновления?
- Есть ли инструкция по установке, список зависимостей и политика обработки данных?
- Локально ли он запускается или обращается к внешнему хосту?
Не считай популярность доказательством безопасности. Проверь URL, домен, владельца пакета и версию. Если сервер запускается командой из интернета, прочитай скрипт перед запуском.
2. Доступ и токены
- Нужен ли только просмотр или также создание/редактирование/удаление?
- Можно ли выдать доступ к отдельной папке, тестовому календарю или минимальному OAuth scope?
- Где хранится credential и можно ли его отозвать независимо?
- Передаёт ли клиент токен только предназначенному серверу?
Не передавай MCP-серверу bearer-токен, выпущенный для другого сервиса, если клиент и протокол не предусматривают такую делегацию. Проверяй, что audience токена соответствует серверу-получателю. Секреты не помещай в URL или чат. Руководство MCP отдельно описывает риск token passthrough.
3. Данные и недоверенный текст
Если сервер читает веб-страницы, письма или документы, их содержимое может включать инструкции, адресованные агенту. Рассматривай этот текст как данные, а не как доверенную команду. OWASP описывает indirect prompt injection через внешние страницы и файлы и подчёркивает, что RAG сам по себе не полностью устраняет этот класс риска (OWASP LLM01).
4. Поведение инструментов
Перед подключением выпиши доступные методы и ожидаемый эффект. «Поиск файлов» и «удаление файла» — разные уровни риска. Предпочитай read-only действие; для записи — тестовый объект, подтверждение пользователя и журнал результата.
Тест безопасного старта
- Подключи сервер только к тестовой папке или аккаунту.
- Выполни один запрос, который ничего не меняет.
- Сверь ответ с фактическим источником и логом.
- Проверь отказ в доступе к запрещённому ресурсу.
- Отключи сервер, отзови тестовый токен и удостоверься, что доступ пропал.
Это не аудит безопасности и не гарантия отсутствия уязвимостей. Это базовая проверка конфигурации до выдачи реального доступа.
Если нужно отключить интеграцию
Выключи сервер в клиенте, отзови OAuth-разрешение у поставщика, удали локальный токен из хранилища и проверь журналы на неожиданные запросы. Если credential мог попасть в лог или репозиторий, считай его раскрытым и отзови — удаление строки из последнего коммита не удаляет её из истории.
Сохрани короткую запись: сервер и версия, дата проверки, клиент, предоставленные scope, тестовое действие и способ отключения. Не записывай в этот отчёт credential или полный запрос с конфиденциальными данными. При обновлении сервера повтори проверку — код и список инструментов могли поменяться.
Если интеграция открывает OAuth-авторизацию, сверь hostname и redirect URI с ожидаемым authorization server. При неожиданном домене остановись и не подтверждай доступ. Так можно заметить подмену адреса и сценарий confused deputy, когда компонент запрашивает полномочия не для того получателя.
Подключение к локальной программе тоже не автоматически безопасно: расширение может запускать команды в пользовательском контексте. Ограничь каталоги и полномочия процесса, проверь родительский package manager и обновления.
Простой журнал разрешений
| Поле | Пример безопасной записи |
|---|---|
| Ресурс | Тестовый календарь, не личный аккаунт |
| Scope | Только просмотр событий |
| Действия | Поиск, получение деталей |
| Запись/отправка | Выключена; требует отдельного подтверждения |
| Данные в запросе | Только интервал и ключевое слово |
| Отключение | Отозвать grant у провайдера и убрать сервер из клиента |
Пиши реальные scopes ровно так, как их показывает провайдер, а не сокращённый пересказ. Если не понимаешь scope, не подтверждай доступ. Внутренний проект может потребовать согласования с администратором: локальная авторизация пользователя не заменяет корпоративную оценку подрядчика.
Для начала можно изучить разницу между пакетом инструкций, кодом и протоколом в материале Skills, плагины и MCP.
Для read-write сервера отдельно проверь, кто может вызвать инструмент и какие объекты он вправе менять. Доступ должен ограничиваться на стороне сервера, а не только скрытием кнопки в интерфейсе. Если тест обнаружил неожиданную запись или удаление, отключи tool и отзови тестовые права.
Проектирование и отладка таких интеграций — тема MK Ultra.