Суть
В прототипе решение о действии и само действие живут в одном месте: модель вернула вызов инструмента, рантайм его исполнил. Пока действия читающие, это незаметно. Как только появляется запись во внешнюю систему, отсутствие границы становится главным архитектурным дефектом: право на действие оказывается функцией вероятностной генерации текста.
Плоскость управления вынимает это право из модели и держит его в трёх механизмах сразу:
- движок политик — что разрешено этому субъекту в этом контексте;
- логика подтверждений — что требует человека (Approval Path);
- шлюз инструментов — что физически может быть исполнено (Tool Gateway).
Ни один из трёх не самодостаточен. Политика без шлюза — декларация, шлюз без политики — жёстко зашитый список, подтверждение без политики — ритуал.
Что она держит
- какими моделями можно пользоваться в этом запуске;
- какие инструменты доступны;
- какие действия требуют подтверждения;
- какие лимиты действуют — по шагам, по стоимости, по времени;
- что запрещено в текущей среде (например, запись в промышленный контур из тестового окружения).
Ключевое свойство: всё это — данные конфигурации, а не код рантайма. Изменение политики не должно требовать релиза, иначе в момент инцидента единственным способом ограничить агента окажется выключить его целиком.
Почему это отдельный слой, а не проверка внутри рантайма
Три практические причины, каждая проявляется не сразу:
- Решение нужно записать отдельно от исполнения. Для расследования важно, что политика сказала, даже если действие не состоялось: отказ — такое же событие, как выполнение (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 — принуждается ли объявленный маршрут; здесь — кто вправе разрешить шаг