Кукбу́к для безопасных и мощных агентов
По мере того как компании переходят от экспериментов с AI-агентами к их production-развертыванию, становится очевидным один вывод: возможности без контроля — это уязвимость.
Агенты работают в длительных, stateful-средах. Они просматривают веб, читают репозитории, выполняют shell-команды, вызывают API и взаимодействуют с внутренними системами. Эта мощность преобразующая — и она существенно расширяет поверхность атаки.
В недавнем интервью Jonathan Wall, CEO компании Runloop, сформулировал этот сдвиг так: «По умолчанию у агентов должен быть доступ почти ни к чему. Им нужно выполнять реальную работу, но возможности должны добавляться поэтапно и контролируемо». Эта логика отражает более широкую отраслевую реальность: инфраструктура агентов должна строиться вокруг принципа least privilege, явной изоляции и наблюдаемого выполнения.
Ниже — практическая архитектура контроля для production-агентов.
Многоуровневая модель контроля
Устойчивая среда развертывания агента объединяет шесть явных уровней:
- Жесткая изоляция runtime с помощью microVM
- Ограничительная сетевая политика с явными egress allowlist
- Централизованное управление учетными данными через gateway
- Дисциплинированное управление идентичностями с краткоживущими, scoped-учетными данными
- Сознательное создание friction вокруг чувствительных действий и высокорисковых инструментов
- Непрерывный мониторинг, logging и adversarial testing
Каждый слой закрывает свой сценарий отказа. Вместе они ограничивают blast radius, когда — не если — что-то ломается.
Начните с least privilege
Production-окружение агента начинается в ограниченном состоянии: изолированная граница runtime, отсутствие inbound-доступа, отсутствие outbound-сетевого доступа и отсутствие неявных прав на инструменты.
Сама runtime-граница — часть least privilege. Контейнеры обеспечивают эффективную изоляцию для доверенных или single-tenant-нагрузок, но они разделяют host kernel. Реальные уязвимости escape неоднократно показывали, что эта граница может ломаться под давлением атакующего. CVE-2019-5736 позволяла атакующим перезаписывать host-бинарник runc изнутри контейнера; CVE-2022-0492 обеспечивала breakout через неверную конфигурацию cgroups; CVE-2024-21626 снова выявила пути escape на базе runc. Эти инциденты не делают контейнеры бесполезными — но они ясно показывают компромисс. MicroVMs вводят более сильную аппаратную границу и уменьшают blast radius, когда агенты исполняют произвольный или непроверенный код.
Изоляция — это не только решение о производительности. Это решение о риске.
Современная модель угроз для агентов
Традиционные SaaS-системы обрабатывают детерминированные запросы. Agent-системы поглощают недоверенный контент и генерируют вероятностные действия.
Prompt injection показала, насколько хрупкими могут быть границы инструкций.
В 2023 году публичные эксперименты против Bing Chat показали, что скрытые инструкции, встроенные в веб-страницы, могут переопределять system prompts. Академические исследования Stanford и других организаций показали, что tool-using-агентов можно принудить к утечке учетных данных или проприетарных данных, если внешний контент считается доверенным контекстом.
Опасность усиливается, когда агенты работают с широкими credential-полномочиями. Service accounts, долгоживущие API keys и общие внутренние токены превращают успешную инъекцию из «неожиданного вывода» в компрометацию репозитория, доступ к базе данных или злоупотребление SaaS. System prompts, в которых зашиты внутренние URL или конфигурационные данные, после раскрытия становятся повторно используемыми артефактами.
Retrieval-augmented-системы и MCP-интеграции расширяют поверхность еще сильнее. Когда внешние документы загружаются без сегментации или разделения ролей, контент под контролем атакующего может перенаправить поведение или вызвать раскрытие данных.
Именно такую среду и должна выдерживать многоуровневая модель.
Сетевая политика как средство сдерживания
Сетевые ограничения часто воспринимаются как галочки для compliance. В agent-системах они являются механизмами сдерживания.
Агентам обычно нужен outbound-доступ для поиска документации, установки зависимостей или взаимодействия с API. Но неограниченный egress дает самый простой путь к утечке данных после инъекции. Restrictive allowlist — разрешение только явно одобренных доменов или endpoint’ов — резко уменьшает blast radius.
Если модель удалось обманом заставить прочитать файл .env, строгая egress-политика может предотвратить очевидный следующий шаг: отправку этих секретов на домен под контролем атакующего. Логирование outbound-трафика формирует поведенческие базовые линии и позволяет рано замечать аномалии.
Сдерживание превращает катастрофическую компрометацию в инцидент, который можно пережить и исправить.
Ingress как операционное событие
Большинству runtime-окружений агентов не нужны несанкционированные входящие соединения. Если оставлять сервисы открытыми по умолчанию, накапливается ненужный риск.
Когда требуется отладка или совместная проверка, доступ должен быть временным и ограниченным — authenticated tunnels открываются осознанно и закрываются быстро. Ingress становится операционным решением, а не статическим состоянием конфигурации.
Кратковременность — это контроль безопасности.
Управление доступом к model
Large language models — это внешние системы с последствиями для стоимости, compliance и утечек. Если каждый runtime самостоятельно управляет model credentials, это фрагментирует контроль.
Централизованный gateway возвращает управление. Он может ограничивать одобренные models, задавать rate ceilings, логировать prompts и responses, а также применять filtering или compliance checks. Агенты больше не держат у себя raw provider credentials.
Урок и из escape контейнеров, и из prompt injection один и тот же: неявные границы доверия размываются. Централизованное управление укрепляет их.
Инструменты, идентичности и friction по замыслу
По мере того как агенты подключаются к репозиториям, CI-системам, deployment pipeline и базам данных, управление инструментами становится неотделимым от дисциплины идентичностей.
Выделенные идентичности для каждого агента, краткоживущие токены и строгие RBAC или ABAC снижают последствия компрометации. Повторное использование человеческих или root-учетных данных полностью разрушает изоляцию.
Чувствительные действия — отправка email, изменение production-кода, доступ к секретам, смена аутентификации — выигрывают от friction. Policy checks, approval workflows или out-of-band-confirmations создают осознанные паузы на высокорисковых границах.
Секреты не должны жить в prompts. Было показано, что system prompts, в которые встроены credentials, могут утекать под давлением инъекций. Внешние secret manager’ы и строгое разделение между видимым модели текстом и credential-материалом заметно снижают exposure.
Непрерывное adversarial testing
Уязвимости escape в контейнерах и публичные демонстрации prompt injection имеют общий урок: системы ломаются на границах интеграции, а не в изоляции. Logging tool calls, data access и network egress создает поведенческие базовые линии, по которым можно рано заметить аномалии — необычные домены, нетипичные чтения файлов, неожиданные шаблоны вызовов инструментов. Red-teaming и adversarial prompt fuzzing помогают обнаруживать пути инъекции раньше атакующих, заставляя организации сталкиваться со слабыми местами в контролируемых условиях, а не в production.
Агенты могут строить, тестировать, просматривать и исполнять произвольный код. Эта способность мощна — и опасна, если не ограничена. Готовность к production определяется не тем, что агенты умеют делать, а тем, насколько точно определены, enforced и observed их границы. Организации, которые успешно масштабируют агентов, будут относиться к инфраструктуре как к policy, к изоляции — как к дизайнерскому решению, а к мониторингу — как к первоклассному требованию, а не к запоздалой мысли.
Материал — перевод статьи с английского.
Оригинал: The cookbook for safe, powerful agents