ИИ-инструменты разработчика: новая поверхность для атак

В 2026 году ИИ-инструменты прочно вошли в работу разработчиков: шлюзы к моделям, ассистенты в редакторах кода, протоколы вроде MCP для подключения внешних сервисов. Вместе с удобством пришёл и новый класс рисков. В октябре уязвимости и атаки нашли сразу в нескольких таких инструментах. Разбираем, почему ИИ-обвязка стала привлекательной целью и как с этим работать.

Что случилось в октябре

Несколько историй подряд показали общую картину.

• Шлюз моделей LiteLLM: в пакет на PyPI попала заражённая версия, крала ключи и секреты. Через такие шлюзы проходят ключи ко всем подключённым ИИ-сервисам.
• Редактор кода OpenCode: нашли уязвимость (исправлена в 1.18.33), где подключение к вредоносному внешнему MCP-серверу при входе могло привести к выполнению кода на компьютере разработчика в Windows и WSL.
• Утечки ключей ИИ-сервисов у хостинговых панелей и инструментов: у части пользователей могли утечь сохранённые ключи к ИИ-провайдерам.

Общее у всех — через ИИ-инструменты проходят самые ценные секреты: ключи к моделям, облакам, репозиториям. Атакующий, который доберётся до этой обвязки, получает многое сразу.

Почему это новая поверхность атаки

ИИ-инструменты устроены так, что им нужен широкий доступ: к ключам моделей, к коду, иногда к файловой системе и внешним сервисам через MCP. Это делает их удобными и одновременно опасными: один скомпрометированный инструмент открывает доступ ко всему, с чем он работает.

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

Как с этим работать

1. Относитесь к ИИ-инструментам как к привилегированным. Они имеют доступ к секретам, поэтому требования к ним те же, что к платёжному модулю.
2. Проверяйте, что подключаете. Внешние MCP-серверы, расширения, плагины — только из доверенных источников. Домен может сменить владельца, поэтому пересматривайте список периодически.
3. Разделяйте окружения. Ключи боевых сервисов не должны лежать на машине, где вы экспериментируете с ИИ-инструментами.
4. Фиксируйте версии ИИ-пакетов и обновляйте осознанно, следя за сообщениями о проблемах.
5. Делайте секреты короткоживущими, чтобы украденный ключ быстро протух.
6. Не запускайте код в заражённом окружении «чтобы проверить»: часть вредоносного кода срабатывает именно при запуске.

Наше мнение

Мы не против ИИ-инструментов — они реально ускоряют работу. Но их внедрение опередило культуру их безопасного использования. Разработчики подключают шлюзы, расширения и MCP-серверы так же легко, как раньше ставили библиотеки, не задумываясь, какой доступ им дают.

Нашим клиентам, которые внедряют ИИ в продукт или в разработку, мы советуем выстроить для ИИ-обвязки те же правила, что для любого доступа к секретам: минимальные права, короткоживущие ключи, проверенные источники, разделённые окружения. Это не тормозит работу, но превращает потенциальную катастрофу в управляемый риск. ИИ-инструменты — не исключение из правил безопасности, а ещё одна область, где эти правила нужно применять.

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

Короткий чек-лист внедрения

Перед тем как подключить новый ИИ-инструмент в работу, полезно пройти три вопроса. Какой доступ он запрашивает и действительно ли весь этот доступ нужен. Откуда он берётся — официальный источник или случайный репозиторий. Куда уходят данные, которые через него проходят. Если на все три вопроса есть внятный ответ, инструмент можно подключать; если нет — стоит разобраться до, а не после. Эта короткая проверка не тормозит внедрение, но отсекает самые опасные варианты.

Баланс между скоростью и осторожностью

Главная сложность с ИИ-инструментами в том, что они дают ощутимое ускорение, и команды не хотят его терять ради процедур. Это понятно, и полный запрет тут контрпродуктивен: люди всё равно найдут обходной путь. Разумнее встроить безопасность так, чтобы она не мешала: заранее подготовленный список одобренных инструментов, отдельное окружение для экспериментов с боевыми ключами подальше, короткоживущие токены по умолчанию. Тогда разработчик получает скорость, а компания — контроль. Безопасность, которая мешает работать, обречена на обход; безопасность, встроенная в удобный процесс, работает.

Что проверить команде

Если ваша команда уже использует ИИ-инструменты, пройдитесь по короткому списку. Какие шлюзы, расширения и MCP-серверы подключены и откуда они. Какой доступ к секретам и файлам у каждого. Разделены ли ключи боевых сервисов и среды, где идут эксперименты. Фиксируются ли версии ИИ-пакетов. Эти вопросы вскрывают, где удобство обогнало безопасность, и показывают, что поправить в первую очередь.