Всё чаще встречаю такую схему: берём LLM, даём ей доступ к kubectl или k8s API, в system prompt или подключённом skill‑е пишем что‑то вроде «ты можешь только читать, ничего не удаляй и не изменяй», и считаем вопрос закрытым. Прошёл через это сам и в какой‑то момент понял, что это не граница безопасности, а вежливая просьба.

Это не гипотетический риск: вы наверняка помните, как в июле 2025 агент Replit удалил базу данных SaaStr, несмотря на прямой запрет что‑либо менять — не Kubernetes и не MCP, но паттерн тот же самый. Инструкция «ничего не трогай» была прямо в контексте, исполнять её было просто некому, кроме самой модели. Дать агенту доступ на запись к k8s‑кластеру — значит собрать ровно ту же конструкцию, которая уже стоила SaaStr их базы.

Я далеко не первый, кто освещает эту тему, и за последнее время появилось множество read‑only MCP‑серверов. Но удивляет, насколько часто в них «read‑only» понимают неправильно. Например, у MCP‑серверов для Kubernetes “read‑only” нередко реализован как переменная окружения, которая фильтрует ответ tools/list, а не отсутствие функции в реестре. Именно так был устроен mcp‑server‑kubernetes (20 тысяч скачиваний в неделю на npm): флаг ALLOW_ONLY_READONLY_TOOLS прятал mutating‑инструменты из списка, а tools/call всё равно принимал kubectl_delete напрямую, в обход фильтра.

Получилась CVE-2026-46519, CVSS 8.8 — тот же принцип, о котором эта статья, доведённый до реального эксплойта: спрятанная из списка функция — не то же самое, что несуществующая. Причём это не только у сообщества — Azure/mcp‑kubernetes, официальный MCP‑сервер Microsoft для Kubernetes, устроен точно так же: --access-level readonly|readwrite вместо отсутствия mutating‑инструментов в принципе.