Очевидный факт: ИИ-агент умеет действовать самостоятельно — запускать программы, управлять файлами и часами напролет последовательно решать поставленную задачу.
Вроде бы новый дивный мир разработчика, но есть проблема: чем больше у агента свобод, тем больше это сулит проблем. Летом 2026 года агенты OpenAI покинули песочницу и пошли работать в интернет, попутно атаковав HuggingFace.
Инцидент поставил перед ИИ-инженерами задачу: нужно найти способ ограничить агентов, чтобы те ни при каких обстоятельствах не могли покинуть изолированные среды. Но агенты хитрые и очень быстро находят способы обойти даже самые жесткие правила. Однако есть одно слабое место.
Сегодня поговорим о системе Hard Stop, предложенной в одноименной научной работе. Это стоп-кран между агентом и ОС, который должен остановить процессы агента раньше, чем тот успеет навредить.
Побег
Вы наверняка слышали о недавней нашумевшей истории с внутренним экспериментом OpenAI. Официальная версия такова: это было тестирование агентов на наборе задач по кибербезопасности на платформе ExploitGym, причем в строго ограниченной среде — у них отсутствовал доступ в интернет, а запуск происходил исключительно в изолированных окружениях. Стояла задача хорошо завершить тесты.
Однако было и слабое место: чтобы установить программные пакеты, использовался промежуточный сервер Artifactory, который имел выход в сеть.
По ходу решения задач агенты подумали, что лучше всего тесты решаются там, где уже есть ответы. То есть в интернете. Поэтому они отыскали в Artifactory уязвимость, с ее помощью сперва организовали связь между собой, а затем научились отправлять запросы во внешний мир.
После разбора инцидента независимые исследователи обнаружили около 1200 агентов, которые наплодили больше 70 тысяч сообщений и файлов. Где-то 700 из них покушались (и успешно) на безопасность HuggingFace.
В HuggingFace при аудите смогли восстановить около 17,6 тысячи действий, когда агенты искали уязвимости, читали системные файлы, они даже умудрились заполучить доступ к Kubernetes и внутренней инфраструктуре.
И все это только ради того, чтобы решить тесты, обозначенные OpenAI со всеми ее мерами безопасности и четко прописанными правилами. Задачки звучали, грубо говоря, так:
-
Не подключайся к посторонним серверам.
-
Не выходи за пределы своей песочницы.
-
Тебе запрещено читать системные файлы.
Как видим, это не помогло. И тогда начался срач пошла активная и неоднозначная дискуссия о необходимости более эффективного способа поймать шаловливого агента.
Поймать мысль вместо действия
Один из способов контролировать ИИ-агента — проверять его команды и сообщения до выполнения: фильтр или другая модель анализирует сгенерированный текст и пытается определить, не собирается ли агент сделать что-то запрещенное. Но такой контроль зависит от того, сможет ли система правильно понять форму записи. Как мы уже разбирали в статье о собственных языках ИИ-агентов, сообщение можно закодировать или передать так, что мониторинг не распознает его смысла. В случае с командами проблема похожая.
Скажем, агенту запретили использовать .curl. Фильтр агента ищет это слово в командах и понимает, что туда напрямую нельзя. Зато можно собрать его из пары строк (cu+rl), закодировать команду или вообще напрямую вызвать сетевую библиотеку Python. И для генеративной системы, коей агент и является, это все разные действия, которые не подпадают под единое ограничение.
Но со стороны ОС, куда поступают запросы, картина другая. Любой процесс рано или поздно должен обратиться к ядру ОС: оно управляет файлами и всеми ресурсами компьютера, этап этот обойти невозможно.
И если агент нахитрил с формированием адреса сервера, для ядра ему все равно придется сообщить конкретный IP и открыть сокет. Или, скажем, с файлами: пусть он прячет путь в нужную папку хоть внутри кода, ядро в любом случае получит настоящий путь.
И в этом месте разработчики решили прикрутить Hard Stop. Принцип его работы прост как фейсконтроль в клубе: если действие в белом списке, оно проходит к ядру, а если нет — действие останавливают. И стоп-крану не нужно разбираться в рассуждениях модели — агент изначально для него недоверенная программа.
Два слоя архитектуры
Стоп-кран нельзя зашивать в саму LLM, поскольку решение все равно будет принимать вероятностная модель, где шанс ошибки в любом случае сохраняется (и может быть даже крайне высоким).
Поэтому у Hard Stop придумали два уровня: агент и его супервизор. У второго очень скучная и прямолинейная задача — сверять действия с заранее заданными правилами. Скажем, такие:
-
Агент может работать только с /workspace.
-
Он может подключаться только к внутреннему серверу.
-
Имеет право запускать исключительно разрешенные программы.
-
Он не имеет доступа к /proc, /sys и другим системным областям.
Супервизор бездействует, если правила не нарушаются. Но шаг влево, шаг вправо — стоп-кран.
Идею прозвали Andon Cord (сигнальный шнур) — в честь системы безопасности на заводе Toyota. Там на конвейере есть механизм Andon, который может немедленно остановить линию, если вдруг случится проблема.
Но в нашем случае дело не заканчивается остановкой запрещенки. Супервизор блокирует опасное действие, после чего все процессы агента замораживаются с фиксацией текущего состояния, чтобы живой разработчик мог провести анализ.
Стоп-кран работает по очень простому принципу: за его основу взяли существующие механизмы Linux — система позволяет встраивать проверки непосредственно в путь выполнения чувствительных операций.
Среди прочего там есть LSM и eBPF.
LSM — инфраструктура безопасности внутри ядра Linux. Проще говоря, она умеет ставить доппроверки перед операциями по типу открытия файлов или работы с сетью. А eBPF представляет собой способ загрузки мини-программы таких проверок прямо в ядро.
Проблема нежелательных действий решена на корню? Почти! Дело в том, что агенты редко запускают один процесс, обычно это цепочки и целые группы процессов: скажем, один работает в браузере, второй запускает shell-команды, которые, в свою очередь, инициируют еще процессы, и так далее.
Можно остановить агента, но это не затронет дочерние процессы. И для этого Linux использует механизм cgroup, который объединяет множество процессов в одну группу. В классической работе Linux использует cgroup для ограничения ресурсов, чтобы, например, объемный контейнер не сожрал всю оперативку или память процессора.
Но тот же cgroup умеет и замораживать группы процессов. На человеческом языке это значит, что он говорит: «Остановить ВСЕ, что сейчас относится к этому агенту».
При этом cgroup ожидает подтверждения через ядро, что агент с его «прихвостнями» заморожен, даже если супервизор сделал запрос на полную остановку группы процессов.
Зачем это делать? Представим, что агент несколько часов решал сложную задачу, но в какой-то момент решил пошалить. Если его ресетнуть, весь полезный прогресс канет в Лету. А это страховка, наподобие истории версий в текстовом редакторе — если вдруг питание ПК выключится, к документу можно будет вернуться с минимальными потерями.
Система при срабатывании стоп-крана пишет логи, где можно посмотреть:
-
что он делал;
-
на каком шаге остановился;
-
какое именно правило нарушил;
-
можно ли продолжить выполнение после вмешательства человека.
И все благодаря встроенному журналу фиксации состояний и событий WAL (write ahead log).
Почему и этого может быть недостаточно?
Решение на уровне ядра выглядит безупречным, но и тут есть брешь. Особенно как было в случае OpeanAI, когда агент пошел не напрямую, а через сторонний сервер, к которому было вполне легально обращаться. То есть в случае со стоп-краном белый список пропустит запрос, потому что это доверенный посредник.
Получилась очередная дыра и бесполезный стоп-кран. Ограничения нужно выстраивать на каждом уровне цепочки, чтобы доверенные посредники тоже имели ограничения и не имели произвольного выхода в интернет.
Иными словами, нужна модель минимальных полномочий: у каждого компонента ровно тот доступ, который необходим для решения его задачи.
Да и сам Hard Stop пока что только демонстрация возможной архитектуры. В опубликованных материалах на GitHub даже есть бенчмарки, например, скорости срабатывания стоп-крана — 4,8 микросекунды в медиане, что довольно оперативно.
Скорость — это хорошо, но Hard Stop работает, лишь пока сам контролер по уровню доступа выше агента.
Допустим, агент работает внутри своей среды, а супервизор управляет правилами, cgroup и сетевыми ограничениями снаружи. В такой конфигурации агент может сколько угодно пытаться выйти за разрешенные границы — он просто не обладает правами, чтобы изменить сами правила.
Но если агент каким-то образом уже получил рут к хосту? Тогда он потенциально может вмешаться в сам механизм защиты: поменять настройки cgroup и вообще воздействовать на супервизора. Получается, стоп-кран хорош ровно до тех пор, пока агент не добрался до комнаты, где находится сам рубильник.
Hard Stop тоже, в принципе, плевать, плохое у него правило или хорошее, и его нужно правильно задать, то есть очень многое зависит от изначальной конфигурации, заданной человеком.
Из всего этого можно сделать вывод: будет надежнее держать ИИ за крепкой дверью, чем надеяться на его благоразумие. Потому что решение, найденное нейросетью, нам всем может не понравиться.
Автор: Andvecher
