На днях вышло интервью Элада Мегеда из Novee Security, который рассказал, как ИИ-агент может успешно пройти встроенные проверки безопасности и все равно украсть секреты или выполнить произвольный код. Детали – на следующей неделе на Black Hat. Со слов исследователя, находки продемонстрированы на агентских конвейерах собственных репозиториев Anthropic, Google и OpenAI.

К примеру, в Claude Code Action pull request (PR) атакующего содержал баг-репорт и инструкции для Claude. Эти инструкции на чтение секретов выглядели допустимыми в контексте решения проблемы, но дальше результат работы публиковался Claude в открытом обсуждении этого PR, что приводило к утечке секретов атакующему.

Основной вывод перекликается с моим постом про OpenAI – для проверки работающего агента нужно проследить все переходы, где созданные или измененные им данные затем используются компонентом с другими полномочиями. “Прочитать секрет” может быть допустимо для внутренней задачи, а “прочитать секрет и вставить его в публичное обсуждение” – уже утечка.

Но есть у исследователя и находка, которую он проговаривает вскользь: ограничение на список разрешенных инструментов, настроенное штатными средствами Gemini CLI, не применялось при запуске в режиме --yolo. Я обратил на нее внимание, потому что у меня как раз лежал разбор changelog Claude Code, и там таких случаев уже много.

В цепочке, где агент – это модель + обвязка (харнесс), модель предлагает действие, а обвязка решает, будет ли оно выполнено и куда попадет результат. И если над агентом нет внешнего контроля, то именно от харнесса зависит, сделает ли агент что-то непредусмотренное.

Пользователь может настраивать части обвязки – например, простые контроли безопасности.

В этом своем разборе я прошелся построчно по истории release notes (>350 блоков) и разложил найденное по классам, отдельно занявшись двумя – про контроли, которые настраивает сам пользователь.

Первый класс – хуки, пользовательские скрипты в разных точках работы агента; PreToolUse-хук, например, встраивается перед вызовом инструмента и может его запретить. После вычистки – выбрасывал все, что не про несработавший контроль – осталось 18 записей о пофикшенных ошибках. В апреле починили PreToolUse-хуки. Из-за ошибки в их реализации поставленный пользовательский хук отрабатывал и мог репортить о запрете запуска инструмента, хотя на самом деле никакой запрет не применялся. А в июне – хук на чтение секретов не срабатывал на тех путях, для которых был написан. Так что пустота в логах не означала, что опасных действий не было.

Второй класс – корпоративная управляемая политика, которую админ раскатывает на компанию – нашлось 19 записей после вычистки. Самая показательная от 28 мая: одна кривая запись в списке разрешенных или запрещенных MCP-серверов фактически отключала managed-политику целиком, включая правила, к этому списку не относящиеся.

Такой разбор вообще возможен только потому, что Anthropic ведет построчный технический changelog. У Cursor исправления тоже публикуются, но чаще одной строкой на патч-версию, по которой не понять, что отказало, – по классам такое не разложишь. У ответственного вендора changelog длиннее :) Понимания масштаба реальных проблем у пользователей это не дает, но видно другое – пользовательские запреты и фактическое их исполнение расходились в нескольких десятках разных мест, разными способами и регулярно.

Практические выводы. Готовых средств, закрывающих весь путь агентного действия от разрешения до конечного эффекта, пока немного, поэтому качество вендорской реализации контролей имеет значение: вендорам стоит его повышать и проверять допустимость действия там, где используется результат работы агента. Пользователям – для критических запретов проверять, работают ли они на самом деле, регулярно, в CI или по расписанию. Для PreToolUse-хука это тестовый вызов, который обязан получить явный отказ; для управляемой политики – обращение к заранее запрещенному MCP-серверу. Ведь пустой лог может означать как то, что запрет не потребовался, так и то, что запрет мертв.