Сегодня CISO нередко просят согласовать применение агентного ИИ, о котором ещё квартал назад никто всерьёз не говорил. Совет директоров ждёт скорости. Бизнес — тоже. А где-нибудь в подразделении уже, возможно, подключили агента к корпоративному сервису, не дожидаясь формального разрешения.

Полный запрет обычно не решает проблему: он толкает команды к теневым внедрениям, где нет ни журналов событий, ни понятного владельца, ни аварийного выключателя. Но и безоговорочное «да» — плохая сделка. Один заметный инцидент способен надолго испортить отношение компании к ИИ.

Задача службы безопасности не в том, чтобы добиться мифического нулевого риска. Её работа — сделать риск понятным, ограниченным и управляемым. Тогда организация может внедрять ИИ-агентов и автоматизацию осознанно, а не украдкой и на свой страх и риск.

Внешние угрозы и внутренние риски агентного ИИ

Современные модели сокращают путь от обнаруженной уязвимости до рабочего эксплойта. Они умеют находить дефекты, которые годами лежали в коде незамеченными, связывать несколько слабостей в одну цепочку атаки и ускорять анализ больших массивов технических данных. Для программ GRC это означает простую, хотя и неприятную вещь: окно для устранения уязвимостей становится всё уже.

Однако в повседневной работе CISO чаще сталкивается с другой стороной вопроса — внутренними рисками. Агент получает доступ к почте, документам, CRM, репозиториям, облаку и корпоративным чатам. Он связывает системы, которые прежде были разнесены. Удобно? Очень. Но именно здесь легко получить утечку данных или непредусмотренное действие от имени пользователя.

Отдельная головная боль — инъекции инструкций в промпт. Злоумышленник прячет директиву в письме, документе, веб-странице или другом контенте, который читает агент. Если защита не сработала, агент может последовать чужой инструкции вместо задачи пользователя. Модели становятся устойчивее, но риск пока не исчез. Увы, волшебной кнопки тут нет.

Четыре вопроса для оценки агентной системы

Перед запуском любого сценария полезно провести короткую, но честную проверку. Не ради бумаги в папке, а чтобы решение действительно изменилось.

1. Какой недоверенный контент получает агент? Это всё, что злоумышленник способен правдоподобно создать или изменить: внешняя почта, открытый веб, документы контрагентов, публичные репозитории. Если такого контента нет, специфический риск агента обычно невысок.
2. Что агент вправе делать и от чьего имени? Чтение — не то же самое, что запись. Выполнение кода, сетевые запросы, изменение прав доступа и работа с внешними системами резко расширяют поверхность атаки. Не менее важно понимать, какая идентичность используется для каждого действия.
3. Каков радиус поражения? Что произойдёт, если агент ошибётся или будет введён в заблуждение: появится неудобный черновик, раскроется один файл или пострадают данные всей компании? Условная формула проста: охват умножается на тяжесть последствий.
4. Есть ли наблюдаемость? Должна быть возможность отличить действие агента от действия сотрудника, увидеть его в SIEM и быстро восстановить ход действий на конкретном шаге, а не гадать задним числом.

После такой оценки действует принцип минимальной агентности: агенту выдают только те полномочия, без которых задача не будет выполнена. Ни на грамм больше. Хорошая практика — начинать с небольшой группы пользователей, наблюдать за телеметрией, уточнять политики и лишь затем расширять доступ.

Для сложных сценариев особенно важна архитектура ИИ-агентов: разделение ролей, изоляция инструментов, контролируемые контуры данных и чёткая модель идентичности должны быть заложены до запуска, а не после первого инцидента.

Идентичность агента: два края спектра

На одном конце находится сервисная учётная запись: узкая, одноцелевая идентичность с минимальными привилегиями. Например, агент может читать обезличенные логи, создавать канал для реагирования на инцидент и готовить черновик отчёта. Он не действует от имени конкретного сотрудника и не получает его полный набор прав.

На другом конце — персональный агент, работающий от имени человека. Сотрудник использует чат или агентную среду, авторизует доступ к нужным системам и отвечает за итоговую операцию так же, как отвечал бы при ручной работе.

Самая скользкая зона — посередине. Это случаи, когда агент переносит делегированную идентичность сотрудника в системы, за которыми тот уже не наблюдает. Тогда ответственность размывается, а расследование становится вязким и неприятным. Агент, ушедший от намерений организации, по эффекту мало отличается от инсайдера с легитимным доступом.

Проблема ещё и в скорости. На локализацию инсайдерских инцидентов у организаций часто уходят недели. Агент же способен сделать сотни операций за минуты. Значит, программа управления рисками должна уметь замечать отклонения почти в реальном времени — дни здесь просто не подходят.

Практический пример: агент реагирования на инциденты

Представим дежурство в два часа ночи. Срабатывает оповещение, создаётся канал инцидента, собираются специалисты, начинается поиск причины. Процесс знакомый и довольно изматывающий. Часть рутины вполне можно поручить агенту, если не открыть ему слишком широкую дверь.

В безопасном варианте такому агенту доступны только три вещи: чтение журналов без персональных данных, создание защищённого канала в корпоративном мессенджере и подготовка документа для разбора инцидента. Он не редактирует инфраструктуру, не удаляет данные, не меняет права и не отправляет сведения наружу.

• Недоверенный контент: отсутствует либо строго ограничен внутренними источниками.
• Действия: чтение разрешено, запись допускается только в новые документы и сообщения внутри защищённого контура.
• Радиус поражения: даже неудачный результат ограничен несколькими строками логов в уже закрытом канале.
• Наблюдаемость: каждый вызов инструмента фиксируется в SIEM.

Любопытный эффект проявляется по мере роста способностей моделей. Агент, которому не добавляли ни новых инструментов, ни разрешений, может сам заметить, что для устранения причины полезно привлечь другого агента — например, подготовить исправление кода для последующего ревью. Это не обязательно нарушение. Но это уже новая цепочка действий, о которой надо думать заранее.

Именно поэтому ограничения должны опираться не на предположение «модель пока так не умеет», а на реальные технические границы: отдельные учётные записи, минимальные права, изолированное выполнение, проверка человеком и полная телеметрия. В мультиагентных системах это особенно критично: взаимодействие агентов способно расширить радиус поражения быстрее, чем успеет обновиться регламент.

Какие средства контроля нужны персональным агентам

Персональная агентная среда удобна, потому что помогает сотруднику работать с файлами, браузером, корпоративными сервисами и коннекторами. Но удобство не должно превращаться в безнадзорность. Ниже — базовый набор требований для корпоративного развёртывания.

Идентичность из IdP. Учётная запись агента должна создаваться, изменяться и отзываться через тот же провайдер идентификации, что и остальные корпоративные учётные записи. SAML, OIDC, SCIM, группы и ролевой доступ — это не бюрократический декор, а нормальная основа контроля.

Разрешённый список коннекторов. Администратор определяет, к каким системам агент вообще может обращаться. Пользователь затем отдельно авторизует свой доступ. Если агент читает веб-страницы или внешнюю почту, разумная настройка по умолчанию — разрешать подготовить черновик письма, но не отправлять его без участия человека.

Разрешения на уровне действия. Недостаточно включить или выключить целый коннектор. Нужна возможность разрешить поиск и чтение, но запретить удаление; позволить создать документ, но не публиковать его автоматически. Если сценарий «удалить рабочую базу данных» вызывает у вас бессонницу — операции удаления вообще не должно быть среди инструментов агента. Всё просто. Почти.

Изолированная среда выполнения. Рабочее окружение агента не должно содержать секреты, которые можно украсть. Временные песочницы, прокси для вызова коннекторов и разделение с учётными данными рабочей среды снижают вероятность эксфильтрации. Для задач, связанных с поиском по внутренним знаниям, документами и контекстом, полезны отдельные подходы к агентной памяти и RAG, где источники, права доступа и жизненный цикл данных контролируются явно.

Контроль исходящего трафика. Весь трафик из среды агента должен проходить через прокси, который агент не может обойти или перенастроить. Разрешаются только заранее определённые адресаты. Даже если агент поддался инъекции инструкций, злоумышленнику будет сложнее вывести данные за пределы контура.

Телеметрия в SIEM. Поток событий через OpenTelemetry или аналогичный механизм должен содержать сведения о вызове инструмента, коннекторе, параметрах, результате, длительности, пользователе и сессии. При этом нужно заранее решить, допустимо ли передавать в SIEM содержимое промптов: требования к хранению и конфиденциальности у компаний различаются.

Единый выключатель. Организации нужен способ мгновенно отключить коннекторы и активные сессии, а также более точные меры: отозвать доступ у группы или запретить операции записи в конкретной интеграции. План реагирования должен быть подготовлен заранее. Во время инцидента сочинять его поздновато.

Управление не обязано тормозить бизнес

Нередко CISO слышит одну и ту же жалобу: руководство требует ускорения, а управление рисками превращается в узкое горлышко. Такое бывает. Но неизбежностью это не является.

Команды GRC могут применять агентов для обработки опросников по безопасности, анализа ответов поставщиков, отслеживания изменений у субподрядчиков и подготовки материалов для оценки рисков. Важно, чтобы автоматизация не подменяла решение уполномоченного человека, а помогала ему быстрее получить нужные факты.

• Начните с живого реестра рисков. Реестр, который пересматривают раз в квартал, плохо подходит для систем, меняющихся каждую неделю. Оценку стоит встроить в процесс проверки безопасности и по возможности автоматизировать сбор доказательств.
• Поймите, кто строит агентов и зачем. Если одобренный путь слишком медленный, сотрудники найдут обходной. А значит, безопасная внутренняя платформа для создания агентов часто полезнее, чем бесконечные запреты.
• Не убирайте человека из контура ответственности. Принятие риска, согласование исключений и переговоры с поставщиками остаются решениями людей, наделённых соответствующими полномочиями.

Вопросы соответствия ИИ требованиям стоит увязывать с действующими процессами ISO 27001, ISO 42001, управления поставщиками и защиты данных. Тогда новая агентная система не живёт в отдельной вселенной, а входит в понятный корпоративный контур.

Проектируйте защиту с запасом на развитие моделей

Программа безопасности, рассчитанная исключительно на способности модели сегодняшнего дня, рискует устареть ещё до полноценного запуска. Через полгода агент может стать самостоятельнее, лучше планировать последовательности шагов и находить неожиданные маршруты к цели.

Поэтому защиту стоит строить вокруг устойчивых принципов: идентичность, минимальные привилегии, сегментация, наблюдаемость, изоляция и быстрое реагирование. Хрупкие запреты, завязанные лишь на текущую слабость модели или на хитро сформулированный промпт, долго не живут.

Агенты с собственными учётными записями и длительными рабочими процессами уже становятся обычной практикой. Управлять ими нужно примерно так же, как сотрудниками с доступом к системам: выдавать ровно необходимые права, наблюдать за действиями и быстро реагировать на отклонения.

С чего начать прямо сейчас

1. Выберите наиболее востребованный внутренний сценарий. Проверьте его по четырём вопросам. Ищите условия, при которых его можно безопасно одобрить, а не повод для автоматического отказа.
2. Проверьте технологический стек. Спросите у команд, поставщиков агентов, IdP и SIEM, какие механизмы идентичности, аудита, изоляции, ограничения коннекторов и аварийного отключения они могут показать в работе уже сейчас.
3. Определите границу доверия. Зафиксируйте, какие данные и источники считаются недоверенными. После этого многие решения — от политик коннекторов до правил DLP — станут куда яснее.

Ожидание нулевого риска легко превращается в бесконечное ожидание. Веб останется враждебной средой, модели будут развиваться, а давление со стороны бизнеса никуда не денется. Выиграют организации, которые уже сегодня научатся честно оценивать риски агентного ИИ, ограничивать их техническими средствами и принимать решения без лишней паники.