Агент в IDE может сам подключить инструмент, которого ему никто не выдавал. Для этого атакующему может быть достаточно спрятать инструкцию на странице, которую агент прочитает.

Недавно исследователи Intezer и Kodem опубликовали разбор уже исправленной уязвимости Kiro, агентной IDE от AWS. Но что закрыло это исправление – найденный путь атаки или устранило сам механизм?

Сценарий атаки выглядел так – разработчик просит Kiro пересказать документацию по ссылке. Но на странице спрятана невидимая инструкция, классический indirect prompt injection. Kiro принимает ее за часть задания и записывает в конфиг MCP-серверов новый сервер с произвольной командой запуска. IDE автоматически перечитывает файл, подключает сервер и выполняет команду с правами разработчика.

Одной записью агент и подключает новый инструмент, и задает команду, которую Kiro запускает при перечитывании конфига. mcp.json здесь лишь один из возможных путей. Опасность возникает, когда недоверенный текст может заставить агента переписать конфигурацию своих будущих возможностей, а платформа принимает такую правку как доверенную.

Этот механизм в Kiro нашли еще в день релиза, в июле 2025 года. Исследователь Йохан Рехбергер показал, как через mcp.json агент подключал произвольный MCP-сервер, а через .vscode/settings.json добавлял shell-команды в список разрешенных.

После первой находки AWS добавила подтверждение таких действий, но только в режиме, где правки проходят через ревью. В автономном режиме, включенном по умолчанию, подтверждение по-прежнему не требовалось.

Находка попала к AWS в феврале 2026-го. Разработчик подтверждал только загрузку страницы, а дальше Kiro без отдельного согласия записывал новый MCP-сервер и запускал его команду. Иногда IDE показывала окно подтверждения, но перечитывала файл независимо от ответа. Окно предупреждало о записи, но не могло ее остановить.

Через девять месяцев после первой находки исследователи подтвердили новое исправление. Сейчас Kiro защищает чувствительные файлы на уровне платформы в обоих режимах и требует согласия на возможности, заранее не разрешенные разработчиком.

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

При выборе агентной IDE я бы поэтому проверил две вещи.

– Может ли агент менять конфигурацию, из которой среда получает его инструменты и автоматически запускаемые команды?

– Контролирует ли платформа такие изменения во всех режимах, независимо от решения модели?

Второй вопрос перекликается с моим прошлым постом – про то, что “включен” не значит “работает”. Здесь ровно тот же сюжет с другой стороны: окно подтверждения в Kiro показывалось, а запись все равно применялась.

После повторной находки нужно менять архитектуру контроля, а не закрывать еще один путь к тому же уязвимому механизму.