Бөлісу құралы:

Безопасность агента

Создание безопасных агентов ИИ является общей задачей между фреймворком агентов и разработчиками приложений. Agent Framework предоставляет стандартные блоки — абстракции, поставщики и оркестрацию, но разработчики отвечают за проверку входных данных, защиту потоков данных и настройку средств для их сценария.

В этой статье описаны лучшие практики по созданию безопасных и защищённых агентов с помощью Agent Framework.

Общие сведения о границах доверия

Данные передаются через несколько компонентов при запуске агента: входные данные пользователя, поставщики журнала чатов, поставщики контекстов, служба LLM и средства функций. Каждая граница, в которой данные входят или покидают приложение, представляют собой потенциальную область атаки.

Основные границы доверия, которые следует учитывать:

  • Служба ИИ — получает сообщения чата (которые могут включать личные данные и системные инструкции) и возвращает выходные данные, созданные LLM.
  • Хранилище журнала чата — поставщики могут загружать и сохранять сообщения беседы через внешнее хранилище.
  • Службы контекста — поставщики контекстов могут получать или хранить данные из внешних служб (воспоминания, профили пользователей, RAG результаты).
  • Службы, доступные через средства — инструменты функций выполняют код, предоставленный разработчиком, который может вызывать внешние API или базы данных.

Все взаимодействия с внешними службами осуществляются клиентскими SDK, выбранными разработчиком. Agent Framework не управляет проверкой подлинности, шифрованием или сведениями о подключении для этих служб.

Лучшие практики

Проверка входных данных функции

ИИ может вызывать любую функцию, предоставляемую в качестве инструмента, и выбирать аргументы. Обрабатывать предоставленные LLM аргументы как ненадежные входные данные, аналогичные входным данным пользователя в веб-API.

  • Используйте список разрешений — проверьте входные данные на основе известных хороших значений, а не пытайтесь отфильтровать известные плохие шаблоны. Например, убедитесь, что путь к файлу находится в разрешенном каталоге, а не проверяйте наличие последовательностей обхода ...
  • Принудительное применение ограничений типа и диапазона — убедитесь, что аргументы имеют ожидаемый тип и в допустимых диапазонах (числовые границы, ограничения длины строки, диапазоны дат).
  • Ограничить длину строк — Установите максимальные длины строковых аргументов, чтобы предотвратить истощение ресурсов или инъекционные атаки.
  • Запретить обход файловых путей — когда функции принимают пути к файлам, преобразовать их в абсолютные пути и проверить, что они находятся в пределах разрешённых каталогов.
  • Используйте параметризованные запросы — если аргументы используются в запросах SQL, командах оболочки или других интерпретированных контекстах, используйте параметризованные запросы или экранирование символов — никогда не используйте конкатенацию строк.

Требовать утверждения для средств высокого риска

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

При принятии решения о том, какие средства требуют утверждения, рассмотрите:

  • Побочные эффекты — средства, которые изменяют данные, отправляют сообщения, делают покупки или имеют другие побочные эффекты, как правило, требуют утверждения.
  • Конфиденциальность данных — средства, которые обращаются к конфиденциальным данным (PII, финансовым данным, учетным данным), требуют одобрения.
  • Обратимость — необратимые операции (удаление, отправка сообщений электронной почты) выше риска, чем запросы только для чтения.
  • Область влияния — средства с широким воздействием (массовые операции) должны требовать более тщательного изучения, чем узкомасштабные.

Хранение системных сообщений, контролируемых разработчиком

Сообщения чата несут роль (system, user, assistant, tool), которая определяет, как служба ИИ интерпретирует их. Понимание этих ролей имеет критическое значение:

Роль Уровень доверия
system Наивысшее доверие — непосредственно формирует поведение LLM. Никогда не должен содержать ненадежные входные данные.
user Ненадежный — может содержать попытки внедрения запроса или вредоносное содержимое.
assistant Ненадежный — генерируется с помощью LLM, которое является внешней системой.
tool Ненадежный — может содержать данные из внешних систем или содержимого, на которые влияет пользователь.

Не помещайте входные данные конечных пользователей в systemсообщения -role. Фреймворк Agent по умолчанию назначает нетипизированный текст роли user, но будьте осторожны при создании сообщений программно.

Поставщики расширений Vet

Поставщики контекстов и поставщики истории могут вставлять сообщения с любой ролью, включая system. Подключайте только тех поставщиков, которым вы доверяете.

Учитывайте непрямое внедрение запроса: если базовое хранилище данных скомпрометировано, враждебное содержимое может повлиять на поведение LLM. Например, документ, полученный с помощью RAG, может содержать скрытые инструкции, которые приводят к отклонению LLM от предполагаемого поведения или эксфильтрации данных с помощью вызовов инструментов.

Проверка и очистка выходных данных LLM

Ответы LLM должны рассматриваться как ненадежные выходные данные. Служба искусственного интеллекта — это внешняя конечная точка, которой не управляет среда агент. Имейте в виду следующее:

  • Галлюцинация — LLMs могут генерировать правдоподобную, но фактически неверную информацию. Не рассматривайте выходные данные LLM как заслуживающие доверия без проверки.
  • Внедрение косвенного запроса — данные, полученные средствами, поставщиками контекстов или поставщиками истории чатов, могут содержать вредоносное содержимое, предназначенное для влияния на LLM.
  • Вредоносные загружаемые файлы — данные, генерируемые LLM, могут содержать содержимое, которое может представлять опасность при выполнении или отображении без очистки (HTML/JavaScript для XSS, SQL для SQL-инъекций, команды оболочки).

Всегда проверяйте и очищайте выходные данные LLM перед рендерингом в HTML, выполнением как кода, использованием в запросах базы данных или передачей в любой контекст, связанный с безопасностью.

Защита конфиденциальных данных в журналах

Agent Framework поддерживает ведение журнала и телеметрию с помощью OpenTelemetry. Конфиденциальные данные регистрируются только при явном включении:

  • Ведение журнала — на уровне TraceChatMessages журнала полная коллекция регистрируется. Это может включать личные данные. Trace уровень никогда не должен быть активирован в производственной среде.
  • Данные телеметрии . Если EnableSensitiveData задано, данные телеметрии включают полный текст сообщений чата, включая вызовы функций и результаты. Не включите это в рабочей среде.

Защищённые данные сеанса

Сеансы (AgentSession) представляют контекст беседы и могут быть сериализованы для сохраняемости. Обрабатывать сериализованные сеансы как конфиденциальные данные:

  • Сеансы могут ссылаться на содержимое беседы или сеансовые идентификаторы.
  • Восстановление сеанса из ненадежного источника эквивалентно принятию ненадежных входных данных. Скомпрометированный сервер хранилища может изменить роли для эскалации доверия.
  • Храните сеансы в безопасном хранилище с соответствующими элементами управления доступом и шифрованием.

Реализация ограничений ресурсов

Agent Framework не накладывает ограничения на длину входных и выходных данных или частоту запросов, так как она не знает, что разумно для вашего сценария. Вы несете ответственность за:

  • Ограничения длины входных данных — ограничение длины входных данных для предотвращения переполнения контекста или атак DoS.
  • Ограничения длины выходных данных — используйте ограничения, предоставляемые службой (например, MaxOutputTokens в параметрах чата).
  • Ограничение скорости — используйте средства ограничения скорости, чтобы предотвратить превышение затрат и злоупотребление одновременным запросом.

Дальнейшие действия

Общие сведения о средствах

Связанный контент

  • Last updated on