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