Команда внедряет AI-ассистента в рабочий продукт и считает, что опасность находится только в пользовательских запросах. Через несколько недель выясняется, что одна малозаметная настройка позволяет менять поведение ассистента, подключать инструмент или передавать внутренний контекст туда, куда он не должен попадать. Такой дефект выглядит как конфигурационная мелочь, но по последствиям напоминает бэкдор.
Опасность скрытых настроек в том, что они находятся между кодом и политикой. Разработчик видит удобную возможность расширения, владелец продукта видит быстрый способ добавить функцию, а AppSec узнаёт о ней только после инцидента. В AI-приложениях это особенно рискованно, потому что настройки часто управляют не только интерфейсом, но и тем, какие данные модель видит и какие действия может инициировать.
Проверка должна начинаться с вопроса: какие поля конфигурации могут изменить системный контекст, маршрутизацию запроса, список инструментов, уровень доступа или сохранение данных. Если такое поле доступно через административную панель, переменную среды, файл проекта или пользовательский шаблон, оно становится частью поверхность атаки.
Цель AppSec — сделать скрытые настройки видимыми, ограниченными и проверяемыми. Для этого нужны схема конфигурации, список опасных параметров, запрет произвольного кода и тесты на внедрение инструкций.
Какие настройки считать опасными
Опасной становится любая настройка, которая меняет границу доверия. Это не только прямой запуск кода. Риск создают дополнительные источники данных, расширенные инструменты, изменение роли модели, отключение фильтра, сохранение истории и передача внутреннего контекста во внешний сервис.
Если настройка влияет на то, что модель считает инструкцией, её нельзя оставлять без проверки. Пользовательский текст, документ или запись в базе не должны становиться системной командой.
- поле системной подсказки;
- список подключённых инструментов;
- разрешение на внешние вызовы;
- путь к секретам и токенам;
- режим сохранения истории;
- источник контекста для RAG;
- параметры фильтрации вывода.
Проверка конфигурации перед релизом
Перед релизом AppSec должен получить не только код, но и итоговую конфигурацию. Именно в ней часто включаются опасные возможности. Проверка включает сравнение настроек с эталоном, поиск неожиданных полей и запуск негативных тестов, где вредный текст пытается стать инструкцией.
Важно проверять разные пути изменения конфигурации. Если панель защищена, но тот же параметр можно передать через файл, переменную среды или API, контроль неполный.
- создать схему допустимых параметров;
- запретить неизвестные поля;
- сравнивать релизную конфигурацию с эталоном;
- проверять панель, файл и API отдельно;
- логировать изменение каждого опасного параметра;
- требовать второго подтверждения для новых инструментов.
Порядок внедрения контроля
Защитный сценарий лучше начинать с режима наблюдения. Команда собирает факты, сравнивает вывод модели с ручной проверкой и только после этого включает автоматические действия. Любое изменение доступа, маршрута данных, политики или сетевого правила должно иметь владельца и журнал решения.
Важно заранее определить, какие события считаются нормой, а какие требуют остановки. Если контроль реагирует только после утечки или выполнения команды, он превращается в отчётность, а не в защиту.
- назначить владельца данных и владельца системы;
- включить полное журналирование входов и действий;
- разделить чтение, анализ и исполнение;
- установить лимиты на сетевые и облачные операции;
- проверять исключения каждую неделю;
- фиксировать версию политики и модели.
Какие журналы собирать
Для расследования нужны не только ошибки приложения. Нужно видеть, какой пользователь инициировал действие, какой сервисный аккаунт выполнил его, какой контекст получила модель, какие поля были скрыты и какой контроль разрешил или отклонил операцию.
Без этих данных команда видит только итог: запрос прошёл или не прошёл. Этого мало для разбора инцидента, потому что вредный контекст может находиться не в команде, а в документе, панели, комментарии, метаданных или внешнем источнике.
- user_id и роль инициатора;
- служебная_учётная_запись и область прав;
- source_system и источник данных;
- action_type и результат действия;
- policy_id и policy_version;
- model_version и режим запуска;
- risk_score и причина решения.
Проверка после запуска
После запуска контроль нужно проверять не презентацией, а повторяемыми тестами. Команда создаёт безопасные сценарии, где система должна отказаться, запросить подтверждение или ограничить объём данных. Если тест проходит только потому, что модель вежливо ответила отказом, но инструмент всё ещё может выполнить действие, защита не готова.
Отдельно проверяется откат. Владелец должен понимать, как остановить процесс, отозвать ключ, закрыть доступ, удалить ошибочный вывод и сохранить доказательства для разбора.
- проводить негативные тесты перед релизом;
- сравнивать ответ модели с фактическим действием;
- проверять, что секреты не попадают в контекст;
- включать аварийную остановку;
- сохранять доказательства для аудита;
- обновлять тесты после каждого инцидента.
Разбор спорного события
Отдельный процесс нужен для случаев, когда контроль сработал частично. Например, система заблокировала действие, но уже успела передать модели лишний контекст, открыть сетевое соединение или показать оператору опасную рекомендацию. Такие события нельзя считать успешной защитой: они показывают, где граница доверия проведена слишком поздно.
Разбор должен быть коротким и повторяемым. Команда фиксирует исходный запрос, источник данных, задействованный сервис, причину решения и недостающий контроль. После этого создаётся маленькое изменение: новое правило, дополнительная проверка, ограничение прав или тест, который больше не позволит повторить тот же сценарий.
- отделить заблокированное действие от утечки контекста;
- указать владельца процесса и владельца данных;
- проверить, какие поля увидела модель;
- сравнить фактические права с требуемыми;
- создать тест на повторение сценария;
- закрыть исключение сроком и владельцем;
- обновить журнал рисков и контрольный лист.
Минимальная карта ответственности
Даже хорошее техническое правило не работает, если никто не отвечает за его поддержку. Для каждой AI-системы нужно определить владельца модели, владельца данных, владельца интеграции и команду реагирования. Эти роли могут принадлежать разным подразделениям, но решение о риске должно быть видимым.
Карта ответственности особенно важна при инцидентах. SOC видит аномалию, AppSec понимает конфигурацию, владелец продукта знает допустимый сценарий, а юристы оценивают последствия раскрытия данных. Если эти роли не связаны заранее, расследование задерживается.
- владелец модели отвечает за версию и ограничения;
- владелец данных определяет допустимый контекст;
- владелец интеграции отвечает за инструменты и API;
- SOC собирает события и корреляции;
- AppSec проверяет конфигурацию и код;
- руководитель риска принимает спорные исключения.
