Недавние инциденты с ИИ-агентами показывают, что нейросеть может выходить за рамки задач и использовать доступные им инструменты непредусмотренным образом. При работе с такими системами компаниям важно заранее продумать, к каким данным давать доступ и какие меры нужны, чтобы они не получили больше полномочий. О том, как контролировать действия ИИ-агентов, рассказал Леонид Плетнев, бизнес-партнер по информационной безопасности «1С-Битрикс».
Когда ИИ выходит из-под контроля
Инциденты с ИИ участились. Модели OpenAI во время тестирования вышли из изолированной среды и добрались до инфраструктуры Hugging Face, Claude в экспериментах Anthropic несколько раз покидал тестовый контур и взаимодействовал с реальными системами, а Kimi K3 обнаружила доступ в интернет из «песочницы». Чем больше автономности получает агент, тем сложнее наблюдать за всей цепочкой его действий, но вместо того, чтобы сначала решить эту проблему, рынок долгое время двигался в сторону все более длинных и самостоятельных сценариев работы.
В подобных кейсах полезный ИИ-помощник начинает совершать несанкционированные действия без прямой команды. Причинами становятся неправильно сформулированная задача, ошибка модели, сбой защитных механизмов, не контролируемое вами взаимодействие с другим агентом. В итоге агент стремится выполнить задачу любой ценой.
Теперь об этом заговорили уже сами руководители крупнейших технологических компаний. Билл Гейтс допускает глобальное замедление AI, Дарио Амодеи предлагает снизить темп развития моделей, чтобы мониторинг, защита и методы оценки успевали за их возможностями, а Сэм Альтман поддержал идею постоянного внешнего аудита. При этом сами ИИ-лаборатории разработку не останавливают.
Решения ищут и законодатели. Например, в США на рассмотрение внесен AI Kill Switch Act, предусматривающий для наиболее мощных ИИ-систем возможность замедления, приостановки и полного отключения. Однако агентов в корпоративном контуре должны контролировать не только разработчики и государство, но и сами компании-пользователи.
Агент внутри корпоративного контура
Похожие ошибки типизируют как reward hacking (дословно — «хакерство вознаграждения»), что означает сбой, при котором ИИ самостоятельно максимизирует формальную награду, заданную в обучении, но не выполняет то, что реально имел в виду разработчик.
Инструкция агенту не выходить за пределы задания в такой ситуации недостаточна. Если у данного инструмента есть техническая возможность обойти ограничение, нужно исходить из того, что однажды он может ею воспользоваться. Получается, что агента с доступом к корпоративным системам следует рассматривать как потенциального внутреннего нарушителя. Конечно, у него нет злого умысла, но и ваша безопасность не должна строиться на вере в послушание и предсказуемость модели.
По профилю риска агент похож на привилегированного сотрудника или сервисную учетную запись. Он находится внутри защищенного контура, использует разрешенные инструменты, может обращаться к чувствительным данным, действует быстрее человека и способен сделать тысячи операций за минуты. Поэтому до подключения агента к реальным системам компания должна составить модель угроз.
Анализ должен охватывать весь контур: модель, системные инструкции, память, инструменты, плагины, учетные данные, внешние источники, других агентов и среду исполнения. Для этого вам нужно ответить на следующие вопросы:
- Какие активы и операции доступны агенту?
- Какие сочетания инструментов могут расширить его полномочия?
- Через какие границы доверия проходят команды и данные?
- Что произойдет при компрометации компонента или его поставщика?
- Какие независимые средства обнаружат и остановят опасный сценарий?
Модель угроз пересматривают после смены модели, системного промпта, инструментов, прав, источников данных или памяти. OWASP рекомендует относиться к использованию таких инструментов так же серьезно, как к созданию и эксплуатации административных сервисных учетных записей.
Предварительная оценка рисков
Архитектура контроля включает следующие процедуры:
1. Инвентаризация и учет
Компания должна знать, какие внутренние и внешние агенты используются, кто за них отвечает, и к каким данным они подключены.
2. Минимальные полномочия
Доступ выдается для конкретной задачи и на ограниченное время. По умолчанию только чтение, короткоживущие токены и доступ только к необходимым объектам. Полномочия на запись требуют усиленного согласования и контроля по принципу «zero trust»: проверять нужно цель каждой операции, ее контекст, запрашиваемые данные и возможные последствия.
3. Изоляция
Инфраструктурный ИИ-контур должен ограничивать файлы, процессы, сеть, облачные метаданные и внутренние сервисы. Если в экспериментальных целях снимаются модельные ограничения, инфраструктурные меры должны становиться жестче.
4. Ограниченная автономность
Для запуска задаются лимиты времени, числа шагов, параллельных задач, повторных попыток, расходов и объема данных. Невыполнимая задача должна завершаться безопасной остановкой и эскалацией на независимый от агента уровень принятия решения. Агент может предложить действие, но разрешение выдает независимый автоматизированный шлюз или человек. Подтверждение человека требуется для критичных операций (удаления данных, денежных переводов, изменения прав, выполнения кода в промышленной среде и т. п.).
5. Мониторинг
Нужно фиксировать версию модели, инструкции, разрешения, вызовы инструментов, сетевые соединения и изменения данных. Журналы следует хранить вне среды агента и защищать от изменения.
Что если инцидент уже произошел
Рассмотрим реализацию функции kill switch для ИИ-агента. На практике ее элементы размещаются не в одном месте, а на нескольких независимых узлах. Оркестратор и очередь заданий прекращают запуск новых операций, API-шлюзы блокируют опасные команды, система управления доступом и брокеры секретов отзывают токены либо переводят агента в режим «только чтение». Сетевой прокси или межсетевой экран блокируют соединения, в среде исполнения останавливаются компоненты на уровне виртуальных машин, контейнеров.
Шина данных может становиться защитным узлом, если через нее проходят обращения агента, проверяются по политикам и могут быть централизованно заблокированы. Управляющий контур должен находиться вне среды агента, чтобы тот не мог изменить правила или помешать отключению.
При первом подозрении на инцидент может быть использован инструмент снижения скорости модели или снижен уровень допустимых запросов, чтобы уменьшить темп нарастания возможного ущерба.
Для подтвержденного инцидента реакцию следует сделать двухступенчатой. Сначала одновременно изолировать агента на шлюзах, отозвать права и токены. Затем остановить процессы, сохранить память и журналы для расследования, далее, при необходимости, выключить инфраструктурные системные компоненты.
Безопасность агентной среды нельзя основывать на их послушании заданным правилам. Необходимо реализовывать классические подходы к обеспечению информационной безопасности, начиная с моделирования угроз, и специализированные, направленные на контроль агентов, которые функционируют с машинной скоростью.