Безопасность ИИ-ассистента: чек-лист проверки на утечки

Модель может безошибочно пересказывать внутренний документ, выполнять вызовы внешних сервисов и поддерживать длинный диалог — и именно в этих полезных функциях будут сосредоточены основные риски. Утечка возникает не обязательно из-за «взлома нейросети»: иногда достаточно неверно настроенного поиска по базе, слишком широкого токена или промпта, в который сотрудник вставил необезличенные данные клиента.

В редакции OWASP LLM Top 10 2026, на которую ориентирован этот разбор, акцент смещён с отдельных трюков обхода фильтров на архитектуру связки «модель — данные — инструменты». В числе центральных угроз остаются prompt injection и раскрытие конфиденциальной информации, а избыточные полномочия модели рассматриваются как самостоятельный высокорисковый класс. Прежняя «утечка системного промпта» также описывается шире: опасен не только текст инструкции, но и любой скрытый операционный контекст, который помогает восстановить устройство ассистента или получить доступ к его окружению.

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

Актуальные угрозы по OWASP LLM 2026: от раскрытия контекста до избыточных полномочий

В актуальной редакции перечня OWASP верхнюю часть списка занимают три взаимосвязанные проблемы:

1. Prompt injection — попытка изменить поведение модели через пользовательский запрос, содержимое найденного документа, веб-страницу или ответ внешнего инструмента.

2. Раскрытие конфиденциальной информации — выдача персональных данных, коммерческой тайны, внутренних инструкций, фрагментов переписки или чувствительных технических сведений.

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

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

Скрытый контекст — это больше, чем системный промпт

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

Именно поэтому тестирование безопасности ИИ-сервисов должно проверять не только запросы вроде «покажи свой системный промпт». Более реалистичные сценарии выглядят иначе:

• попросить ассистента вывести служебные поля в формате, который обычно не показывается пользователю;
• предложить ему «отладить» ошибку и напечатать полный объект запроса к инструменту;
• попросить пересказать предыдущие сообщения, включая скрытые инструкции и метаданные;
• передать в RAG-документ инструкцию, замаскированную под обычный текст, а затем проверить, повлияла ли она на ответ;
• попытаться получить сведения о другом пользователе через изменение идентификатора запроса или параметров поиска.

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

Избыточные полномочия увеличивают радиус ошибки

Function calling и агентские сценарии сделали ассистентов полезнее, но одновременно добавили новые точки отказа. Модель может отправить письмо, создать задачу, изменить запись в CRM, сформировать платёжный документ или инициировать цепочку действий в другом сервисе. В каждом случае возникает вопрос: кто принимает окончательное решение — модель или программный слой с жёсткими правилами?

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

• проверяет схему и типы аргументов;
• сопоставляет действие с ролью пользователя;
• ограничивает допустимые объекты и диапазоны значений;
• требует подтверждения для необратимых операций;
• записывает результат в журнал;
• при необходимости применяет rate limit и лимит количества вызовов.

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

Безопасность LLM — это не только способность модели давать корректные ответы. Это ещё и точное ограничение того, что она может увидеть, вызвать и изменить.

Guardrails: программные фильтры между запросом и действием

Guardrails — внешний слой контроля, который проверяет запрос пользователя, контекст, ответ модели и, в агентских системах, вызовы инструментов. Их удобно сравнивать с WAF, но аналогия неполная: веб-фильтр чаще анализирует формальные признаки запроса, а защитный слой для LLM должен учитывать смысл, последовательность сообщений и происхождение данных.

Условно guardrails можно разделить на несколько классов.

В качестве строительных блоков могут использоваться NVIDIA NeMo Guardrails, Guardrails AI, классификационные модели вроде Llama Guard и библиотеки для обнаружения персональных данных, включая Microsoft Presidio. Их нельзя считать взаимозаменяемыми «готовыми защитами»: одно решение контролирует диалоговые переходы, другое — структуру ответа, третье — семантический класс запроса, четвёртое — PII. Архитектуру приходится собирать под конкретные данные и действия ассистента.

Задержка — часть модели угроз

Каждый дополнительный вызов, особенно к отдельной LLM-классификатору, увеличивает задержку и стоимость. Точный эффект зависит от провайдера, размера запроса, числа проверок и того, выполняются ли они последовательно. В простом чате дополнительная проверка может быть почти незаметной, а в агентском сценарии с несколькими инструментами — накапливаться на каждом шаге.

Поэтому полезно разделять проверки по цене:

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

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

Input, output и контроль инструментов

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

Input-фильтр не обязательно заметит, что легитимный запрос привёл к раскрытию данных из неправильно настроенной базы. Output-фильтр может обнаружить номер документа в ответе, но не предотвратит удаление записи в CRM, если действие уже было выполнено. А контроль инструмента должен проверять не только название функции, но и её аргументы: какой объект читается, кому отправляется сообщение, какой объём данных выгружается.

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

RAG и разграничение прав: как не превратить поиск по базе в канал утечки

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

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

Где должна находиться проверка доступа

Источник истины для разрешений должен оставаться во внешней системе управления доступом: IAM, Active Directory, RBAC- или ABAC-сервисе. Метаданные векторного хранилища нужны для фильтрации и ускорения поиска, но не должны становиться единственным местом, где живёт информация о правах.

Каждый фрагмент документа может иметь атрибуты:

• владелец и подразделение;
• уровень конфиденциальности;
• список ролей или групп;
• область действия документа;
• срок актуальности;
• идентификатор исходного объекта и версии.

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

Фраза «модель физически не может вспомнить то, что ей не передали» полезна как объяснение одного ограничения, но не как абсолютная гарантия. Модель могла получить тот же факт раньше в диалоге, через другой источник, из кэша или в составе слишком широкого контекста. Кроме того, утечка возможна не только через прямую цитату: ассистент может выдать сводный вывод, по которому восстанавливается закрытая информация. Поэтому контроль должен охватывать весь путь данных.

Что проверить в RAG-интеграции

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

2. Удаление и версии. Удалённый или отозванный документ не должен оставаться доступным через старые embeddings, резервные индексы и кэш результатов.

3. Изоляция арендаторов. В мультитенантной системе фильтр должен исключать документы другой организации ещё до формирования контекста.

4. Безопасность самих документов. Текст из базы может содержать prompt injection. Документ нужно рассматривать как данные, а не как инструкцию, имеющую тот же приоритет, что и политика ассистента.

5. Журнал выдачи. В логе должны оставаться идентификаторы документов и фрагментов, пользователь, политика доступа и причина, по которой результат был допущен. Сохранять полный чувствительный текст в каждом логе необязательно и иногда опасно.

6. Проверка косвенных ответов. Тесты должны искать не только прямое цитирование документа, но и попытки вывести суммы, имена, внутренние оценки и другие признаки закрытого содержания через пересказ или сравнение.

Так RAG становится не просто поиском по смыслу, а частью системы авторизации. Если права проверяются только после генерации, это уже слишком поздний этап: модель успела получить данные, а значит, их могли увидеть промежуточные компоненты, записи отладки или другой инструмент.

Динамические учётные данные вместо статических API-ключей

Агент, который вызывает CRM, почту, таск-трекер или внутренний API, должен действовать от имени определённой идентичности. Наиболее простой, но рискованный вариант — положить в конфигурацию общий сервисный ключ с широкими правами. Такой ключ может попасть в код, переменные окружения, логи, дампы памяти или служебный контекст.

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

Динамические учётные данные, или just-in-time credentials, выпускаются непосредственно перед операцией. Посредник вроде секрет-хранилища, брокера идентичности или OAuth-сервиса выдаёт токен для конкретной функции, пользователя и ресурса. После выполнения операции токен отзывается или истекает по TTL. Конкретная реализация зависит от инфраструктуры, но принцип один: ассистент не должен годами пользоваться одним универсальным ключом.

При проектировании такого механизма полезно проверить:

• кто является субъектом действия — пользователь, агент или сервис;
• можно ли связать токен с конкретной сессией и запросом;
• ограничен ли токен одним сервисом и одной операцией;
• что произойдёт при повторном вызове или тайм-ауте;
• можно ли отозвать токен немедленно;
• попадает ли его значение в логи и сообщения об ошибках;
• требуется ли подтверждение человека перед необратимым действием.

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

Отдельно нужно тестировать повторное использование токена. Если агент получил разрешение на одну карточку, нельзя допускать, чтобы он тем же маркером запросил весь раздел CRM. Ограничение должно проверяться на стороне сервиса, а не доверяться параметру, который сформировала модель.

Гигиена данных при работе с LLM: PII, анонимизация и opt-out

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

Маскирование и псевдонимизация

Перед передачей запроса полезно применять слой обнаружения и маскирования PII. Это могут быть Microsoft Presidio, spaCy NER, регулярные выражения и собственные классификаторы. Инструмент не так важен, как правила его применения и проверка качества на реальных документах.

Обычно в область контроля попадают:

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

Простая замена имени на [ИМЯ] не всегда подходит. Если модель должна сопоставлять несколько обращений одного клиента, лучше использовать устойчивый псевдоним вроде Клиент_482, а таблицу соответствий хранить отдельно, в защищённом сервисе. В идеале модель вообще не должна иметь доступа к исходной таблице соответствий.

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

Что на самом деле означает opt-out

Настройка opt-out не является универсальным флагом, одинаковым для всех провайдеров. У разных поставщиков отличаются режимы использования данных, сроки хранения, правила для API и веб-интерфейсов, доступность корпоративных настроек, условия обработки логов и варианты изоляции окружения. Поэтому параметры вроде zero_retention или их аналоги нельзя назначать конкретному сервису без проверки официальной документации и договора.

При выборе режима нужно отдельно выяснить:

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

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

Если провайдерский режим не позволяет подтвердить нужные гарантии, варианты ограничены: маскировать данные до отправки, использовать корпоративный тариф с документированными условиями, выбрать изолированное размещение или не передавать чувствительный контекст внешней модели. Локальное развёртывание уменьшает зависимость от внешнего поставщика, но не решает автоматически проблемы прав, журналов, кэшей и доступа к внутренним инструментам.

Журналирование без создания нового источника утечки

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

Практичнее разделить журналы по чувствительности:

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

Журналирование не предотвращает утечку, но позволяет установить, какие данные получил пользователь, какой фрагмент был найден, какой инструмент вызван и на каком этапе сработала или не сработала политика.

Проверка перед запуском и после изменений

Проверка безопасности чат-бота должна быть регрессионной. Модель, индекс, фильтр или инструмент могут измениться независимо друг от друга, поэтому тесты нужно запускать не только перед первым релизом, но и после обновлений.

Минимальный набор сценариев включает:

1. Попытки раскрыть системную инструкцию, скрытые поля, идентификаторы сессии и внутренние имена инструментов.

2. Инъекции в разных формах: прямой приказ, многошаговый диалог, текст в документе, закодированный фрагмент, конфликтующие инструкции в найденном контексте.

3. Запросы к данным другого отдела, пользователя или арендатора с изменением идентификаторов и формулировок.

4. Проверку отозванных прав: заблокированный сотрудник не должен получать старые фрагменты из индекса или кэша.

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

6. Передачу PII в разных форматах — с пробелами, дефисами, ошибками, транслитерацией и внутри таблиц.

7. Проверку, что фильтр не выпускает секреты даже тогда, когда модель оформляет их как пример, цитату или фрагмент кода.

8. Сценарии отказа провайдера, тайм-аута IAM и недоступности RAG: в аварийном режиме ассистент должен безопасно остановиться, а не перейти к широкому сервисному доступу.

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

Что меняется в архитектуре ассистентов

OWASP LLM Top 10 2026 полезен не как сертификат безопасности, а как карта вопросов к собственной системе. Он показывает, что защита всё меньше сводится к выбору «самой безопасной модели». Важнее, какие данные попадают в контекст, как проверяются права, кто подписывает вызов инструмента, сколько живёт токен и что происходит с запросом после завершения диалога.

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

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

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