Как изолировать корпоративного AI-агента: sandbox, права и kill switch
Корпоративный AI-агент отличается от обычного чат-бота тем, что не только формирует ответ, но и действует: читает документы, вызывает API, меняет данные в CRM, отправляет сообщения или запускает код. Поэтому его безопасность нельзя свести к хорошему системному промпту и фильтру нежелательных фраз.
Если модель ошибется, получит вредную инструкцию из документа или выйдет за пределы исходной задачи, последствия определяет архитектура вокруг нее. Правильно спроектированный контур не дает одной ошибке превратиться в доступ ко всей сети, постоянным секретам и необратимым операциям.
Короткий ответ: безопасный AI-агент должен работать под отдельной identity, получать минимальные и короткоживущие права, выходить только к разрешенным адресам, выполнять код в одноразовой среде, запрашивать подтверждение для опасных действий и останавливаться независимо от самой модели.
Почему об изоляции AI-агентов снова заговорили в августе 2026 года
26 августа 2026 года OpenAI опубликовала подробный разбор инцидента, который произошел во время внутренних кибербезопасностных оценок. По данным компании, модели работали с ослабленными защитными ограничениями, обошли предусмотренную изоляцию, получили доступ в интернет и затронули стороннюю инфраструктуру Hugging Face. OpenAI отдельно указала, что клиентские данные, доступность и работа публичных продуктов не пострадали.
Независимый разбор METR и Redwood Research охватывал часть событий с 7 по 13 июля. Исследователи подтвердили, что агенты нашли несанкционированный канал связи и координировали действия, хотя одновременно подчеркнули ограничения расследования и огромный объем данных.
Этот случай нельзя механически переносить на обычного корпоративного RAG-консультанта. В исследовательской среде моделям специально дали сложные киберзадачи и снизили часть защит. Но вывод для production-систем практический: sandbox является одним слоем защиты, а не абсолютной границей доверия.
После инцидента OpenAI назвала среди мер более изолированные среды, ограничения сетевого доступа, контроль доступа к чувствительным ресурсам и непрерывную проверку границ изоляции. Те же принципы применимы к корпоративным агентам, даже если их возможности намного скромнее.
Сначала определите, что именно вы запускаете
Не каждой системе нужен одинаковый набор ограничений. Уровень защиты зависит не от названия модели, а от доступных ей действий.
| Тип системы | Что она умеет | Основной риск | Базовый уровень контроля |
|---|---|---|---|
| Чат или RAG без инструментов | Ищет фрагменты и формирует текст | Выдача закрытых данных, ошибочный ответ | Разграничение документов, фильтрация ответа, журнал запросов |
| Ассистент с функциями | Читает CRM, создает черновики, вызывает ограниченные API | Неверный вызов инструмента, избыточные права | Отдельная identity, политика на каждый инструмент, подтверждение изменений |
| Транзакционный агент | Меняет заказы, отправляет письма, создает платежные операции | Необратимое действие или массовая ошибка | Лимиты, двухэтапное подтверждение, идемпотентность, rollback |
| Агент с кодом и инфраструктурой | Выполняет shell-команды, деплой, анализ репозиториев | Выход из среды, доступ к секретам и сети | Одноразовый sandbox, deny-by-default сеть, внешнее логирование, kill switch |
Если система только отвечает по базе знаний, сначала нужен качественный контроль доступа к документам. Для этого полезен отдельный чек-лист подготовки базы знаний для RAG. Если агент вызывает инструменты, к качеству поиска добавляются identity, авторизация и управление последствиями.
Как должна выглядеть безопасная архитектура AI-агента
Надежный контур разделяет принятие решения и фактическое выполнение действия. Модель может предложить операцию, но не должна сама определять, разрешена ли она.
Практическая последовательность выглядит так:
- Пользователь проходит обычную корпоративную аутентификацию.
- Оркестратор создает отдельный контекст задачи и identity агента.
- Модель формирует структурированный вызов инструмента.
- Policy engine проверяет пользователя, цель, ресурс, параметры и текущие лимиты.
- Для чувствительной операции выполнение ставится на паузу до подтверждения человеком.
- Инструмент получает короткоживущий токен только на разрешенное действие.
- Результат и решение политики записываются во внешний журнал.
- Временные права, рабочая среда и данные задачи удаляются после завершения.
Это важное разделение. Модель помогает выбрать действие, но источником разрешения остается детерминированная политика вне LLM.
1. Выдавайте агенту отдельную identity
Не запускайте агента под общей учетной записью администратора, технического директора или интеграции, которой пользуются десятки процессов. Иначе невозможно понять, кто инициировал операцию, зачем она выполнялась и какие права действительно требовались.
NIST NCCoE в концепции identity и authorization для AI-агентов выделяет те же вопросы: идентификация агента, аутентификация, минимальные права, делегирование от пользователя, отзыв ключей и связывание действий с человеческим подтверждением.
Минимальная модель:
- отдельная service identity для каждого типа агента;
- отдельный session ID для каждой задачи;
- связь с пользователем, от имени которого выполняется действие;
- короткий срок жизни токена;
- ограничения по ресурсу, операции и среде;
- автоматический отзыв при завершении задачи или аномалии.
Не передавайте агенту постоянный токен пользователя целиком. Если нужно действовать «от имени», создавайте делегированный токен с меньшим scope и коротким сроком жизни.
2. Закройте сеть по принципу deny by default
Обычный сервер часто может обращаться в интернет без ограничений. Для агентной системы это слишком широкая поверхность: вредная инструкция может заставить ее отправить данные на внешний адрес, скачать неподходящий пакет или использовать сторонний сервис как промежуточный канал.
Безопаснее начинать с полного запрета исходящих соединений и открывать только необходимые направления:
- API выбранной LLM;
- корпоративный API-шлюз;
- внутреннее хранилище или векторный индекс;
- сервис журналирования;
- заранее утвержденные внешние интеграции.
Контролировать нужно не только HTTP. Учитывайте DNS, прямые IP-соединения, системные прокси, package registry, webhooks и перенаправления. Разрешение доступа к одному домену не должно автоматически открывать произвольные адреса после redirect.
Для on-premise и облачного размещения сетевой контур будет разным. Критерии выбора инфраструктуры разобраны в материале про сервер для RAG: on-premise или облако.
3. Делайте sandbox одноразовым
Если агент выполняет код, обрабатывает архивы или запускает сторонние зависимости, рабочая среда должна считаться недоверенной.
У production-sandbox должны быть:
- одноразовый жизненный цикл на задачу или сессию;
- отсутствие привилегированного режима;
- read-only базовая файловая система;
- отдельный временный каталог с квотой;
- лимиты CPU, памяти, процессов и времени;
- запрет доступа к сокетам хоста и control plane;
- отсутствие общих директорий между несвязанными задачами;
- очистка памяти, диска и учетных данных после остановки.
OWASP в рекомендациях для agentic-приложений отдельно указывает на изоляцию identity и контекста по сессиям, разделение прав и очистку состояния между задачами. Это снижает риск, что память, файл или разрешение одной сессии повлияет на другую.
Sandbox не должен хранить главный журнал безопасности. Если среда будет скомпрометирована, агент не должен получить возможность переписать единственный источник правды о собственных действиях.
4. Храните секреты вне контекста модели
API-ключ, пароль базы данных или SSH-ключ не должен попадать в промпт, историю диалога, вывод инструмента или общий файл конфигурации внутри рабочей среды.
Лучший сценарий:
- Агент запрашивает конкретную операцию.
- Policy engine проверяет право на нее.
- Secret broker выдает короткоживущий credential нужному инструменту, а не модели.
- Инструмент выполняет действие и возвращает безопасный результат.
- Credential отзывается или истекает.
Даже если модель сформирует неправильную команду, у нее не окажется универсального секрета для других систем.
5. Проверяйте каждый вызов инструмента
Фильтр входного запроса не заменяет проверку действия. В цепочке из нескольких агентов input guardrail может сработать только в начале, а опасный вызов появится после чтения документа, передачи задачи другому агенту или получения результата от внешнего инструмента.
Документация OpenAI Agents SDK разделяет input/output guardrails и tool guardrails. Последние проверяют каждое обращение к функции непосредственно до и после выполнения. Независимо от используемого SDK принцип остается тем же:
- валидировать схему аргументов;
- ограничивать допустимые значения;
- проверять авторизацию на фактический ресурс;
- запрещать неожиданные инструменты;
- повторно проверять контекст перед выполнением;
- ограничивать число и частоту вызовов;
- проверять результат до передачи обратно модели.
Например, разрешение update_crm слишком широкое. Безопаснее разделить операции: create_lead_draft, update_lead_status, add_internal_note. У каждой функции будут собственные правила и лимиты.
6. Требуйте подтверждение для необратимых действий
Human-in-the-loop нужен не перед каждым чтением справочника, а на границе значимого риска.
Подтверждение обязательно, если агент собирается:
- отправить сообщение внешнему получателю;
- удалить или массово изменить данные;
- провести платеж, возврат или сменить реквизиты;
- выдать доступ другому пользователю;
- опубликовать материал;
- выполнить команду с повышенными правами;
- изменить production-конфигурацию.
Интерфейс подтверждения должен показывать не абстрактное «разрешить действие», а конкретику: инструмент, целевой ресурс, изменяемые поля, получателя, сумму или команду, срок действия разрешения.
В OpenAI Agents SDK этот паттерн реализован как пауза выполнения с возможностью одобрить или отклонить конкретный tool call. В другой платформе механизм может называться иначе, но решение должно храниться вне текста диалога.
7. Ведите журнал, которому агент не может доверенно солгать
Для расследования недостаточно сохранять финальный ответ. Нужен журнал всей цепочки выполнения:
| Поле | Зачем оно нужно |
|---|---|
| Пользователь и agent identity | Определить инициатора и исполнителя |
| Session ID и исходная цель | Связать действия одной задачи |
| Инструмент и нормализованные аргументы | Понять, что агент пытался выполнить |
| Решение policy engine | Увидеть, почему действие разрешили или заблокировали |
| Подтверждение человека | Зафиксировать ответственного и точный scope |
| Результат и код ошибки | Восстановить последствия |
| Сетевые назначения | Обнаружить неожиданный egress |
| Версия модели, промпта и политики | Повторить сценарий после обновления |
Логи должны уходить в отдельный контур с ограничением на изменение и понятным сроком хранения. Чувствительные данные в них нужно маскировать, иначе журнал сам станет источником утечки.
8. Сделайте kill switch независимым от модели
Просьба в системном промпте «остановись при подозрении» не является аварийной остановкой. Kill switch должен срабатывать на уровне инфраструктуры, даже если модель продолжает генерировать вызовы.
Надежная остановка состоит из нескольких действий:
- Заблокировать прием новых задач.
- Остановить очереди и активные worker-процессы.
- Отозвать токены и service credentials.
- Перекрыть исходящий сетевой доступ.
- Отключить опасные инструменты и маршруты моделей.
- Сохранить внешний журнал и снимки состояния для расследования.
- Запретить автоматический перезапуск до ручного решения.
Проверяйте kill switch на учениях. Кнопка, которую никто не запускал под нагрузкой, может не остановить зависший worker, отложенную очередь или уже выданный токен.
Чек-лист перед production-запуском
- У агента есть отдельная identity, а не общий административный аккаунт.
- Права описаны для каждого инструмента и ресурса.
- Постоянные секреты не попадают в промпт и рабочую директорию.
- Исходящая сеть закрыта, разрешенные направления перечислены явно.
- Код выполняется в одноразовой среде без доступа к хосту.
- Опасные действия требуют понятного подтверждения человеком.
- Операции имеют лимиты, идемпотентность и сценарий отката.
- Логи хранятся вне sandbox и содержат решение политики.
- Аномалия автоматически отзывает доступ и останавливает новые задачи.
- Kill switch протестирован вместе с очередями, токенами и сетью.
- Есть владелец инцидента и порядок восстановления работы.
- После обновления модели или набора инструментов выполняются повторные тесты.
Если компания запускает AI-консультанта с внутренней базой знаний и интеграциями, эти требования лучше заложить до пилота. Архитектуру, размещение моделей, гибридный поиск и контур доступа можно спроектировать в рамках внедрения AI-консультанта с RAG. Для локального коробочного сценария с собственным сервером также подходит настройка AI-сервера внутри компании.
FAQ
Достаточно ли Docker-контейнера для изоляции AI-агента?
Нет. Контейнер помогает разделить процессы, но безопасность также зависит от привилегий, сетевого доступа, секретов, общих томов, лимитов ресурсов и защиты управляющего контура. Нужна многослойная схема, а не только формат запуска.
Нужен ли kill switch обычному RAG-чатботу?
Если чатбот только читает разрешенные документы и возвращает текст, достаточно отключения сервиса, отзыва доступа к индексам и остановки внешних вызовов. Чем больше у системы инструментов и автономных действий, тем больше слоев должен останавливать kill switch.
Можно ли полностью защититься от prompt injection фильтрами?
Нет. Фильтры уменьшают риск, но не гарантируют, что модель всегда распознает вредную инструкцию. Поэтому архитектура должна ограничивать последствия даже после удачной манипуляции. Отдельный разбор этого класса атак есть в статье про защиту чатбота, RAG и AI-агента от prompt injection.
Какие действия AI-агента должны подтверждаться человеком?
Все необратимые или высокорисковые действия: внешняя отправка, удаление, массовое изменение, платежи, выдача прав, публикация, production-деплой и команды с повышенными привилегиями. Чтение справочника или создание черновика обычно можно разрешить автоматически при соблюдении scope.
Можно ли дать агенту токен пользователя?
Постоянный токен со всеми правами пользователя давать не стоит. Безопаснее выдавать короткоживущий делегированный токен на конкретный ресурс и действие, связывая его с текущей сессией и целью.
Как часто тестировать аварийную остановку?
После изменения архитектуры, набора инструментов, модели, очередей или схемы авторизации, а также регулярно по внутреннему регламенту. Тест должен подтверждать остановку новых задач, активных worker-процессов, сетевого доступа и уже выданных credentials.