В чём суть риска
Системные инструкции ассистента могут быть раскрыты пользователю вместе с логикой продукта и внутренними правилами. OWASP подчёркивает: системные инструкции не должны быть местом хранения секретов и единственным средством защиты.
Пользователь добивается от ассистента раскрытия скрытых инструкций, шаблонов, внутренних категорий или подсказок о политике. Модель не хранит эти сведения отдельно от остального контекста и может их воспроизвести. Граница доверия нарушена ошибочным допущением, что скрытое от интерфейса недоступно пользователю. При неудачной архитектуре вместе с инструкциями раскрываются секреты и учётные данные.
Чем риск оборачивается для компании
Раскрываются логика продукта, шаблоны и внутренние контексты.
Знание правил упрощает их обход, а секреты в инструкциях дают прямой доступ к системам.
Публикация внутренних инструкций показывает клиентам неприглядные детали настройки.
Где риск наиболее вероятен
Кому и что решать
Принять правило: инструкции считаются потенциально публичными, разграничение доступа реализуется в коде и инфраструктуре.
Обеспечить отсутствие секретов в инструкциях и детерминированные средства контроля вне модели.
Оценить, какой ущерб нанесёт публикация инструкций, и убрать из них лишнее.
Что стоит наблюдать
Признаки сами по себе не доказывают инцидент. Их полезно сопоставлять с учётной записью, версией модели, решением политики, источником контекста и результатом вызова инструмента.
Какие меры создают границу
Меры работают в связке и не перекладывают ответственность на модель: важны границы полномочий, владелец, телеметрия и процедура безопасного отказа.
Никаких секретов в инструкциях
Убрать из системных инструкций ключи, пароли и адреса. Их раскрытие перестаёт вести к компрометации.
Детерминированный контроль вне модели
Реализовать проверки прав и ограничений в коде приложения, а не в тексте инструкций.
Маскирование служебных фрагментов
Удалять из ответов совпадения с текстом инструкций и шаблонов.
Минимальные права ассистента
Ограничить доступ ассистента, чтобы знание его инструкций не давало новых возможностей.
Ревизия содержимого инструкций
Ввести обязательный просмотр инструкций перед выпуском на предмет лишних сведений.
Отслеживание запросов на раскрытие
Фиксировать обращения с просьбой показать инструкции и ответы с их фрагментами.
Вопросы, показатели и первые шаги
Вопросы команде и поставщику
- Что содержится в системных инструкциях наших ассистентов?
- Есть ли там секреты или учётные данные?
- Какая защита останется, если инструкции опубликуют?
- Кто проверяет инструкции перед выпуском?
Показатели контроля
- Доля ассистентов с проведённой ревизией инструкций
- Число секретов, найденных в инструкциях
- Число ответов с замаскированными служебными фрагментами
Первые 30 дней
- Собрать системные инструкции всех ассистентов
- Удалить из них секреты и заменить скомпрометированные
- Перенести проверки доступа из инструкций в код
Как проверить в пилотном проекте
Проверить, что недоверенный контент не может напрямую менять политику и действие системы.
Шлюз политик фиксирует разрешение или запрет для согласованных рисковых сценариев.
Трассировка связывает учётную запись, версию модели, решение политики и результат обращения.
Изменение защитного ограничения или политики проходит проверку и воспроизводимый откат.
Какие классы решений рассматривать
Ниже — редакционные профили поставщиков, связанные с доменом угрозы. Это не рейтинг и не подтверждение применимости: заявленные функции следует проверить в вашем пилоте по указанным критериям.
INFERA AI Security portfolio
InfEra Security · AI Security / DevSecOps
INFERA AI.SafeCode · INFERA AI.FirewallSTRAZH AI Control
STRAZH · Corporate AI Security
Shadow AI Audit & Control · LLM Firewall
AIGATE / DevScore / AIPitch
Aitalon · AI Gateway
AIGATE · DevScoreИсточники и проверка
Сначала — объяснение для русскоязычной команды. Затем — первоисточники, по которым можно проверить границы, методологию и применимость в конкретной архитектуре.