Суть
В прототипе решение о действии и само действие живут в одном месте: модель вернула вызов инструмента, рантайм его исполнил. Пока действия читающие, это незаметно. Как только появляется запись во внешнюю систему, отсутствие границы становится главным архитектурным дефектом: право на действие оказывается функцией вероятностной генерации текста.
Плоскость управления вынимает это право из модели и держит его в трёх механизмах сразу:
- движок политик — что разрешено этому субъекту в этом контексте;
- логика подтверждений — что требует человека (Approval Path);
- шлюз инструментов — что физически может быть исполнено (Tool Gateway).
Ни один из трёх не самодостаточен. Политика без шлюза — декларация, шлюз без политики — жёстко зашитый список, подтверждение без политики — ритуал.
Что она держит
- какими моделями можно пользоваться в этом запуске;
- какие инструменты доступны;
- какие действия требуют подтверждения;
- какие лимиты действуют — по шагам, по стоимости, по времени;
- что запрещено в текущей среде (например, запись в промышленный контур из тестового окружения).
Ключевое свойство: всё это — данные конфигурации, а не код рантайма. Изменение политики не должно требовать релиза, иначе в момент инцидента единственным способом ограничить агента окажется выключить его целиком.
Требование, а не архитектурный вкус
Вынесение решения о праве за пределы модели выглядит как один из возможных способов устроить систему. Это не так: стандарт формулирует его как проверяемое требование — все решения об управлении доступом принимаются кодом приложения или движком политик, «never by the AI model itself» (OWASP AISVS 1.0, C9.5.3). Модель может предложить действие; разрешить его она права не имеет ни в какой конфигурации.
Оттуда же два требования, задающие форму этого слоя: токен ограниченной области, несущий контекст авторизации пользователя и принуждаемый на каждом нижележащем вызове (C9.5.2), и переоценка текущей политики при каждом привилегированном действии долгоживущей сессии (C9.5.6) — вердикт, выданный на старте, не наследуется.
Почему это отдельный слой, а не проверка внутри рантайма
Три практические причины, каждая проявляется не сразу:
- Решение нужно записать отдельно от исполнения. Для расследования важно, что политика сказала, даже если действие не состоялось: отказ — такое же событие, как выполнение (Agent Audit Log).
- Границы прав меняются чаще, чем логика выполнения. Новый арендатор, новое требование комплаенса, новый уровень риска у существующего инструмента — всё это правки политики, и они не должны трогать граф выполнения.
- Один и тот же рантайм обслуживает разные классы риска. Без выделенного слоя различие между «черновик письма» и «отправка письма» приходится размазывать по коду веток.
Как это выглядит на одном запросе
Запрос проходит слой управления до обращения к модели, а не после: сначала известно, что разрешено, и только разрешённые инструменты попадают в описание доступных возможностей. Модель, не знающая о запрещённом инструменте, не может его предложить — это дешевле, чем отклонять предложение потом.
Решение политики полезно оформлять не булевым значением, а объектом: разрешено, запрещено, требует подтверждения, разрешено с ограничением. Булево «да/нет» не выражает третий и четвёртый случай, а именно они и составляют большинство интересных решений.
Проверять надо то множество, из которого будут выбирать
Приём выше — сузить набор инструментов до обращения к модели — имеет вторую половину, о которой забывают чаще. Между решением политики и исполнением почти всегда стоит ещё один шаг выбора: какой из подходящих аккаунтов взять, какое из доступных соединений использовать, какой из равнозначных исполнителей вызвать. Этот выбор делается позже и другим кодом.
Форма дефекта отсюда следует сама: проверка прошла по одному элементу списка, а исполнение взяло другой из того же списка. Формально проверка была, фактически она ничего не гарантирует — и хуже всего то, что расследование покажет успешную проверку.
Лечится это не запоминанием вердикта, а сужением списка. Проверка идёт по каждому элементу по отдельности, и список переписывается ровно до выживших — не остаётся исходным, не схлопывается до одного произвольно выбранного. Тогда «проверено» и «использовано» совпадают по построению, а не по аккуратности того, кто писал шаг выбора.
Разница между двумя способами практическая. Вердикт, привязанный к элементу, надо донести до места выбора, ничего не потеряв, и правильно сопоставить — это три возможности ошибиться, и все три молчаливые. Сужённый список ошибиться не даёт, потому что выбирать больше не из чего.
Что политика вообще способна выразить
Слой описан выше как объект конфигурации, но не сказано, какой формы бывает эта конфигурация, — а форма определяет, какие ограничения выразимы, и режет постановку задачи раньше всех остальных решений.
- По роли — самый распространённый выбор и самый грубый: набор прав привязан к роли субъекта. Выражает «агенту поддержки можно читать заявки», не выражает «этому запуску можно читать заявки этого клиента».
- По атрибутам — права выводятся из свойств субъекта, ресурса и обстановки. Гибче, но правила быстро становятся нечитаемыми, а ответ на вопрос «почему разрешили» приходится восстанавливать вычислением.
- По отношениям — право выражено как ребро графа связей между сущностями: у задачи есть владелец, у владельца — арендатор, у запуска — инструмент. Из такой формы естественно выражается то, что предыдущие две выражают плохо: доступ к инструменту на час, вызов инструмента с конкретным значением параметра, доступ, действующий пока жива породившая его задача.
Последнее и есть довод в пользу отношений применительно к агентам: у агентного действия объём прав почти всегда зависит не от того, кто субъект, а от того, в рамках какой задачи он действует, — а задача это ровно связь, не атрибут. Цена честная: граф отношений — отдельное хранилище со своей моделью данных и своей эксплуатацией, и заводить его до появления таких требований незачем.
Источник задачи входит в решение наравне с субъектом
Права запуска принято выводить из того, кто агент и что за инструмент. Пропускается третья составляющая: кто поставил задачу.
Задача, пришедшая от человека через интерфейс, и задача, прилетевшая от другого агента по межагентному протоколу, — разные по проверяемости источника: во втором случае формулировка уже прошла через модель, а значит могла прийти из недоверенных данных, которые эта модель читала. Отсюда правило: делегированная задача получает прав не больше, а строго меньше, и сужение это входит в решение политики явно, а не подразумевается.
Это тот же принцип, по которому пользовательский контекст сужает права и не расширяет их (Agent Identity), продлённый на цепочку агентов: каждая передача может только убавлять. Без такого правила цепочка делегирований работает как усилитель — задача, начавшаяся с недоверенного текста, добирается до инструмента с полными правами исполнителя, и запись факта делегирования этого не предотвращает, а только позволяет разобрать потом (A2A Task Lifecycle).
Связано с
- Agent Execution Platform — где этот слой стоит среди остальных
- Tool Gateway — исполняющая половина той же границы
- Approval Path — что происходит при решении «требует подтверждения»
- Agent Audit Log — куда пишется решение политики
- Guardrails — фильтрация содержимого, а не прав на действие
- Agent Governance — управление парком агентов уровнем выше
- Deterministic Veto — детерминированная проверка аргументов как часть решения
- Capability Containment — что ограничивает ущерб, если решение оказалось неверным
- Agent Identity — субъекты, между которыми распределяются права, и запись факта делегирования
- Agent Harness — принуждается ли объявленный маршрут; здесь — кто вправе разрешить шаг