На днях вышло интервью Элада Мегеда из 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-серверу. Ведь пустой лог может означать как то, что запрет не потребовался, так и то, что запрет мертв.