Описание
Разработчик часто наделяет систему на базе LLM определённой степенью автономности (agency) — способностью вызывать функции или взаимодействовать с другими системами через расширения (у разных вендоров они называются инструментами, навыками или плагинами — tools, skills, plugins), чтобы выполнять действия в ответ на промпт. Решение о том, какое расширение вызвать, также может быть передано LLM-агенту, который определяет его динамически на основе входного промпта или вывода LLM. Агентные системы, как правило, многократно обращаются к LLM, используя вывод предыдущих вызовов для обоснования и направления последующих.
Избыточная автономность (Excessive Agency) — это уязвимость, которая позволяет выполнять наносящие ущерб действия в ответ на неожиданный, неоднозначный или подвергшийся манипуляции вывод LLM, независимо от того, что вызывает сбой в работе LLM. Типичные триггеры:
галлюцинации и конфабуляции, вызванные плохо составленными безобидными промптами или просто низким качеством модели;
прямая или косвенная промпт-инъекция (prompt injection) со стороны злонамеренного пользователя, предыдущего вызова вредоносного или скомпрометированного расширения либо (в мультиагентных и совместных системах) вредоносного или скомпрометированного агента-участника.
Первопричина избыточной автономности, как правило, — одно или несколько из следующего:
избыточная функциональность;
избыточные права доступа;
избыточная самостоятельность.
Избыточная автономность может привести к широкому спектру последствий для конфиденциальности, целостности и доступности; их характер зависит от того, с какими системами может взаимодействовать приложение на базе LLM.
Примечание: избыточная автономность отличается от небезопасной обработки вывода (Insecure Output Handling), которая связана с недостаточной проверкой выходных данных LLM.
Типовые примеры уязвимости
- Избыточная функциональность. LLM-агент имеет доступ к расширениям, содержащим функции, не нужные для штатной работы системы. Например, разработчику нужно дать LLM-агенту возможность читать документы из репозитория, но выбранное им стороннее расширение позволяет также изменять и удалять документы.
- Избыточная функциональность. Расширение могли опробовать на этапе разработки и отказаться от него в пользу более удачной альтернативы, но исходный плагин остался доступен LLM-агенту.
- Избыточная функциональность. Плагин LLM с функциональностью открытого типа не фильтрует должным образом входные инструкции и пропускает команды, выходящие за рамки необходимого для штатной работы приложения. Например, расширение для запуска одной конкретной команды оболочки (shell) не предотвращает должным образом выполнение других команд оболочки.
- Избыточные права доступа. Расширение LLM имеет в нижестоящих системах права, не нужные для штатной работы приложения. Например, расширение, предназначенное для чтения данных, подключается к серверу базы данных под учётной записью, у которой есть не только права SELECT, но и UPDATE, INSERT и DELETE.
- Избыточные права доступа. Расширение LLM, предназначенное для выполнения операций в контексте отдельного пользователя, обращается к нижестоящим системам под общей привилегированной учётной записью. Например, расширение для чтения хранилища документов текущего пользователя подключается к репозиторию документов под привилегированной учётной записью, имеющей доступ к файлам всех пользователей.
- Избыточная самостоятельность. Приложение или расширение на базе LLM не выполняет независимую проверку и утверждение действий с серьёзными последствиями. Например, расширение, позволяющее удалять документы пользователя, удаляет их без какого-либо подтверждения со стороны пользователя.
Меры предотвращения и смягчения
- Предотвратить избыточную автономность позволяют следующие меры.
- Минимизация расширений. Ограничьте набор расширений, которые разрешено вызывать LLM-агентам, необходимым минимумом. Например, если системе на базе LLM не требуется получать содержимое по URL, такое расширение не должно предоставляться LLM-агенту.
- Минимизация функциональности расширений. Ограничьте функции, реализованные в расширениях LLM, необходимым минимумом. Например, расширению, которое обращается к почтовому ящику пользователя для составления сводки писем, может требоваться только чтение писем, поэтому оно не должно содержать других функций, например удаления или отправки сообщений.
- Отказ от расширений открытого типа. По возможности избегайте расширений открытого типа (например, запуск команды оболочки, загрузка по URL и т. п.) и используйте расширения с более узкой функциональностью. Например, приложению на базе LLM может понадобиться записать часть вывода в файл. Если реализовать это через расширение для выполнения команд оболочки, пространство для нежелательных действий будет очень большим (можно выполнить любую другую команду оболочки). Более безопасная альтернатива — создать отдельное расширение для записи файлов, реализующее только эту функцию.
- Минимизация прав расширений. Ограничьте права, предоставляемые расширениям LLM в других системах, необходимым минимумом, чтобы сузить область возможных нежелательных действий. Например, LLM-агенту, который использует базу данных товаров для формирования рекомендаций покупателю, может быть достаточно доступа на чтение к таблице products; у него не должно быть доступа к другим таблицам или возможности вставлять, изменять и удалять записи. Это должно обеспечиваться соответствующими правами в базе данных для учётной записи, под которой расширение LLM к ней подключается.
- Выполнение расширений в контексте пользователя. Отслеживайте авторизацию и область полномочий пользователя, чтобы действия, совершаемые от его имени, выполнялись в нижестоящих системах в контексте именно этого пользователя и с минимально необходимыми привилегиями. Например, расширение LLM, которое читает репозиторий кода пользователя, должно требовать аутентификации пользователя через OAuth с минимально необходимой областью доступа (scope).
- Обязательное одобрение пользователем. Используйте контроль с участием человека (human-in-the-loop), чтобы действия с серьёзными последствиями требовали одобрения человека до их выполнения. Это можно реализовать в нижестоящей системе (вне приложения LLM) или в самом расширении LLM. Например, приложение на базе LLM, которое создаёт и публикует контент в социальных сетях от имени пользователя, должно включать процедуру одобрения пользователем в расширение, реализующее операцию публикации.
- Полное опосредование (complete mediation). Реализуйте авторизацию в нижестоящих системах, а не полагайтесь на то, что LLM решит, разрешено ли действие. Применяйте принцип полного опосредования, чтобы все запросы к нижестоящим системам через расширения проверялись на соответствие политикам безопасности.
- Очистка входных и выходных данных LLM. Следуйте лучшим практикам безопасной разработки, например рекомендациям OWASP из стандарта ASVS (Application Security Verification Standard), уделяя особое внимание очистке входных данных. Используйте статическое тестирование безопасности приложений (SAST), а также динамическое и интерактивное тестирование (DAST, IAST) в конвейерах разработки.
- Следующие меры не предотвращают избыточную автономность, но позволяют ограничить масштаб ущерба.
- Журналируйте и отслеживайте активность расширений LLM и нижестоящих систем, чтобы выявлять, где происходят нежелательные действия, и реагировать соответствующим образом.
- Внедрите ограничение частоты запросов (rate limiting), чтобы сократить число нежелательных действий за определённый период времени и повысить вероятность обнаружить их с помощью мониторинга до того, как будет нанесён существенный ущерб.
Примеры сценариев атак
- Приложение — персональный ассистент на базе LLM получает доступ к почтовому ящику пользователя через расширение, чтобы составлять сводки входящих писем. Для этого расширению нужна возможность читать сообщения, однако выбранный разработчиком плагин содержит и функции отправки сообщений. Кроме того, приложение уязвимо к косвенной промпт-инъекции: специально составленное входящее письмо вынуждает LLM дать агенту команду просканировать почтовый ящик пользователя на предмет конфиденциальной информации и переслать её на адрес злоумышленника. Этого можно было избежать следующими способами: устранить избыточную функциональность, используя расширение, реализующее только чтение почты; устранить избыточные права, выполняя аутентификацию в почтовом сервисе пользователя через сессию OAuth с областью доступа только на чтение; и/или устранить избыточную самостоятельность, требуя от пользователя вручную просматривать каждое письмо, подготовленное расширением LLM, и самостоятельно нажимать «Отправить». Как вариант, ущерб можно было бы уменьшить, внедрив ограничение частоты в интерфейсе отправки почты.