Еще шесть месяцев назад протокол MCP был у всех на устах, и казалось, что все стремятся выпустить продукты и инструменты, связанные с MCP.
Но что изменилось за это время?
Люди стали замечать, что при работе с MCP агент тратит больше токенов, чем если бы он использовал обычные CLI tools.
Но это не основная проблема.
MCP стали расти как на дрожжах, и не всегда становится понятно, надежным ли инструментом ты пользуешься.
Один разработчик рассказывает, что он с удивлением обнаружил 66 zombie Docker containers.
Агент взаимодействует с локальными MCP-серверами через stdio.
Он запускает docker run -i, отправляет JSON через stdin и читает ответы из stdout.
Когда вы закрываете сессию Claude Code, процесс docker run завершается.
Но сам контейнер — это отдельный процесс, управляемый демоном Docker, который не знает, что сессия MCP завершена.
Контейнер продолжает работать, удерживая открытым соединение с базой данных и ожидая данные из stdin, которые уже никогда не придут.
Флаг --rm в этом случае не помогает: он удаляет контейнер после его остановки.
Но эти контейнеры никогда не останавливаются.
Решение: использовать uvx вместо Docker.
И многие MCP доступны как пакеты, которые можно запускать напрямую.
uvx запускает сервер как обычный дочерний процесс.
Когда агент завершает работу, этот процесс автоматически очищается.
npx и pnpx работают аналогичным образом.
Другая ситуация оказалась намного хуже.
Атаку выявили при анализе инцидента: у разработчика litellm оказался транзитивной зависимостью MCP-плагина в Cursor.
Но инцидент с litellm произошёл не на ровном месте.
Чуть ранее был подвержен атаке Trivy.
Trivy — это инструмент, который ты запускаешь в своём CI/CD пайплайне, и он проверяет твой код на уязвимости. Ищет проблемы в NPM-пакетах, Python-зависимостях, Docker-образах, проверяет мисконфигурации в Kubernetes, находит захардкоженные секреты.
В общем, это именно тот инструмент, который должен быть про безопасность — но иронично, что вот его-то и взломали.
24 марта.
LiteLLM — Python-библиотека-прокси для всех LLM API с 95 миллионами загрузок в месяц, которая использовала Trivy в своём CI, потеряла токен мейнтейнера, и с его помощью были опубликованы версии 1.82.7 и 1.82.8 с вредоносным кодом.
Какие выводы можно сделать из этих историй с MCP?
Пинить и убирать :latest из Docker-образов
Пинить и убирать :latest из любых сторонних пакетов
Хотя бы частично проверять код MCP и issues на GitHub
@tldr_data