Компания утверждает правило: AI-система не должна запускать кибератаки, повышать собственный доступ, обходить ограничения или выполнять действия без разрешения. На бумаге это выглядит убедительно, но в рабочей среде вопрос другой: где именно стоит запрет, кто его проверяет и что произойдёт, если модель всё же предложит опасное действие.
Системная инструкция сама по себе не является контролем безопасности. Модель может ошибиться, получить вредный контекст, столкнуться с двусмысленной задачей или быть встроенной в процесс, где фактическое действие выполняет не она, а подключённый сервис. Поэтому запреты нужно переносить из текста политики в IAM, сетевые ограничения, шлюзы действий, журналы и процедуры подтверждения.
Практический риск возникает, когда AI получает доступ к инструментам: терминалу, облачному API, системе заявок, репозиторию, почте или среде управления инцидентами. Даже если модель обучена не выполнять опасные команды, инфраструктура должна считать её ненадёжным инициатором и проверять каждое действие отдельно.
Цель статьи — показать, как построить слой исполнения политики: какие действия запрещены всегда, какие требуют ручного подтверждения, какие разрешены только в песочнице и какие должны оставлять доказательства для аудита.
От документа к исполнение политики
Политика должна иметь техническое отражение. Если написано, что AI не может повышать доступ, то сервисный аккаунт AI не должен иметь право назначать роли. Если написано, что AI не может запускать активное тестирование, то сеть и шлюз инструментов должны блокировать такие действия вне утверждённого полигона.
Удобно разделить требования на три уровня: декларация, технический запрет и контроль события. Декларация объясняет цель, запрет не даёт выполнить опасное действие, а контроль события показывает, что попытка была замечена и разобрана.
- запретить сервисному аккаунту менять роли;
- разнести чтение, анализ и действие по разным токенам;
- поставить шлюз перед каждым внешним инструментом;
- требовать ручное подтверждение для высокорисковых операций;
- логировать отклонённые попытки;
- проверять политику тестовыми сценариями.
Какие действия считать опасными
Опасным считается не только очевидный запуск атаки. Критичными становятся попытки расширить доступ, отключить журналирование, изменить правила фильтрации, выполнить запрос к внешнему адресу, выгрузить секреты или создать новый ключ. AI может формулировать это как помощь, оптимизацию или диагностику, поэтому правило должно смотреть на фактическое действие.
Для каждого действия нужен класс риска. Низкий риск можно разрешить автоматически, средний риск требует подтверждения владельца процесса, высокий риск выполняется только в изолированной среде или отклоняется без исключений.
- изменение ролей и политик доступа;
- создание ключей и токенов;
- отключение журналов или алертов;
- доступ к секретам и персональным данным;
- запуск сетевого сканирования;
- изменение финансового или клиентского статуса;
- выгрузка данных за пределы контура.
Как проверять работу запрета
Технический контроль нужно проверять негативными тестами. Команда заранее создаёт набор задач, в которых модель должна отказаться, запросить подтверждение или предложить безопасную альтернативу. Важно проверять не только ответ модели, но и фактический результат в системе действий.
Если модель написала безопасный ответ, но подключённый инструмент всё равно выполнил рискованную операцию, контроль провален. Поэтому тест должен идти по всей цепочке: запрос, решение, инструмент, журнал, алерт и откат.
- создать тесты на повышение доступа;
- проверять попытки отключить журналы;
- имитировать вредный контекст в документе;
- сравнивать ответ модели и действие инструмента;
- фиксировать результат в журнале аудита;
- повторять тест после обновления модели.
Как внедрять без лишнего риска
Начинать нужно с режима наблюдения. Команда собирает события, сравнивает решения модели с ручным разбором и только после этого включает частичную автоматизацию. Любое действие, которое меняет доступ, блокирует пользователя, раскрывает данные или влияет на деньги, должно иметь ручное подтверждение или заранее утверждённую политику.
Владелец процесса должен видеть не только итоговое решение, но и доказательства. Если модель рекомендует блокировку, повышение риска или отклонение действия, в карточке события должны быть исходные сигналы, версия правила, ссылка на журнал и причина уверенности.
- определить владельца процесса и владельца данных;
- включить режим наблюдения на первые недели;
- сохранить версии правил и шаблонов;
- запретить скрытые исключения без срока;
- проводить выборочную проверку решений;
- назначить процедуру отката и пересмотра.
Контроль качества после запуска
После запуска нельзя измерять успех только числом срабатываний. Важно понять, сократилась ли неопределённость, уменьшилась ли ручная работа и не появились ли решения, которые никто не может объяснить. Если объяснение отсутствует, автоматизация становится новым источником риска.
Отдельно нужно следить за дрейфом. Поведение пользователей, атакующих и сервисов меняется, поэтому правила, признаки и пороги должны пересматриваться. Иначе контроль быстро превращается в устаревшую формальность.
- доля событий с полным набором журналов;
- время до первичного решения;
- число ручных откатов;
- доля спорных решений;
- количество исключений без владельца;
- частота пересмотра правил.
Разбор спорного события
Когда запрет сработал, событие нельзя просто закрыть как «модель отказалась». Нужно понять, какой слой остановил действие: сама модель, шлюз инструмента, IAM, сетевой фильтр или ручное подтверждение. Это помогает отличить хороший контроль от удачного совпадения.
В карточке спорного события фиксируется исходная задача, запрошенное действие, фактический запрет, владелец решения и риск, который был предотвращён. Если запрет сработал слишком поздно, команда меняет порядок проверок: сначала политика, затем инструмент, затем действие.
- сохранять исходный запрос без секретов;
- указывать слой, который остановил действие;
- отмечать риск и затронутый ресурс;
- проверять, не было ли обходного пути;
- обновлять тестовый набор после каждого спора;
- добавлять новый запрет в шлюз действий.
