Опубликованный в The New Stack эксперимент показывает, что предоставление ИИ-агенту более широких полномочий, чем ему необходимо, может превратить простую логическую ошибку в повторяющуюся финансовую операцию, которую модель не остановит самостоятельно. В тесте с клиентскими счетами агент поддержки подтвердил, что платёж не прошёл и деньги клиента не были списаны, однако выполнил возврат средств, хотя исходные данные этого не подтверждали, и повторил ошибку пять раз.
Claude Sonnet 5 обнаружила все шесть случаев, разработанных для проверки этой уязвимости, тогда как Claude Haiku 4.5 не справилась ни с одним из них. Однако одна строка в системных инструкциях с требованием проверить статус транзакции перед выполнением финансового действия позволила устранить проблему. При этом автор считает оба решения хрупкими: организация может заменить модель на более дешёвую версию или изменить инструкции во время эксперимента, и защита исчезнет без явного предупреждения.
Отказ в предоставлении полномочия как барьер безопасности
Защитой, выдержавшей эти изменения, оказался запрет агенту изначально иметь полномочие billing:refund. В таком случае выполнение завершалось сбоем на уровне полномочий независимо от модели или формулировки инструкций. В этом заключается суть принципа наименьших привилегий в архитектуре ИИ-агентов: цель состоит не только в том, чтобы остановить злоумышленника или защитить секретные токены, но и в том, чтобы не позволить добросовестному агенту быстро и автоматически выполнить ошибочные инструкции без надзора человека.
Природа агента отличается от природы традиционной сервисной учётной записи, выполняющей фиксированную функцию. Агент поддержки может прочитать тикет в 09:00, выполнить возврат средств в 09:04 и изменить количество мест в 09:11. Поэтому набор полномочий, необходимый для всех его потенциальных действий в течение недели, не обязательно отражает то, что ему требуется для одной конкретной задачи.
Что измерял эксперимент?
Автор создал тестовую среду с 30 полномочиями, распределёнными по девяти областям в интерфейсе программирования приложений виртуальной корпоративной системы: тикеты, пользователи, биллинг, подписки, файлы, сообщения, аудит, администрирование и поиск. Тринадцать полномочий позволяли изменять состояние или извлекать его. Эксперимент включал 20 задач, для каждой из которых существовал результат, автоматически поддающийся проверке, например закрытие тикета или возврат суммы по счёту.
На уровнях Claude Haiku 4.5 и Claude Sonnet 5 сравнивались четыре модели предоставления полномочий — всего 160 запусков:
- Широкое полномочие: долгосрочный доступ, включающий все 30 полномочий.
- Фиксированная роль: роль поддержки, включающая 17 полномочий, полученных из типового описания должности.
- Ограничение по задаче: предоставление полномочий, необходимых для каждого запуска, с их отзывом после завершения.
- Немедленная активация: начало работы без полномочий и запрос каждого полномочия по мере необходимости с указанием обоснования.
Ограничение по задаче уменьшает масштаб ущерба
Модель ограничения по задаче обеспечила полное выполнение задач, используя примерно одну пятнадцатую от числа полномочий по сравнению с широким предоставлением. Случайные отказы и повторные попытки не привели к заметному увеличению количества вызовов интерфейса.
Модель фиксированной роли оказалась слабейшей по обоим показателям. Она предоставляла 17 полномочий, четыре из которых не использовала ни одна задача, при этом ей не хватало девяти основных полномочий. Расширение роли до уровня, позволяющего успешно выполнить все задачи, потребовало бы 26 полномочий, тогда как медианное значение составляло всего два полномочия на одну задачу. Таким образом, фиксированная роль одновременно оказывается чрезмерно широкой и недостаточной, поскольку решение строится на названии должности, а не на фактической работе.
Модель немедленной активации обеспечила столь же низкий уровень потенциального ущерба, но потребовала примерно на 80% больше дополнительных вызовов интерфейса. Кроме того, отказ в предоставлении полномочия в модели задачи обычно касался необязательных исследовательских сценариев, тогда как в модели фиксированной роли отказ был окончательным, поскольку блокировал основное полномочие.
Почему это важно для организаций?
Результаты показывают, что возможности модели и системные инструкции являются изменяемыми защитными уровнями, тогда как непредоставленное полномочие остаётся эффективным даже при замене модели или изменении prompt. Поэтому командам следует проектировать полномочия агента вокруг текущей задачи, а чувствительные полномочия делать временными и подлежащими аудиту, вместо того чтобы объединять их в широкой постоянной роли.
При этом эксперимент ограничен искусственной средой, 20 задачами и двумя моделями Claude, поэтому он не доказывает, что результаты будут идентичными в каждой организации или с каждой моделью. Однако он даёт ясный практический ориентир: тестирования агента недостаточно, если архитектура позволяет ему выполнять действия, которые ему не нужны, поскольку изменение модели или инструкций может изменить поведение, тогда как способность причинить ущерб сохранится.