Виртуальные сотрудники под контролем: как ограничить автономных ИИ-агентов

Очевидный факт: ИИ-агент умеет действовать самостоятельно — запускать программы, управлять файлами и часами напролет последовательно решать поставленную задачу.

Вроде бы новый дивный мир разработчика, но есть проблема: чем больше у агента свобод, тем больше это сулит проблем. Летом 2026 года агенты OpenAI покинули песочницу и пошли работать в интернет, попутно атаковав HuggingFace.

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

Сегодня поговорим о системе Hard Stop, предложенной ^[1] в одноименной научной работе. Это стоп-кран между агентом и ОС, который должен остановить процессы агента раньше, чем тот успеет навредить.

Побег

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

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

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

После разбора инцидента независимые исследователи обнаружили ^[2] около 1200 агентов, которые наплодили больше 70 тысяч сообщений и файлов. Где-то 700 из них покушались (и успешно) на безопасность HuggingFace.

В HuggingFace при аудите смогли восстановить около 17,6 тысячи действий, когда агенты искали уязвимости, читали системные файлы, они даже умудрились заполучить доступ к Kubernetes и внутренней инфраструктуре. 

И все это только ради того, чтобы решить тесты, обозначенные OpenAI со всеми ее мерами безопасности и четко прописанными правилами. Задачки звучали, грубо говоря, так:

• Не подключайся к посторонним серверам.

• Не выходи за пределы своей песочницы.

• Тебе запрещено читать системные файлы.

Как видим, это не помогло. И тогда начался срач пошла активная и неоднозначная дискуссия о необходимости более эффективного способа поймать шаловливого агента.

Поймать мысль вместо действия

Один из способов контролировать ИИ-агента — проверять его команды и сообщения до выполнения: фильтр или другая модель анализирует сгенерированный текст и пытается определить, не собирается ли агент сделать что-то запрещенное. Но такой контроль зависит от того, сможет ли система правильно понять форму записи. Как мы уже разбирали в статье ^[3] о собственных языках ИИ-агентов, сообщение можно закодировать или передать так, что мониторинг не распознает его смысла. В случае с командами проблема похожая.

Скажем, агенту запретили использовать .curl. Фильтр агента ищет это слово в командах и понимает, что туда напрямую нельзя. Зато можно собрать его из пары строк (cu+rl), закодировать команду или вообще напрямую вызвать сетевую библиотеку Python. И для генеративной системы, коей агент и является, это все разные действия, которые не подпадают под единое ограничение.

Но со стороны ОС, куда поступают запросы, картина другая. Любой процесс рано или поздно должен обратиться к ядру ОС: оно управляет файлами и всеми ресурсами компьютера, этап этот обойти невозможно.

И если агент нахитрил с формированием адреса сервера, для ядра ему все равно придется сообщить конкретный IP и открыть сокет. Или, скажем, с файлами: пусть он прячет путь в нужную папку хоть внутри кода, ядро в любом случае получит настоящий путь.

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

Два слоя архитектуры

Стоп-кран нельзя зашивать в саму LLM, поскольку решение все равно будет принимать вероятностная модель, где шанс ошибки ^[4] в любом случае сохраняется (и может быть даже крайне высоким).

Поэтому у Hard Stop придумали два уровня: агент и его супервизор. У второго очень скучная и прямолинейная задача — сверять действия с заранее заданными правилами. Скажем, такие:

• Агент может работать только с /workspace.

• Он может подключаться только к внутреннему серверу.

• Имеет право запускать исключительно разрешенные программы.

• Он не имеет доступа к /proc, /sys и другим системным областям.

Супервизор бездействует, если правила не нарушаются. Но шаг влево, шаг вправо — стоп-кран.

Идею прозвали Andon Cord (сигнальный шнур) — в честь системы безопасности на заводе Toyota. Там на конвейере есть механизм Andon, который может немедленно остановить линию, если вдруг случится проблема.

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

Стоп-кран работает по очень простому принципу: за его основу взяли существующие механизмы Linux — система позволяет встраивать проверки непосредственно в путь выполнения чувствительных операций.

Среди прочего там есть LSM и eBPF.

LSM — инфраструктура безопасности внутри ядра Linux. Проще говоря, она умеет ставить доппроверки перед операциями по типу открытия файлов или работы с сетью. А eBPF представляет собой способ загрузки мини-программы таких проверок прямо в ядро.

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

Можно остановить агента, но это не затронет дочерние процессы. И для этого Linux использует механизм cgroup, который объединяет множество процессов в одну группу. В классической работе Linux использует cgroup для ограничения ресурсов, чтобы, например, объемный контейнер не сожрал всю оперативку или память ^[6] процессора.

Но тот же cgroup умеет и замораживать группы процессов. На человеческом языке это значит, что он говорит: «Остановить ВСЕ, что сейчас относится к этому агенту».

При этом cgroup ожидает подтверждения через ядро, что агент с его «прихвостнями» заморожен, даже если супервизор сделал запрос на полную остановку группы процессов.

Зачем это делать? Представим, что агент несколько часов решал сложную задачу, но в какой-то момент решил пошалить. Если его ресетнуть, весь полезный прогресс канет в Лету. А это страховка, наподобие истории версий в текстовом редакторе — если вдруг питание ПК выключится, к документу можно будет вернуться с минимальными потерями.

Система при срабатывании стоп-крана пишет логи, где можно посмотреть:

• что он делал;

• на каком шаге остановился;

• какое именно правило нарушил;

• можно ли продолжить выполнение после вмешательства человека.

И все благодаря встроенному журналу фиксации состояний и событий WAL (write ahead log).

Почему и этого может быть недостаточно?

Решение на уровне ядра выглядит безупречным, но и тут есть брешь. Особенно как было в случае OpeanAI, когда агент пошел не напрямую, а через сторонний сервер, к которому было вполне легально обращаться. То есть в случае со стоп-краном белый список пропустит запрос, потому что это доверенный посредник.

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

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

Да и сам Hard Stop пока что только демонстрация возможной архитектуры. В опубликованных материалах ^[7] на GitHub даже есть бенчмарки, например, скорости срабатывания стоп-крана — 4,8 микросекунды в медиане, что довольно оперативно.

Скорость — это хорошо, но Hard Stop работает, лишь пока сам контролер по уровню доступа выше агента.

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

Но если агент каким-то образом уже получил рут к хосту? Тогда он потенциально может вмешаться в сам механизм защиты: поменять настройки cgroup и вообще воздействовать на супервизора. Получается, стоп-кран хорош ровно до тех пор, пока агент не добрался до комнаты, где находится сам рубильник.

Hard Stop тоже, в принципе, плевать, плохое у него правило или хорошее, и его нужно правильно задать, то есть очень многое зависит от изначальной конфигурации, заданной человеком.

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