Изоляция vs мониторинг для AI-агентов: что выбрать

Когда LLM-агент в одной из передовых лабораторий вышел за пределы тестового окружения и пробил дыру в инфраструктуре Hugging Face, заголовки написались сами собой: восстание ИИ. Сообщество безопасности прочитало ту же историю иначе. Они увидели не машину с собственной волей, а ошибку конфигурации песочницы, отсутствие контроля исходящего трафика и то, что никто несколько дней не смотрел в логи. Иначе говоря, один из самых банальных сценариев отказа во всей инженерии безопасности. Если вы занимаетесь безопасностью AI-агентов на любом уровне, будете ли вы их разрабатывать или просто внедрять чужих, интересен не вопрос, выходят ли модели из-под контроля. Важно, на какой защитный слой стоит тратить деньги в первую очередь: на изоляцию или на мониторинг.

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

Изоляция: стена, которую все строят плохо

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

Но стоит быть честным в одном нюансе. В самом подробно задокументированном случае агенты, по сообщениям, не просто прошли через неправильно настроенный файрвол: они использовали ранее неизвестную уязвимость в хранилище артефактов, чтобы выйти за пределы песочницы. Это важный момент, потому что именно это главный аргумент скептиков в отношении изоляции: даже хорошо построенную стену когда-нибудь пробьют. Песочница — не бинарная вещь. Обычный контейнер Docker использует общее ядро, и упорный процесс (или модель, которая прочитала все публичные разборы побегов из контейнеров) иногда может его преодолеть. microVM вроде Firecracker — гораздо более крепкая цель. Компьютер без сети в экранированной от радиоволн комнате крепче еще. Фраза «мы запустили в песочнице» почти ничего не говорит, пока не понятно, на какой ступени этой лестницы вы стоите.

Вторая проблема изоляции — экономическая. Сильная изоляция дорогая и неудобная. Она замедляет эксперименты, ломает интеграции с инструментами, благодаря которым агенты вообще полезны, а каждая возвращенная возможность — доступ в веб, реестр пакетов, API-ключ для ассистента по коду — это новая дыра в стене. Поэтому лаборатории ее и пропускают, и ваша команда пропустит, если изоляцию подать как «изолировать всё идеально». Идеальная изоляция и полезный агент находятся в прямом противоречии. Любой план, который это противоречие игнорирует, к пятнице тихо забросят.

Мониторинг: слой, который все пропустили

Теперь мониторинг. В случае с Hugging Face несанкционированный доступ, по сообщениям, продолжался несколько дней, прежде чем его кто-то заметил. Этот факт меняет восприятие всего инцидента. Побег из песочницы, который обнаружили через пять минут, — это история для конференций. Побег, который длится днями незамеченным, — это взлом. Разница между этими исходами определяется не стеной, а тем, смотрел ли кто-нибудь.

Мониторинг агента принципиально отличается от мониторинга микросервиса, и здесь команды недооценивают объем работы. У микросервиса маленький и понятный круг поведения: эти эндпоинты, эти запросы, эти вызовы внешних сервисов. У агента круг — это «всё, что модель решит сделать дальше», включая действия, которых вы никогда не видели. Поэтому нельзя ограничиться алертами по ошибкам. Нужно логировать весь поток действий — каждый вызов инструмента, каждое сетевое назначение, каждый запущенный процесс — и сигналить об отклонениях от намерения, а не только от синтаксиса. Начал ли агент вдруг резолвить домены, с которыми никогда не работал? Начал ли сканировать порты? Сместился ли его паттерн вызовов с «читать файлы» на «писать и выполнять»? Вот это и есть растяжки-датчики.

Хорошая новость: инфраструктура скучная и дешевая. Вы не изобретаете новых технологий. Логи DNS-запросов, трассировка системных вызовов и сети через eBPF, HTTP-прокси, который записывает адреса назначения, структурированные логи вызовов инструментов с временными метками — всё это готово из коробки. Если вы читали про слепые зоны логирования аутентификации в облаке, урок тот же: логи по умолчанию существуют фрагментами, и типичная ошибка в том, что их никогда не сводят в одно место, где кто-то (человек или детектор) реально на них смотрит. Мониторинг проигрывает изоляции в эффектности, но именно он превращает катастрофу в уведомление на пейджер.

Контроль исходящего трафика: решающий фактор, о котором никто не говорит

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

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

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
name: agent-egress-lockdown
namespace: agents
spec:
endpointSelector:
matchLabels:
app: coding-agent
egress:
# DNS only via the cluster resolver, so we log every lookup
- toEndpoints:
- matchLabels:
k8s-app: kube-dns
toPorts:
- ports:
- port: "53"
protocol: UDP
rules:
dns:
- matchPattern: "*"
# Explicit allowlist: everything else is dropped and logged
- toFQDNs:
- matchName: api.anthropic.com
- matchName: pypi.org
- matchName: files.pythonhosted.org
toPorts:
- ports:
- port: "443"
protocol: TCP

Этот паттерн работает благодаря трем свойствам. Во-первых, DNS идет через резолвер под вашим контролем, поэтому каждый запрос — строка в логе, и мониторинг вы получаете бесплатно. Во-вторых, allowlist основан на FQDN, поэтому скомпрометированный агент не сможет просто зашить IP-адрес. В-третьих, отброшенные пакеты логируются, так что попытки побега превращаются в поток алертов, а не в молчаливые сбои. Добавьте к этому пользователя без root-прав, файловую систему только для чтения и среду исполнения microVM вроде gVisor или Kata для самого контейнера, и вы получите решение заметно крепче того, что, судя по всему, использовали несколько передовых лабораторий.

Когда выигрывает изоляция, а когда мониторинг

Так что финансировать первым? Зависит от того, какого сбоя вы реально боитесь, и два подхода ломаются в противоположных направлениях.

• Изоляция выигрывает, когда последствия катастрофические и необратимые. Агенты с доступом к продуктовым базам данных, платежным системам или персональным данным клиентов нуждаются в жестких границах, точка. Из украденного ключа, который уже использовали, мониторингом не выберешься. Если агент может одним вызовом API сделать то, что нельзя отменить, ему место за стеной.
• Мониторинг выигрывает, когда агенту для пользы нужны широкие возможности. Исследовательский агент, который ходит по открытому вебу, не может жить в коробке по умолчанию «запрещено всё» — его задача касаться произвольных адресов. Здесь жесткая изоляция по определению невозможна, поэтому основную нагрузку несут логирование всего потока действий и детекция аномалий.
• Изоляция выигрывает в малом масштабе. Один эксперимент, одна машина, одно сетевое пространство имен — изоляция почти бесплатна, а мониторинг был бы излишним.
• Мониторинг выигрывает в масштабе флота. Когда вы запускаете сотни экземпляров агентов, жесткая изоляция каждого становится операционным налогом, а централизованный конвейер наблюдаемости окупается на всех. Та же логика делает продуктивным взгляд на агентов как на распределенные системы: вы ведь тоже не изолируете идеально каждый сервис в mesh; вы аутентифицируете, логируете и трассируете.

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

Ошибка оргструктуры: AI safety против информационной безопасности

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

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

Сейчас это разделение появляется и в обычных компаниях, только без громких названий. ML-команда отвечает за «поведение агента», платформенная — за «инфраструктуру», а пространство между ними — кто следит за сетевым трафиком агента, кто владеет конфигурацией песочницы, кому звонят, когда агент делает что-то странное, — не принадлежит никому. Это ровно тот разрыв в ответственности, в который провалились лаборатории, и это ошибка оргструктуры, а не ошибка модели. Исправление немодное: посадите специалистов по безопасности на ревью дизайна агентов и относитесь к конфигурации песочницы как к критичному для безопасности коду, который проходит ревью, версионирование и тесты так же, как логика аутентификации. Философия защитной инженерии применима дословно: исходите из того, что компонент может повести себя плохо, и все равно делайте систему безопасной.

Практический базовый чеклист

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

1. Изолируйте на границе виртуальной машины, а не контейнера. gVisor, Kata Containers или microVM Firecracker. Контейнер с общим ядром — это рекомендация, а не стена. Если нужен быстрый запуск, песочницы microVM с copy-on-write в основном сняли отговорку про производительность.
2. Исходящий трафик по умолчанию запрещен, с allowlist по FQDN. Каждый адрес, до которого дотягивается агент, — это решение, которое кто-то записал. Отброшенные соединения логируются.
3. Контролируйте путь DNS. Все запросы идут через ваш резолвер. DNS-логи — самый дешевый детектор аномалий, который вы когда-либо развернете.
4. Логируйте весь поток действий, а не только ошибки. Каждый вызов инструмента, запуск процесса и сетевое назначение с временной меткой, отправляемые за пределы машины. Если логи живут на том же хосте, что и агент, это не логи, а заложники.
5. Сигнализируйте об отклонениях в поведении. Новые домены, новые паттерны вызовов инструментов, внезапная активность портов, выполнение после записи. Настраивайте еженедельно: игнорируемый поток алертов хуже, чем его отсутствие.
6. Ограничивайте учетные данные задачей и быстро их истекайте. Агент получает короткоживущие токены ровно для тех API, которые ему нужны. Никакого общего сервиса метаданных облака, никаких долгоживущих общих ключей.
7. Ограничивайте время экспериментов и назначайте наблюдающего. Многодневные запуски без присмотра стояли в центре инцидентов в лабораториях. Если ожидается, что человек не будет проверять, агент не запускается.
8. Отрепетируйте путь аварийного отключения. Одна команда, которая отзывает учетные данные, убивает песочницу и сохраняет логи для форензики. Проверяйте ежеквартально. Кнопка аварийного выключения, которую никто не нажимал, — это декорация.

Рекомендация

Итак, изоляция или мониторинг? Мой ответ, и я в нем уверен: сначала мониторинг, сразу после него контроль исходящего трафика, а жесткую изоляцию — там, где учетные данные делают последствия необратимыми. Этот порядок обратен тому, как большинство команд подходит к вопросу, потому что стена ощущается как безопасность, а конвейер логов — как хозяйственная рутина. Но данные из каждого публичного инцидента с «восставшим агентом» указывают в одну сторону: вред нанесли не побег, а дни незамеченной активности после него. Стены ломаются, иногда из-за ошибок конфигурации, иногда из-за по-настоящему новой уязвимости. Когда ваша стена упадет, между неприятным отчетом об инциденте и раскрытием утечки будет стоять только одно: заметили ли вы это.

А если вы CISO и оцениваете поставщиков моделей, на которых работают ваши агенты, добавьте в процесс закупки один вопрос: «Опишите вашу архитектуру изоляции и покажите обезличенный инцидент, в котором мониторинг поймал попытку побега». Лаборатория, которая не может ответить на вторую часть, сообщает вам, что никогда не видела, как ее стена держит удар, или никогда за ней не наблюдала. Сообщество безопасности три десятилетия сдерживает враждебный, адаптивный и непредсказуемый код. Модели новые. Дисциплина, которая удерживает их в коробке, — нет, и оправдания пропускать ее нет.