AI-безопасность агентов: модель угроз для production-флотов агентов

Каждый AI-агентный фреймворк даёт инструменты для построения агентов. Почти ни один не даёт инструменты для их сдерживания. Когда агент может вызывать API, просматривать веб, исполнять код и обращаться к БД, вопрос безопасности не в том, может ли что-то пойти не так — а как выглядит зона поражения, когда это происходит.

AI-безопасность агентов — это практика ограничения автономных агентов так, чтобы скомпрометированный, неверно сконфигурированный или плохо ведущий себя агент не мог утечь учётные данные, эксфильтровать данные, осушить бюджеты или эскалировать привилегии. OpenLegion рассматривает это как core архитектурную заботу, а не надстройку. Каждый агент работает в изолированном контейнере с vault-проксированными учётными данными, бюджетным контролем на агента и матрицей разрешений — всё включено по умолчанию.

Используйте свои LLM API-ключи. Никакой наценки на использование моделей.

Что такое AI-безопасность агентов?

AI-безопасность агентов охватывает контроли, предотвращающие нанесение вреда автономными AI-агентами — будь то утечка учётных данных, prompt injection, злоупотребление ресурсами, эксфильтрация данных или избыточная agency. Включает runtime-изоляцию, управление учётными данными, принуждение расходов, контроль разрешений и валидацию входов, применяемые на уровне инфраструктуры.

Кратко

Угроза реальна. Исследования показывают, что 77% организаций с AI-развёртываниями испытали security-инциденты в 2024. Только 5% выражают уверенность в своих AI-мерах безопасности.
Четыре основные угрозы: утечка учётных данных, prompt injection, злоупотребление ресурсами (denial of wallet) и эксфильтрация данных. Каждая требует своего смягчения.
Ни один крупный фреймворк не предоставляет встроенной безопасности. По публичной документации, LangGraph, CrewAI, AutoGen и OpenClaw все полагаются на переменные окружения для учётных данных без нативной изоляции или принуждения бюджета.
Шестислойная защита OpenLegion: изоляция контейнеров, hardening контейнеров, разделение учётных данных (vault-прокси), принуждение разрешений, валидация входов и санитизация unicode — всё включено по умолчанию.
Безопасные AI-агенты возможны с BYO-ключами — модель vault-прокси означает, что ваши ключи остаются в доверенной зоне, а агенты взаимодействуют через прокси, который никогда не раскрывает сырые секреты.

Модель угроз для AI-агентов

Угроза 1: утечка учётных данных

Что происходит. Агент с доступом к API-ключам — через переменные окружения, конфиг-файлы или передачу в контексте — утекает эти ключи через prompt injection, логирование, сообщения об ошибках или вредоносные tool calls.

Насколько распространено. Исследования начала 2026 обнаружили, что 283 из 3,984 просканированных skills агентов (7.1%) содержали критические недостатки обработки учётных данных, передавая API-ключи и пароли через контекст LLM в plaintext. Отдельно 76 skills содержали умышленно вредоносные payload'ы для кражи учётных данных. Громкие инциденты включают сотрудника xAI, утекшего API-ключ на GitHub, давший доступ к 60+ приватным LLM на два месяца, и уязвимость в популярной LLM-платформе, раскрывшую API-ключи через неаутентифицированный эндпоинт.

Как OpenLegion это смягчает. OpenLegion использует vault-проксированные учётные данные через vault-прокси. API-ключи хранятся в Mesh Host (Zone 2). Когда агенту нужно вызвать внешний API, запрос маршрутизируется через vault-прокси, который внедряет учётные данные на сетевом уровне. Агент никогда не видит, не логирует и не имеет доступа к памяти с сырым ключом. Даже полностью скомпрометированный агент не может извлечь учётные данные, потому что их нет в контейнере агента.

Угроза 2: prompt injection

Что происходит. Атакующий встраивает вредоносные инструкции в контент, который агент обрабатывает — веб-страницы, документы, email'ы, записи БД, пользовательские входы. Агент следует внедрённым инструкциям вместо (или дополнительно к) своей предполагаемой задачи.

Насколько распространено. Prompt injection появляется в более чем 73% production AI-развёртываний, оцениваемых при security-аудитах. OpenAI заявил в декабре 2025, что prompt injection «вряд ли когда-либо будет полностью решён». OWASP ставит его на #1 уязвимость для LLM-приложений. Реальные инциденты включают браузерного агента, обманом заставленного украсть учётные данные за 150 секунд через скрытые инструкции на веб-странице, и корпоративные RAG-системы, где вредоносный контент в публичных документах заставлял агентов утекать проприетарные данные.

Как OpenLegion это смягчает. OpenLegion применяет defense-in-depth по нескольким слоям. Санитизация unicode убирает невидимые символы (bidi overrides, tag-символы, символы нулевой ширины) в 56 choke point до достижения LLM-контекста — эти символы обычно используются для скрытия внедрённых инструкций. Валидация входов предотвращает path traversal и обеспечивает безопасную оценку условий. Изоляция контейнеров ограничивает зону поражения: даже если агент успешно injected, он может только обращаться к своему sandboxed-контейнеру со своими scoped-разрешениями. Он не может обращаться к данным других агентов, credential vault или хост-системе.

Ни одна система не может гарантировать полный иммунитет к prompt injection. Подход OpenLegion — минимизировать поверхность атаки и сдержать ущерб.

Угроза 3: злоупотребление ресурсами (Denial of Wallet)

Что происходит. Агент входит в рекурсивный цикл, делает чрезмерные API-вызовы или манипулируется потреблением ресурсов далеко за пределами нужного. В мульти-агентных системах это умножается — workflow на 5 агентов стоит в 5 раз больше одного агента, а сбежавший цикл может сжечь сотни долларов за минуты до того, как кто-то заметит.

Насколько распространено. Это OWASP LLM10:2025 (Unbounded Consumption). Большинство облачных billing-систем не автоматически останавливают charge'и при превышении бюджетов — алерты срабатывают, но счётчик работает. Сообщения сообщества от пользователей CrewAI и LangGraph описывают token-burning циклы, потреблявшие в 10 раз больше ожидаемых бюджетов.

Как OpenLegion это смягчает. Ежедневный и месячный бюджетный контроль на агента с жёстким cutoff. У каждого агента во флоте свой бюджет токенов, отслеживаемый в реальном времени. При достижении лимита слой оркестрации останавливает именно этого агента. Остаток workflow продолжает или приостанавливается gracefully. Никаких «мягких предупреждений», которые игнорируются — cutoff применяется на уровне инфраструктуры.

Угроза 4: эксфильтрация данных

Что происходит. Агент манипулируется отправить чувствительные данные на эндпоинт, контролируемый атакующим. Техники включают: инструктаж агента кодировать данные в URL-параметрах (которые логируются или отправляются через link previews), использование браузера агента для посещения страниц, контролируемых атакующим, или эксплуатация tool calls для пересылки данных во внешние API.

Насколько распространено. Zero-click эксфильтрация продемонстрирована против агентов в мессенджер-платформах (где link previews автоматически забирают URL), корпоративных collaboration-инструментах и репозиториях кода. Исследование банковских агентов показало приблизительно 20% успеха атак эксфильтрации данных.

Как OpenLegion это смягчает. Изоляция сети на уровне контейнера ограничивает, к каким внешним эндпоинтам каждый агент может добраться. Матрица разрешений определяет разрешённые инструменты, файлы и mesh-операции на агента. Исходящие запросы маршрутизируются через контролируемые каналы. В сочетании с изоляцией учётных данных (у агента нет учётных данных для эксфильтрации) и координацией по модели флота (которая логирует каждое действие) поверхность атаки для эксфильтрации значительно уменьшена по сравнению с агентами в общих пространствах процессов с неограниченным сетевым доступом.

Угроза 5: побег из sandbox

Что происходит. Агент или его исполняемый код вырывается из своего контейнера и получает доступ к хост-системе, другим контейнерам или слою оркестрации. Уязвимости container escape обнаруживаются регулярно — несколько high-severity CVE runC были раскрыты в ноябре 2025, затрагивая Docker и Kubernetes у крупных облачных провайдеров.

Как OpenLegion это смягчает. Hardening контейнеров: non-root исполнение (UID 1000), флаг no-new-privileges, настраиваемые лимиты памяти (384 МБ по умолчанию), настраиваемые лимиты CPU (0.15 по умолчанию) и отсутствие общей файловой системы между контейнерами. У каждого агента свой том /data. Модель доверия из четырёх зон (плюс operator-or-internal tier) означает, что даже если агент сбежит из контейнера, он попадёт в зону без прямого доступа к credential vault или контейнерам других агентов. Для сред, требующих более сильной изоляции, архитектура поддерживает Docker Sandbox microVMs.

Угроза 6: атаки на цепочку поставок

Что происходит. Вредоносный код вводится через skills агентов, MCP-tool-серверы, общие конфигурации или зависимости фреймворка. Вредоносные MCP-серверы найдены на npm, маскирующиеся под легитимные сервисы. Crowdsourced конфиг-файлы вооружаются скрытыми LLM-triggered промптами.

Как OpenLegion это смягчает. OpenLegion использует нулевые внешние framework-зависимости — без LangChain, без Redis, без Kubernetes. Ядро — чистый Python + SQLite. MCP-tool-серверы поддерживаются, но изолированы через матрицу разрешений. Координация по модели флота означает, что tool calls явно объявлены в определении workflow, а не динамически обнаруживаются в runtime — уменьшая поверхность для непредвиденной инъекции инструментов.

Как работает изоляция AI-агентов в OpenLegion

Модель доверия из четырёх зон OpenLegion плюс operator-or-internal tier разделяет каждое развёртывание на отдельные security-границы:

Zone 0 — Untrusted External Input. Всё, приходящее от пользователей или третьих сторон: CLI, Telegram, Discord, Slack, WhatsApp и webhook-эндпоинты. Входы валидируются и санитизируются через защиту от prompt-injection до входа в Zone 2.

Zone 1 — Sandboxed Agent Containers (Untrusted). Каждый агент работает как изолированный FastAPI-инстанс в своём Docker-контейнере. У каждого контейнера свой том /data, своя БД памяти (SQLite + векторный поиск), настраиваемые лимиты ресурсов (384 МБ ОЗУ / 0.15 CPU по умолчанию), non-root исполнение (UID 1000), cap_drop=ALL, no-new-privileges, read-only root filesystem и никакого доступа к Docker-сокету, credential vault или контейнерам других агентов.

Zone 2 — Mesh Host (Trusted). Единственный компонент с доступом к учётным данным. Запускает Blackboard (общее состояние + WAL), PubSub router, Credential Vault (slepое прокси-внедрение), ACL-матрицу, Container Manager, Cost Tracker и Browser Service (Camoufox на агента на :8500). Эта зона hardened и не выставлена коду агента.

Zone 2.5 — Operator-or-Internal. Зарезервированные control-plane операции, доступные Operator-агенту или внутреннему mesh-тулингу — управление флотом, правки агентов, грантование разрешений (Operator не может грантовать can_spawn или can_use_wallet).

Zone 3 — Loopback-Only Internal. Самый ограниченный tier: эндпоинты, требующие и заголовок x-mesh-internal: 1, и loopback-source IP. Используется только для mesh-внутренних координационных вызовов.

Эта архитектура означает, что скомпрометированный агент в Zone 1 не может добраться до Zone 2 (учётные данные) или других Zone 1 контейнеров (данные других агентов). Зона поражения от компрометации одного агента ограничена sandbox этого агента.

Управление учётными данными AI-агентов: Vault-прокси vs переменные окружения

Наиболее распространённый шаблон управления учётными данными в AI-агентных фреймворках — переменные окружения. Ваш API-ключ сидит в файле .env или передаётся через OAI_CONFIG_LIST. Процесс агента читает его напрямую. Это означает:

Ключ существует в пространстве памяти агента
Атака prompt injection может проинструктировать агента распечатать или эксфильтровать ключ
Логи, сообщения об ошибках и debug-вывод могут содержать ключ
Если агент скомпрометирован, у атакующего прямой доступ ко всем внедрённым учётным данным

Vault-прокси OpenLegion меняет эту архитектуру фундаментально. API-ключи хранятся в Credential Vault Mesh Host (Zone 2). Когда агенту нужно сделать аутентифицированный API-вызов, он отправляет запрос в vault-прокси. Прокси внедряет учётные данные на сетевом уровне, делает аутентифицированный вызов и возвращает результат агенту. Агент никогда не видит, не хранит и не имеет доступа к памяти с сырым ключом.

Это vault-проксированные учётные данные — тот же принцип, что используется корпоративными системами управления секретами вроде HashiCorp Vault, но встроенный в слой AI-агентной оркестрации, а не требующий отдельной инфраструктуры.

Контейнеризованные AI-агенты: почему изоляции на уровне процесса недостаточно

Несколько фреймворков предлагают какую-то форму изоляции, но детали реализации имеют значение:

Фреймворк	Подход к изоляции	Что реально изолировано	Что общее
OpenLegion	Docker-контейнер на агента (обязательно)	Процесс, файловая система, сеть, память, учётные данные	Ничего — агенты полностью изолированы
OpenClaw	Docker-контейнер (опционально)	Процесс, файловая система	Docker-сокет смонтирован по умолчанию; хост-сеть доступна
LangGraph	Не встроена	N/A	Всё — агенты делят Python-процесс
CrewAI	Docker для CodeInterpreter	Вывод исполнения кода	Процессы агентов делят Python-runtime
AutoGen	Docker для исполнения кода	Вывод исполнения кода	Процессы агентов делят Python-runtime

Критическое различие: OpenLegion изолирует самого агента в контейнере. Другие фреймворки, предлагающие Docker-изоляцию, обычно изолируют только вывод исполнения кода — процесс агента, его память и доступ к учётным данным остаются общими. Это значит, что prompt injection, компрометирующий агента в LangGraph или CrewAI, имеет доступ ко всем учётным данным и состоянию в общем процессе. В OpenLegion та же компрометация ограничена одним sandboxed-контейнером без доступа к учётным данным.

Контроль расходов AI-агентов: принуждение бюджета как безопасность

Контроль расходов — не просто финансовый governance, это security-механизм. Сбежавший агент, потребляющий неограниченные токены, — это атака злоупотребления ресурсами, инициирована ли она вредоносным prompt injection или просто багом в петле рассуждения агента.

Принуждение бюджета OpenLegion работает на уровне оркестратора:

У каждого агента конфигурируемый ежедневный и месячный бюджет токенов
Использование токенов отслеживается в реальном времени Cost Tracker в Zone 2
Когда агент достигает лимита, оркестратор выдаёт жёсткий cutoff — агент остановлен
Остаток workflow продолжает или приостанавливается gracefully
Данные расходов видны в дашборде флота с разбивкой по агентам

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

Комплаенс и аудит-соображения

OpenLegion спроектирован для сред, требующих контролей комплаенса, включая:

Request tracing: аудитируемая координация по модели флота означает, что каждый шаг workflow явный и трассируемый. Встроенная система request tracing записывает переходы задач, tool calls и расход токенов для наблюдаемости в реальном времени. Blackboard (общее состояние) предоставляет контекст координации между агентами.
Аудитируемая координация по модели флота: координация по модели флота (blackboard + pub/sub + handoff) может быть аудирована до исполнения — вы можете проверить полный поток данных, разрешений и взаимодействий агентов без запуска системы.
Изоляция данных: контейнеры на агента с выделенными томами /data обеспечивают, что чувствительные данные, обрабатываемые одним агентом, недоступны другим агентам.
Поддержка air-gap: никаких внешних сервисов (без Redis, без Kubernetes, без облачных сервисов) означает, что OpenLegion может работать в on-premises средах.

Важно: OpenLegion в настоящее время не имеет SOC 2, ISO 27001, HIPAA или других сертификаций комплаенса. Архитектура построена для поддержки сред с этими требованиями, но сертификация — это функция вашего развёртывания, конфигурации и организационных контролей, а не просто фреймворка.

Разверните агентов, безопасных по умолчанию.

Начать Документация

Часто задаваемые вопросы

Что означает AI-безопасность агентов?

AI-безопасность агентов — это набор контролей, предотвращающих нанесение вреда автономными AI-агентами через утечку учётных данных, prompt injection, злоупотребление ресурсами, эксфильтрацию данных, побег из sandbox или избыточную agency. Охватывает runtime-изоляцию (sandboxing агентов), управление учётными данными (предотвращение раскрытия ключей), принуждение расходов (остановка runaway-трат), контроль разрешений (ограничение того, что могут делать агенты) и валидацию входов (фильтрацию вредоносных входов).

Как защитить AI-агентов с API-ключами?

Самый безопасный подход — vault-проксированные учётные данные: храните API-ключи в vault, к которому агенты не имеют прямого доступа. Когда агенту нужно сделать аутентифицированный вызов, запрос маршрутизируется через прокси, внедряющий учётные данные на сетевом уровне. Агент никогда не видит сырого ключа. OpenLegion реализует это через свой vault-прокси в Zone 2 модели доверия из четырёх зон (плюс operator-or-internal tier). Наименее безопасный (и самый распространённый) подход — переменные окружения, где ключи существуют в памяти агента и могут быть утечены через prompt injection, логирование или вывод ошибок.

Как работает изоляция AI-агентов?

Изоляция агентов означает запуск каждого агента в своём sandboxed-окружении — отдельный процесс, файловая система, сетевое пространство имён и пространство памяти. В OpenLegion каждый агент работает в выделенном Docker-контейнере с настраиваемыми лимитами ресурсов (по умолчанию 384 МБ ОЗУ, 0.15 CPU), non-root исполнением и без общей файловой системы. Это значит, что скомпрометированный агент не может обращаться к данным других агентов, credential vault или хост-системе. Это отличается от фреймворков, где агенты делят Python-процесс и могут обращаться к памяти друг друга.

Почему AI-агентам нужен бюджетный / контроль расходов?

Автономные агенты могут входить в рекурсивные циклы, делать чрезмерные API-вызовы или манипулироваться потреблением ресурсов далеко за пределами нужного. Без бюджетного контроля один сбежавший агент может слить сотни долларов в токенах за минуты. В мульти-агентных системах это умножается — каждый агент умножает риск. OpenLegion применяет ежедневные и месячные бюджеты на агента с жёсткими cutoff на уровне оркестратора, не давая одному агенту вызвать неограниченные расходы.

Возможны ли безопасные AI-агенты с BYO-ключами?

Да. Модель BYO (Bring Your Own) ключей фактически более безопасна с правильной архитектурой. В OpenLegion ваши ключи хранятся в Credential Vault Mesh Host и внедряются через vault-прокси на сетевом уровне. Агенты никогда не видят сырых ключей. Это даёт вам полную прозрачность расходов (вы точно видите, что каждый агент тратит у каждого провайдера), гибкость провайдера (меняйте модели на агента) и те же гарантии изоляции учётных данных независимо от того, какого провайдера используете. Используйте свои LLM API-ключи. Никакой наценки на использование моделей.

Что такое OWASP Top 10 для AI-агентов?

OWASP опубликовал Top 10 для Agentic Applications в декабре 2025. #1 риск — Agent Goal Hijacking — где атакующий манипулирует агентом преследовать цели, отличные от пользовательских намерений. Другие топ-риски включают утечку учётных данных, избыточную agency (агенты, совершающие действия за пределами scope) и уязвимости цепочки поставок (вредоносные инструменты или плагины). OpenLegion адресует это через vault-проксированные учётные данные, изоляцию контейнеров, матрицы разрешений и координацию по модели флота (blackboard + pub/sub + handoff).

Как OpenLegion сравнивается с OpenClaw по безопасности?

По публичной документации, OpenLegion предоставляет более строгие настройки безопасности по умолчанию. Локальное развёртывание OpenClaw по умолчанию требует монтирования Docker-сокета (давая широкий доступ к хосту), его security-анализатор имел сообщения о проблемах с последовательной активацией, и он хранит учётные данные в конфигурации, доступной процессу агента. OpenLegion запускает агентов в обязательных изолированных контейнерах, использует vault-прокси для vault-проксированных учётных данных, применяет бюджеты на агента и применяет санитизацию unicode в нескольких choke point. Для детального сравнения см. OpenLegion vs OpenClaw.

Какие фреймворки комплаенса применимы к AI-агентам?

Ключевые фреймворки включают OWASP Top 10 for LLM Applications (2025) и Agentic Applications (2026), NIST AI Risk Management Framework (с предстоящими AI Agent Standards), ISO/IEC 42001 (системы управления AI), EU AI Act (enforcement начинается в августе 2026) и отраслевые регуляции вроде HIPAA, SOC 2 и SOX в зависимости от вашего домена. Архитектура OpenLegion спроектирована для сред, требующих этих контролей, но сама по себе не имеет сертификаций.

Внутренние ссылки

Анкорный текст	Назначение
AI-агентная платформа	/learn/ai-agent-platform
AI-агентная оркестрация	/learn/ai-agent-orchestration
Сравнение AI-агентных фреймворков	/learn/ai-agent-frameworks
AI-безопасность агентов	/learn/ai-agent-security
Альтернатива OpenClaw	/openclaw-alternative
OpenLegion vs OpenClaw	/comparison/openclaw
Документация	/docs
GitHub	https://github.com/openlegion-ai/openlegion