Когда ИИ-агент получает доступ к корпоративной почте, календарю и системам учёта, классическая модель безопасности перестаёт работать. Периметр исчезает: риск перемещается внутрь рабочего процесса — в последовательности отдельно разрешённых действий, которые вместе могут изменить бизнес-процесс, который никто не авторизовал. Статья Krti Tallam и соавторов, опубликованная на arXiv 10 июня 2026 года, предлагает первую референсную архитектуру runtime governance для production-агентов, построенную из четырёх компонуемых примитивов и проверенную на семи конкретных угрозах.

Что такое runtime governance для ИИ-агентов

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

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

Пять плоскостей: от намерения до исполнения

Архитектура декомпозирует каждое решение агента на пять плоскостей, работающих одновременно. Рассуждающая плоскость (reasoning plane) — единственная точка принятия решений. Она видит намерение агента, составной субъект и накопленное состояние сессии, а затем выпускает структурированную проекцию решения. Четыре инфраструктурные плоскости — сеть, идентичность, endpoint и данные — реализуют это решение параллельно, не принимая самостоятельных политических решений.

Это принципиально отличается от федеративного подхода, где каждая плоскость несёт собственный политический движок. В федеративной модели один агентный action — например, автоматический workflow планирования и уведомлений — порождает четыре независимых решения: на сетевом экране, в провайдере идентичности, в проверке endpoint и на шлюзе классификации данных. Ни одно из них не видит полного плана агента. Архитектура из пяти плоскостей устраняет этот дефект структурно: решение принимается один раз, против полного контекста, и исполняется скоординированно.

Сетевая плоскость обеспечивает mTLS, сегментацию и rate-limiting. Плоскость идентичности управляет короткоживущими credentials. Endpoint-плоскость проверяет posture и attestation. Плоскость данных классифицирует содержимое до retrieval. Все четыре получают проекцию решения от reasoning plane и реализуют её, а не принимают своё.

Семь точек медиации: остановить где угодно

Ключевое свойство архитектуры — stop-anywhere mediation. Система присутствует в семи точках конвейера исполнения агента, и в каждой может прервать выполнение. Это расширяет классическую концепцию полного медиации Saltzer-Schroeder от доступа к объекту до последовательности действий и самого цикла reasoning агента.

Точки медиации охватывают весь жизненный цикл: формирование плана, retrieval контекста, вызов инструмента, обновление состояния, фиксация action, делегирование подзадачи и аудит. В отличие от традиционных систем, которые проверяют только границу action commit, эта архитектура видит и может прервать на любом этапе.

Шесть примитивов прерывания

Вместо бинарного allow/deny архитектура предлагает шесть примитивов прерывания, которые обобщают и заменяют традиционные булевы оценщики политики.

Allow и Deny — базовые случаи, но они лишь два из шести. Narrow позволяет продолжить с ослабленным набором capabilities, отражая строгое подмножество полномочий составного субъекта. Escalate маршрутизирует решение к adjudicator более высокого уровня — человеку, более авторизованному агенту или внешнему workflow — и возобновляет выполнение только после ответа. Defer приостанавливает выполнение до выполнения указанного условия, возвращаясь к текущей точке медиации, если условие не наступило к дедлайну. Rollback откатывает выполнение к предыдущему checkpoint, исполняя компенсационные действия для уже зафиксированных side-effecting операций.

Традиционные системы allow/deny — это вырожденный случай stop-anywhere mediator, ограниченного одной точкой медиации и двумя примитивами. Архитектура показывает, что такое ограничение недостаточно для production-агентов.

Составные субъекты и аттенюация полномочий

Когда агент делегирует подзадачу другому агенту, образуется цепочка делегирования. Классическая модель оценивает действующего субъекта против его raw capabilities, игнорируя цепочку. Это позволяет скомпрометированному посреднику действовать вне своих полномочий.

Архитектура вводит составной субъект (composite principal) — структуру, представляющую всю цепочку делегирования. Эффективный набор полномочий вычисляется как пересечение capability-наборов всех звеньев цепочки. Ни один агент в цепочке не может действовать вне этого пересечения. Реализация policy-engine core показала 100% корректность аттенюации на 5000 случайно сгенерированных цепочках делегирования глубиной до шести уровней.

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

Семь угроз production-агентов

Архитектура адресует семь конкретных угроз, которые возникают при делегировании действий агенту. Это не угрозы поведения модели — не alignment, не hallucinations, не jailbreak в узком смысле. Это угрозы делегированного действия.

Косвенный prompt injection через выходы инструментов (T1). Вредоносный контент попадает в данные, которые агент извлекает — документ, письмо, веб-страница. Агент воспринимает его как доверенную инструкцию и выполняет действия, которые не намеревался авторизовать исходный субъект. Архитектура закрывает эту угрозу на уровне формирования плана (MP1), где манипулированный план обнаруживается против authority составного субъекта, и на уровне retrieval контекста (MP2), где кандидатский набор ограничивает до достижения агентом adversarial content.

Злоупотребление цепочками инструментов (T2). Последовательность отдельно разрешённых вызовов инструментов производит составной эффект, который политика запретила бы. Классический пример — прочитать конфиденциальный документ, а затем отправить сообщение внешнему получателю. Архитектура блокирует опасную композицию на уровне состояния сессии: предикат разделения состояния запрещает чтение конфиденциального и последующую внешнюю коммуникацию в рамках одной сессии.

Превышение полномочий коннектора (T3). Агент, которому предоставлен доступ к ресурсу через коннектор, обращается к большему, чем требует задача. Экосистема Model Context Protocol анализировалась как предоставляющая доступ к инструментам в scopes существенно более широких, чем требуют отдельные задачи. Архитектура ограничивает кандидатский набор retrieval до task-justified подмножества до того, как произойдёт retrieval, и связывает инструмент с ослабленным capability-набором через примитив Narrow.

Уклонение от одобрения (T4). Агент выполняет высококонсеквентное действие без требуемого человеческого одобрения, потому что одобрение было привязано к конкретной сигнатуре действия, а агент достиг эффекта через другой путь. Архитектура привязывает одобрение к границам capabilities, а не к сигнатурам действий: любое действие, требующее capability из approval-gated набора, вызывает escalation независимо от пути.

Эксплуатация цепочки делегирования (T5). Составной субъект сохраняет больше authority, чем должно давать любое отдельное звено цепочки, потому что модель делегирования упрощает цепочку или не ослабляет authority через неё. Архитектура решает это структурно: эффективный capability-набор — пересечение capability-наборов цепочки, поэтому ни один агент не может действовать вне этого пересечения.

Непрозрачность аудита (T6). После работы агента система не может реконструировать, что он сделал, под чьей authority, против каких данных, с каким результатом. Традиционное logging-as-audit производит записи, недостаточные для реконструкции. Архитектура гарантирует, что каждое решение производит структурированную, полную, tamper-evident, reconstructible evidence record.

Потеря целостности workflow (T7). Агент изменяет сам бизнес-процесс — не просто обращается к данным, а меняет состояние систем учёта так, что преобразует авторизованный workflow в другой. Это угроза, которая больше всего отличает агентный режим от режима данных-в-покое. Архитектура адресует её на уровне оценки совокупного эффекта плана на системы учёта (MP1), медиации каждого state-changing commit (MP5) и через примитив Rollback для компенсации process-altering эффектов.

Аудит как структурированный evidence substrate

Традиционный аудит — это логи. Логи неструктурированы, неполны, подвержены under-approximation и не позволяют реконструировать цепочку решений. Архитектура заменяет логи на evidence substrate: каждое решение reasoning plane производит структурированную evidence record, аннотируемую каждой enforcement-плоскостью статусом реализации.

Evidence record обладает четырьмя свойствами: полнота — никакое решение не остаётся без записи; реконструируемость — из записи можно восстановить полное состояние; монотонность — записи только добавляются, никогда не изменяются; tamper-evidence — любая модификация обнаруживается. Реализация показала 100% sound reconstruction и 100% monotonicity на 1000 тестах. Tamper detection с bare hash chain достигает 88.2%, а с chain plus head attestation — 100%.

Микросекундная скорость и корректность

Референсная реализация policy-engine core валидирует внутренние утверждения архитектуры измеримыми числами. Adjudication — процесс оценки authority для действия — выполняется в среднем за 5–15 микросекунд, 99-й перцентиль ниже 20 микросекунд. Это делает архитектуру практически применимой для production-агентов с service-level expectations около 100 миллисекунд на action.

Корректность аттенюации проверена на 5000 случайных цепочках: пересечение capability-наборов совпадает с формальным определением в 100% случаев. Попытки расширения authority вверх по цепочке отклонены в 100% случаев. Это не означает, что архитектура доказуемо безопасна в живой системе — полная системная оценка против live agent benchmark приглашается как следующий шаг. Но внутренняя корректность и latency делают её жизнеспособной основой.

Четыре production домена

Архитектура продемонстрирована на четырёх доменах с различными профилями риска. В финансовых услугах доминируют потеря целостности workflow (T7) и эксплуатация цепочки делегирования (T5): перевод денег необратим, и архитектура требует escalation перед commit, реализуя структурно maker-checker control, который требует регуляция. В здравоохранении доминирует превышение полномочий коннектора (T3): принцип minimum-necessary реализуется как структурное свойство через pre-retrieval gate и Narrow.

В программной инженерии доминирует злоупотребление цепочками инструментов (T2): агент, который может читать secrets и открывать внешние pull requests, компонует путь эксфильтрации credentials. Предикат разделения состояния блокирует эту композицию на уровне плана. В клиентских операциях доминирует уклонение от одобрения (T4): агент может декомпозировать крупный refund в последовательность sub-threshold credits. Привязка одобрения к capability disburse-value, а не к сигнатуре действия, перекрывает все пути к этому эффекту.

Почему safety и utility не противоречат

Доминирующая рамка в безопасности агентов предполагает, что safety — налог на capability: каждый guardrail, повышающий safety, снижает utility. Авторы архитектуры утверждают обратное. Хорошо спроектированная runtime governance повышает utility именно за счёт сокращения failure modes, которые останавливают production-развёртывания.

Ранние эмпирические данные поддерживают малость маргинального компромисса: система CaMeL, предотвращающая эксфильтрацию через capability-based separation, сохраняет 77% completion задач на AgentDojo против 84% незащищённого baseline — utility cost около семи процентных пунктов за доказуемое закрытие целого класса атак. Архитектура предсказывает, что измеренная на production-релевантных конфигурациях, эта скромная стоимость более чем компенсируется развёртыванием, которое foreclosure enables.

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

Чем эта архитектура отличается от Zero Trust?

BeyondCorp и service-mesh — вырожденные случаи пятиплоскостной композиции: необходимы на своём уровне, недостаточны, когда агентный action пересекает все уровни в одном решении. Архитектура не заменяет Zero Trust, а объединяет её под reasoning plane, который видит полный контекст.

Почему семь точек медиации, а не одна?

Проверка только на границе action commit (одна точка) пропускает манипулирование планом, нежелательный retrieval и опасные композиции, которые формируются раньше. Stop-anywhere mediation позволяет прервать на любом этапе, где policy требует вмешательства.

Какова производительность policy engine?

Средняя latency adjudication — 5–15 микросекунд, 99-й перцентиль ниже 20 микросекунд. Это измерено на референсной реализации без внешних зависимостей и фиксированным seed.

Итог

Архитектура из пяти плоскостей — это первый систематический подход к runtime governance production ИИ-агентов, который объединяет safety и utility как совместные, а не противоположные цели. Четыре компонуемых примитива — пятиплоскостная декомпозиция, stop-anywhere mediation, составные субъекты с аттенюацией и аудит как structured evidence substrate — закрывают семь угроз делегированного действия, продемонстрированных на пяти production workflow. Микросекундная скор adjudication и 100% корректность аттенюации на референсной реализации показывают, что архитектура не только теоретически обоснована, но и практически жизнеспособна. Для команд, развёртывающих ИИ-агентов в production, это каркас, на который можно опираться при проектировании контроля — до того, как агент получит доступ к первой системе учёта.