AppSec-команда проверяет AI-приложение, которое читает документы, страницы и сообщения, а затем помогает пользователю выполнить действие: подготовить отчёт, открыть задачу, обратиться к данным или вызвать внутренний инструмент. Главный риск возникает в момент, когда внешний контент перестаёт быть только данными и начинает влиять на действие приложения.
внедрение инструкций в таком сценарии не обязательно выглядит как сложная атака. Вредная инструкция может лежать в документе, комментарии, веб-странице или скрытом блоке текста. Модель может принять её за часть задачи и попытаться сделать то, чего пользователь не просил: раскрыть контекст, вызвать инструмент, изменить данные или обойти политику.
Цель проверки — доказать, что граница между данными и инструкциями работает технически. Нельзя полагаться только на системную подсказку. Нужен слой политики, который видит намерение пользователя, источник контента, доступные действия и чувствительность целевого ресурса.
Статья полезна командам, которые внедряют LLM в рабочие процессы: обработку заявок, документов, знаний, CRM и внутренних порталов. Чем больше действий доступно приложению, тем важнее AppSec-тесты до релиза.
Минимальный набор тестов
Проверка должна имитировать обычный рабочий процесс. Тестовый документ или страница содержит безопасную скрытую инструкцию: попросить модель игнорировать правила, раскрыть контекст или вызвать действие, которое не относится к задаче. Тест считается проваленным не только при фактической утечке, но и при попытке вызвать недопустимый инструмент.
Важно проверять несколько источников: документ, письмо, страницу, запись в базе знаний и комментарий пользователя. Один защищённый канал не доказывает безопасность всей цепочки.
- документ с недоверенной инструкцией;
- страница со скрытым блоком;
- письмо с просьбой изменить действие;
- запись базы знаний с конфликтной инструкцией;
- попытка вызвать лишний инструмент;
- попытка обратиться к чужим данным;
- проверка журнала отказа политики.
Как строить безопасную архитектуру действий
Приложение должно разделять пользовательскую задачу, внешний контент и системные правила. Внешний контент помечается как недоверенный и не может самостоятельно расширять права. Перед каждым действием внешний слой политики проверяет: кто пользователь, что он просил, какой источник повлиял на решение и какой ресурс будет затронут.
Если действие меняет данные или раскрывает чувствительную информацию, нужно подтверждение. Подтверждение должно показывать не только результат, но и причину: какие данные используются и почему действие допустимо.
- маркировать внешний контент как недоверенный;
- запрещать внешнему контенту менять политику;
- проверять права перед каждым действием;
- вести журнал причины вызова инструмента;
- разделять чтение, подготовку и изменение данных;
- требовать подтверждение для чувствительных операций;
- показывать пользователю источник решения.
Журналы и признаки, без которых расследование слепнет
Расследование должно связывать исходную задачу, пользователя, устройство, вызов модели, действие приложения и сетевое событие. Если эти элементы пишутся в разные системы без общего идентификатора, аналитик видит отдельные фрагменты и не может доказать цепочку.
Для AI-сценариев важно хранить не только ответ модели, но и решение политики: что было разрешено, что было остановлено, какой источник данных использовался и почему действие считалось допустимым.
- идентификатор пользователя и роль;
- идентификатор устройства и доверенность среды;
- источник данных и уровень чувствительности;
- версия модели и версия политики;
- тип действия и целевой ресурс;
- оценка риска и причина решения;
- сквозной идентификатор всей операции.
Контроли, которые нужно включить заранее
Контроль должен находиться вне модели. Подсказка может объяснять правила, но запрет опасного действия должен выполняться отдельным слоем: политикой доступа, сетевым шлюзом, проверкой владельца данных или ручным подтверждением.
Хорошая схема начинает с режима наблюдения. Команда проверяет шум, нормальные сценарии и аварийный откат, затем переводит отдельные действия в блокировку. Так меньше риск сломать рабочий процесс и больше шанс получить доверие владельцев продукта.
- режим наблюдения перед блокировкой;
- запрет по умолчанию для опасных действий;
- разделение данных, инструкций и действий;
- ручное подтверждение для необратимых операций;
- лимиты на объём и скорость запросов;
- автоматический отзыв ключей при аномалии;
- проверка исключений по сроку и владельцу.
Как измерять результат
Польза видна не в количестве правил, а в скорости и качестве реакции. Если после внедрения контроля инцидент разбирается быстрее, а доказательства собираются без ручного поиска по разным системам, контроль работает.
Метрики должны быть понятны SOC, AppSec и владельцу продукта. Технический сигнал сам по себе малоценен, если не ясно, кто принимает решение и что происходит дальше.
- время от сигнала до первичного разбора;
- доля событий с полным набором журналов;
- число подтверждённых инцидентов;
- количество постоянных исключений;
- доля заблокированных опасных действий;
- скорость отзыва ключей и сессий;
- число проверенных сценариев перед релизом.
Карта ответственности
SOC отвечает за сигнал, корреляцию и расследование. AppSec проверяет код, права и границы приложения. Владелец данных определяет допустимость доступа. Инфраструктура управляет сетью, ключами и журналами. Руководитель риска принимает остаточный риск и исключения.
Без такой карты первый инцидент превращается в спор о владельце. Поэтому роли фиксируются вместе с архитектурой и пересматриваются после каждого изменения в AI-функции.
- SOC собирает доказательства и задаёт приоритет;
- AppSec проверяет границы и тесты;
- владелец данных оценивает чувствительность;
- инфраструктура меняет ключи и сеть;
- юридическая функция оценивает уведомления;
- руководитель риска утверждает исключения.
Приёмочные критерии перед релизом
Перед выпуском функции AppSec фиксирует критерии, которые нельзя обойти красивым ответом модели. Если внешний контент попросил изменить правила, приложение должно сохранить этот фрагмент как данные и не расширять действие. Если модель предложила вызвать инструмент вне задачи, слой политики должен остановить вызов и записать причину.
Отдельно проверяется объяснимость. В журнале должно быть видно, почему действие разрешено: какая пользовательская задача была исходной, какой источник был прочитан и какой ресурс затрагивается. Без этого невозможно доказать, что приложение действовало в границах намерения пользователя.
- внешний контент не меняет правила;
- недоверенная инструкция не вызывает инструмент;
- доступ к данным проверяется до действия;
- отказ политики попадает в журнал;
- пользователь видит источник решения;
- чувствительное действие требует подтверждения;
- регрессионный тест запускается перед релизом.
