Top.Mail.Ru

Безопасность ИИ-агентов в корпоративном контуре: 6 компонентов архитектуры, без которых не запустить пилот

Архитектура безопасности ИИ-агента
Шесть слоёв защиты вокруг агента — от identity до runtime monitoring

TL;DR

Корпоративные команды перешли от вопроса «что такое агент» к запуску в прод — и упёрлись не в качество моделей, а в архитектуру безопасности. Ниже — рамка из 6 инженерных компонентов, собранная из публичных рекомендаций OpenAI и практик российских корп-платформ. В конце — чек-лист «что закрыть до пилота» и развилка SaaS против закрытого контура под 152-ФЗ.


Зачем читать сейчас

72 часа — столько потребовалось ИИ-агенту в кейсе UNC6426 (март 2026). За это время он прошёл путь от первого коммита до прав администратора в AWS-окружении заказчика. Рынок перешёл от «давайте попробуем агента» к «давайте поставим его в прод», и блокером оказалась не модель, а архитектура. Ниже — рамка из 6 компонентов и чек-лист, который полезно прогнать перед запуском любого пилота.

Ещё в декабре 2023 OpenAI опубликовал документ «Practices for Governing Agentic AI Systems» — базовую рамку из семи практик. Это: оценка пригодности задачи, ограничение пространства действий с обязательным approval, заданное поведение по умолчанию, легибильность действий агента, автоматический мониторинг, атрибутируемость и интерруптируемость. Параллельно на российском рынке закрепились корп-платформы со своим набором controls — SimpleOne GenAI, BPMSoft AI, ELMA Cortex. Пора собрать из этого чек-лист.

36,82%
агентских скиллов содержат уязвимости (Snyk, 2026, выборка 3 984)
13,4%
из них критические — RCE, утечка ключей
10,9%
хранят учётные данные в открытом виде
CTO или Head of Engineering, который запускает агентов в прод
запрос

У команды уже есть пилот ИИ-агента или план запустить его в ближайший квартал. Безопасность — следующий вопрос, а не первый.

что найдёте в статье 🔥

Чек-лист 6 компонентов архитектуры безопасности — то, что нужно закрыть до запуска. Без хайпа и без рекламы конкретных вендоров.

Что такое агент в корп-контексте

Агент — не «чат с памятью». Это система с инструментами через function calling, которая принимает решения и совершает побочные эффекты во внешних системах: создаёт тикеты, пушит коммиты, переводит средства, рассылает письма. Каждый такой шаг — потенциальное действие в проде.

OpenAI делит жизненный цикл агента на четыре роли: Developer (строит модель), Deployer (разворачивает и конфигурирует), User (направляет задачи), Affected Party (на кого влияют действия). Корпоративная команда обычно сидит на роли Deployer. И именно её зона ответственности — архитектура безопасности.

6 компонентов архитектуры безопасности

Identity и permission boundaries

У агента должна быть собственная identity, не унаследованная от пользователя. Привязка — к корпоративному IdP через SSO (SAML 2.0, OIDC, LDAP/AD). RBAC отвечает на вопрос: какие инструменты этому агенту доступны и в каких системах.

Этот компонент закрывает privilege escalation и действия от имени админа. Без него каждый tool call расширяет атакующую поверхность до прав того, кто запустил агента.

Guardrails: input, output, tool

Agents SDK от OpenAI делит guardrails на три слоя. Input guardrails валидируют пользовательский ввод до запуска агента — отлавливают jailbreak, PII, вредоносные инструкции. Output guardrails проверяют финальный ответ перед отправкой — блокируют утечку чувствительных данных. Tool guardrails оборачивают вызовы функций до и после исполнения; срабатывание триггерит исключение InputGuardrailTripwireTriggered или OutputGuardrailTripwireTriggered и останавливает агента.

Tool guardrails работают только на function-tools — не на handoffs или hosted tools. Tripwire — это «стоп», а не «осторожно продолжаем».

OpenAI по входному слою формулирует прямо: вход чистится встроенными guardrails, чтобы редактировать PII и ловить jailbreak. Anthropic параллельно строит цепочки классификаторов поверх Constitutional Classifiers — индустрия движется к многоэтапной верификации. Системный промпт отсекает массовые атаки, но от целенаправленной не защитит — нужна архитектурная защита, не prompt-инжиниринг.

🔥 Что бывает, когда guardrails нет

Кейс Amazon Q Developer: промпт-инъекция целилась на форматирование дисков на машинах разработчиков. Кейс RoguePilot (февраль 2026): GITHUB_TOKEN утёк через HTML-комментарий в Issue — агент обработал инструкцию, скрытую от человеческого глаза в разметке, и выполнил её.

Tool sandboxing и human approval

Каждый tool call — потенциальная запись в прод. Гайд OpenAI Agent Builder говорит про MCP-инструменты прямо: «When using MCP tools, always enable tool approvals so end users can review and confirm every operation, including reads and writes». Принцип масштабируется на любой агентский контур: в корпоративном сценарии разумен двухконтурный approval — для read-операций авто, для write — ручной.

Структурированные схемы между нодами агентского графа убирают free-text каналы, через которые проходит prompt injection. Тот же гайд OpenAI рекомендует фиксировать схемы межнодовых выходов — enums, обязательные поля, фиксированные структуры. Так из пайплайна исчезают свободные текстовые каналы, которыми пользуются нарушители.

Подход видно на архитектуре OpenAI Codex: sandbox, подагент auto_review для рутины, allowlist по доменам, prefix_rule для shell. Принцип одной фразой: низкорисковые действия — без остановок, высокорисковые — с проверкой.

Data isolation

Токенизация чувствительных полей (PII, ПДн, банковская тайна) до их попадания в контекст модели — стандартный паттерн. ELMA Cortex описывает его в составе своего набора: «guardrails, токенизация чувствительных данных, аудит общения с LLM». Маршрутизация решает второй вопрос: какие данные допустимы во внешние SaaS-модели (никакие, если речь о ПДн), какие — только в локальные.

Маршрутизация моделей — один из мотивов, ради которых OnPrem-конфигурация в платформах вроде AlpinaGPT существует отдельно от Cloud. К ней же подтягиваются SSO, SIEM-интеграция и изоляция данных в принципе. Один контур обращается к публичным API, другой — только к локальным эндпойнтам через OpenAI-совместимый интерфейс (Ollama, vLLM). Граница задаётся политикой, а не привычками разработчика.

Этот компонент закрывает утечку ПДн в обучение внешних моделей и нарушение 152-ФЗ.

Audit и SIEM logging

Каждый агентский шаг — prompt, tool call, response, decision — должен лечь в SIEM заказчика, а не в дашборд вендора. OpenAI описывает это как «legibility of agent activity»; в Agents SDK реализуется через custom trace processors. Codex работает по той же логике: OpenTelemetry-логи с полным контекстом и ИИ-классификатор поверх.

Российский эквивалент — практика SimpleOne GenAI: гранулярный AI Task Step logging с биллингом по департаментам и ролевой моделью. В обзоре платформы тезис формулируется так: «логирование сообщений, библиотека, ролевая модель».

Без этого слоя инцидент превращается в чёрный ящик: ни forensics, ни compliance-аудита.

Runtime monitoring и interruptibility

Agent watchdog — отдельный сервис, который мониторит других агентов. Это укладывается в рамку OpenAI: и автоматический мониторинг, и интерруптируемость входят в её базовые семь практик. Метрики, которые имеет смысл собирать: rate of tool errors, аномальные последовательности tool calls, drift по latency. Кнопка kill-switch — обязательна.

Слой закрывает runaway loops и сценарий, когда агент уходит за пределы своих capability bounds. Сами авторы ELMA Cortex формулируют это иначе, но с тем же выводом: «качественные процессы и структурированные данные — это лучшая почва для ИИ».

🪪
Identity & permissions
Собственная identity агента, привязка к IdP, RBAC по инструментам
🛡️
Guardrails
Input + output + tool-слои, tripwire останавливает выполнение
Tool sandboxing
Sandbox + human approval на write, structured outputs против prompt injection
🔒
Data isolation
Токенизация ПДн, маршрутизация какие данные куда уходят
📜
Audit & SIEM
Каждый шаг агента в SIEM заказчика, не в дашборд вендора
⏸️
Runtime monitoring
Watchdog-агент, метрики, kill-switch

Что из этого недоступно в SaaS

Разбор официальной страницы «Safety in building agents» от OpenAI показывает: SaaS-сборка покрывает guardrails, structured outputs и tool approvals. А tool sandbox на инфраструктуре заказчика, audit в SIEM заказчика, network egress controls и отдельные permission boundaries для агента — не покрывает или покрывает частично. Именно здесь возникает требование закрытого контура.

Привязка к 152-ФЗ простая. Персональные данные нельзя отдавать во внешние API — точка. Если агент работает с обращениями клиентов, кадровыми данными или финансовыми операциями, закрытый контур перестаёт быть опцией. Он становится условием запуска.

Чек-лист «что сделать перед запуском агента»

  • У агента есть собственная identity, привязанная к корпоративному IdP через SSO
  • Настроены input, output и tool guardrails; tripwire останавливает выполнение, а не «продолжает осторожно»
  • Все write-операции tool-ов идут через human approval; read-операции логируются
  • PII и ПДн токенизируются до попадания в контекст модели
  • Каждый шаг агента (prompt, tool call, response) уходит в SIEM заказчика
  • Прописаны capability bounds — какие инструменты и в каких системах агент в принципе не может вызвать
  • Есть watchdog-агент, мониторящий аномалии, и kill-switch (к чему стремиться — в РФ-проектах пока редко реализовано)
Хотите поставить такой агент в своём контуре?

AlpinaGPT можно развернуть в закрытом контуре под 152-ФЗ — обсудим архитектуру под вашу инфраструктуру и тип агентских сценариев. А если команде сначала нужно научиться уверенно работать с ИИ — начните с практикума, и затем перенесём процессы в OnPrem.

Обсудить ваш сценарий →