Безопасность LLM, RAG и ИИ-агентов

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

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

На уровне модели обсуждаем её происхождение, условия использования, обновления и известные ограничения. На уровне сервера, который выполняет запросы к модели, важны сетевые границы, аутентификация, лимиты ресурсов и доступ к административным функциям. В приложении проверяется, где формируются инструкции, как обрабатывается ответ и какие решения принимаются на его основе.

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

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

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

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

Для многопользовательского сервиса отдельно согласуется проверка изоляции организаций, проектов, коллекций и истории общения. Полезно подготовить матрицу доступа и тестовые документы с различающимися правами. В отчёте следует разделить недоступность документа через интерфейс, его исключение из поиска и отсутствие фрагментов в сформированном ответе: это разные наблюдения.

Если агент подключён к почте, CRM, файловому хранилищу или внутреннему API, его возможности определяются разрешениями этих интеграций. Предлагаем проверить минимальность прав, разделение чтения и записи, ограничения параметров действий и необходимость подтверждения пользователем. Критичные решения не должны зависеть исключительно от формулировки системного сообщения.

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

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

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

Предлагаемый результат — схема границ доверия, согласованная матрица сценариев, подтверждённые наблюдения и план улучшений с приоритетами. Для руководителя описываются возможные последствия для данных и процессов, для разработчиков — затронутые компоненты и проверяемые критерии исправления. Непроверенные функции, исключённые интеграции и ограничения выбранной версии отражаются отдельно.

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