Публичный агент первичной сортировки удобен для разбора обращений, но он работает с недоверенным вводом. Если такой агент может запустить привилегированный процесс исправления кода, появляется риск межагентной эскалации.
Злоумышленник может разместить инструкцию в обращение, комментарии или описании ошибки и попытаться заставить привилегированный процесс выполнить действие, которое не проходило независимую проверку. Поэтому процесс должен быть построен как управляемый контур: ограниченный доступ, журналирование, проверяемые источники, ручное подтверждение для важных действий и понятный способ остановить ошибочную автоматизацию.
Практическая задача
Практическая задача — разделить публичного и привилегированного агента: первый только классифицирует и собирает факты, второй работает после проверки, с ограниченным доступом и через обычный проверка. На старте нужно выбрать один сценарий и описать, какие данные разрешены модели, какие действия запрещены, кто утверждает результат и какие признаки считаются ошибкой.
Для защитной команды важна не сама возможность применить AI, а воспроизводимый порядок работы. Один аналитик, разработчик или владелец сервиса должен получить такой же формат ответа, что и другой, иначе автоматизация быстро превращается в набор разрозненных подсказок.
Кейс
Кейс: в обращение появляется текст, который просит агента изменить файл сборки. Публичный агент помечает обращение как подозрительное и передаёт его человеку, а не запускает исправление с правами записи. Команда не разрешает модели самостоятельно менять рабочую среду. AI готовит сводку, гипотезу, черновик запроса или проект изменения, а человек проверяет доказательства и принимает решение.
В таком подходе даже неверный ответ модели не становится инцидентом сам по себе. Ошибка остаётся внутри проверочного контура: её можно увидеть, отклонить, разобрать и добавить в базу примеров для следующей проверки.
Архитектура контроля
Архитектура должна иметь недоверенную зону для публичного ввода, проверочный слой, зону привилегированных действий и журнал переходов между зонами. Отдельно фиксируется граница между чтением, анализом и действием. Чтение даёт контекст, анализ помогает найти связи, а действие меняет состояние системы. Последний этап должен иметь отдельную защиту.
Журнал должен хранить запрос, использованные источники, вывод модели, решение проверяющего, итоговое действие и причину отклонения. Это нужно не только для аудита, но и для улучшения шаблонов, ограничения доступа и обучения команды.
Порядок внедрения
Первый шаг — провести инвентаризацию данных и инструментов, которые попадают в сценарий. Второй шаг — определить владельца риска. Третий шаг — подготовить шаблон запроса и формат ответа. Четвёртый шаг — провести пилот на ограниченном наборе задач.
В пилоте проверяются три свойства: модель использует только разрешённые источники, отделяет факты от предположений и не просит лишний доступ. Если любое свойство нарушается, сценарий не расширяется, пока не будет добавлен технический или организационный контроль.
Контроли безопасности
Нужны запрет прямого запуска привилегированного процесс из внешнего текста, независимое подтверждение, отдельные токены, минимальные права, запрос на слияние вместо прямого коммита и проверка новых зависимостей. Дополнительно нужны лимиты времени, лимиты объёма данных, маскирование чувствительных полей, список разрешённых инструментов и сигнал при попытке выйти за границы сценария.
Для важных действий полезно требовать второй источник: запись в журнале, конфигурацию, результат сканера, заявку владельца сервиса или подтверждение аналитика. Один ответ модели не должен быть единственным доказательством.
Практический пример
Например, публичный агент может поставить метку “нужна проверка безопасности”, но не может открывать ветку, менять код или вызывать секреты без решения человека. В шаблоне запроса заранее указываются цель, источники, запреты, формат ответа и критерии остановки. Это снижает случайность и помогает сравнивать результаты разных запусков.
После пилота команда сравнивает новый порядок с обычной работой: сколько времени ушло до первой гипотезы, сколько выводов подтвердилось, сколько рекомендаций отклонено и сколько раз модель запросила лишний доступ.
Типовые ошибки
Ошибка — считать обращение обычной задачей и разрешить агенту выполнять инструкции из описания как внутренние команды. Частая ошибка — измерять успех количеством сгенерированных ответов. Для безопасности важнее подтверждённые выводы, отсутствие утечек данных и понятный владелец каждого действия.
Нельзя оставлять AI-процесс без владельца. Если непонятно, кто отвечает за проверку ответа, кто утверждает действие и кто исправляет ошибку, автоматизация становится организационным риском.
Мини-чек-лист
Перед запуском проверьте семь пунктов: область применения, владелец, разрешённые данные, запрещённые действия, журналирование, ручное подтверждение, план остановки. Если хотя бы один пункт не описан, сценарий должен оставаться в тестовом режиме.
Межагентная безопасность держится на простой границе: недоверенный агент сообщает, привилегированный агент действует только после независимой проверки. Безопасное применение AI строится не на полном доверии к модели, а на ограничениях, проверке и ответственности. Именно такая схема позволяет получать пользу от автоматизации без потери контроля.
Проверка перед рабочим запуском
Перед внедрением сценарий нужно прогнать на ограниченном наборе данных. В проверке участвуют владелец процесса, специалист безопасности и будущий исполнитель. Они оценивают, какие сведения получает модель, какие действия ей доступны, где нужен человек и какие ошибки считаются критичными. Результат фиксируется в короткой карточке риска.
Особое внимание стоит уделить недоверенному вводу. Любой внешний текст, страница, обращение, журнал, комментарий или файл может содержать инструкцию, которую модель ошибочно воспримет как команду. Поэтому шаблон должен явно разделять данные для анализа и команды, которые разрешено выполнять.
Разбор отказов и ложных выводов
Ошибки AI-сценария нужно разбирать так же дисциплинированно, как ошибки обычного процесса безопасности. Если модель дала неверный вывод, команда проверяет источник данных, шаблон запроса, доступные инструменты, ограничения, решение проверяющего и итоговое действие. Это помогает понять, нужно ли менять технический контроль или достаточно улучшить регламент.
Полезно хранить примеры отклонённых рекомендаций: ложные гипотезы, запросы на лишний доступ, неверные связи между событиями, попытки использовать запрещённые данные и опасные действия. Такая база быстро становится практическим учебным материалом для команды.
Метрики пользы и риска
Оценивать сценарий нужно по двум группам метрик. Первая показывает пользу: время до первой гипотезы, доля подтверждённых выводов, снижение ручной рутины, скорость подготовки задачи и качество объяснения для владельца. Вторая показывает риск: ложные рекомендации, попытки выйти за границы задачи, запросы на лишние данные и действия, остановленные проверяющим.
Если польза растёт, но риск не контролируется, сценарий нельзя расширять. Если риск низкий, но практической пользы почти нет, его тоже не стоит оставлять. Рабочий вариант находится там, где AI ускоряет повторяемые шаги, а человек сохраняет контроль над решением.
Роли и ответственность
Минимальная схема включает владельца процесса, владельца технического контроля и проверяющего результат. Владелец процесса определяет цель и допустимое влияние на бизнес. Владелец контроля отвечает за ограничения, журналы и интеграции. Проверяющий подтверждает факты перед действием.