При каждой передаче работы между агентами полномочия должны сужаться

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

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

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

Идентичность фиксирует связь, но не ограничивает власть

RFC 8693 даёт полезный язык для этой задачи. Он различает делегирование и имперсонацию. При делегировании действующий субъект сохраняет собственную идентичность, используя права, полученные от другого принципала. Спецификация предлагает примитивы subject token, actor token и claim act для представления этой связи.

На практике различие существенно. Если агент исследований действует с полномочиями, делегированными финансовым принципалом, среда должна уметь назвать и того, кто остаётся ответственным за эти полномочия, и агента, действующего сейчас. Имперсонация, при которой агент считается самим принципалом, стирает важную границу ответственности. Анонимный сервисный вызов стирает обе.

Однако видимая цепочка не является доказательством безопасности. RFC 8693 допускает вложенные claims act для записи истории делегирования, но прямо указывает: предыдущие акторы носят информационный характер и не должны участвовать в решениях контроля доступа. Сервер ресурсов учитывает claims верхнего уровня токена и текущего актора. Цепочка может объяснить происхождение токена, но сама по себе не доказывает, что каждая предыдущая передача была уже предыдущей.

“История делегирования — доказательство для расследования. Ослабление полномочий — инвариант, который нужно принудительно проверять.

Поэтому управляемая среда должна хранить идентичность и полномочия как связанные, но разные объекты. Первый отвечает: какой принципал несёт ответственность и какой актор работает сейчас? Второй: что этот актор может сделать, с какими ресурсами, какими входными данными, до какого времени и вправе ли он делегировать часть этих полномочий дальше?

Делегирование следует моделировать как производное разрешение

Практическая единица здесь — узел разрешения в графе «родитель—потомок». Родительское разрешение уполномочивает конкретного актора в заданных границах. Дочернее называет дочернего актора, ссылается на родительское и содержит такой же или более узкий набор прав. Среда выдаёт его только после проверки вложенности, а затем проверяет те же ограничения при каждом использовании на защищённой границе.

Этот набор прав должен быть структурированным, а не сведённым к одной широкой строке scope. RFC 9396, Rich Authorization Requests, предлагает подходящий примитив: authorization details могут выражать действия, расположения ресурсов, типы данных, привилегии и ограничения конкретной транзакции; пользователь также может одобрить лишь часть запрошенного. Эти объекты сами по себе не обеспечивают рекурсивное ослабление прав. Но они дают словарь, который среда может сопоставлять.

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

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

Не все измерения являются простыми множествами. Денежный потолок — это упорядоченная граница. Лимит расходов ещё и зависит от состояния: среда должна учитывать резервирование или уже израсходованную сумму, а не каждый раз сравнивать исходное число. Ограничения на аргументы могут потребовать языка политик с явно заданным отношением вложенности. Важен не единый синтаксис, а отказ выдавать дочернее разрешение, когда среда не может доказать, что запрошенные границы вложены в родительские.

Проверяйте при выдаче и при использовании

Проверка при выдаче не даёт агенту создать слишком широкое учётное средство. Проверка при использовании не даёт корректно оформленному средству выйти за свои границы. Одно не заменяет другое. Токен может быть корректен по форме, но предъявлен не тому ресурсу, после исчерпания бюджета или после отзыва разрешения предка.

Точка контроля должна находиться на границе сервиса, а не в инструкции для агента. NIST SP 800-207A описывает детализированную авторизацию на основе идентичностей приложений и сервисов, с принудительным контролем во время исполнения через компоненты вроде API-шлюзов и sidecar-прокси. В среде агентов эти границы могут проверить текущего актора, ответственного принципала, идентификатор разрешения, запрошенную операцию и относящиеся к ней ограничения до того, как вызов попадёт в нижележащую систему.

Формат учётного средства — выбор реализации, а не архитектура. Token exchange может передавать отношения subject и actor, а структурированные authorization details — описывать ограниченный запрос. Исследование Macaroons даёт полезный прецедент: последующие учётные средства накапливают caveats, ограничивающие место, время, субъекта и цель использования. Ключевое свойство — монотонное сокращение. Следующая сторона может добавить ограничения, но не убрать их и не придумать более широкие права.

Для отзыва нужна семантика графа

Дерево делегирования создаёт и обязательство по жизненному циклу. RFC 8693 прямо говорит: token exchange в общем случае не создаёт жизненной связи между входными и выходными токенами; распространение отзыва зависит от реализации. Организация не может предполагать, что отзыв родительского токена автоматически отключит потомков.

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

Этот граф — основа и для реагирования на инциденты. При компрометации агента данных поставщиков операторы должны видеть разрешения, которые он получил, разрешения, которые он выдал, затронутые ресурсы и ответственного принципала. Плоский журнал идентичностей участников не даёт такого контура управления надёжно.

Сделайте доказательство видимым операторам

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

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

Для автономных организаций следствие архитектурное. Специализация агентов становится безопаснее не потому, что доверять приходится каждому, а потому, что ни одна передача не может расширить операционный радиус поражения. Координатор распределяет работу, сохраняя вместе с ней лимиты платежей, границы данных, временные окна и права на дальнейшее делегирование. Так организация получает композиционность, не превращая граф задач в неконтролируемый граф привилегий.

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

• Представляйте каждое делегирование как дочернее разрешение со ссылкой на родителя, ответственным принципалом и текущим актором.
• Задайте машиночитаемое отношение вложенности для каждого измерения полномочий, которое делегирует организация.
• Проверяйте вложенность при выдаче дочернего разрешения и проверяйте итоговые ограничения на каждой защищённой границе сервиса.
• Явно определите глубину, срок действия и семантику бюджета; не выводите их из принадлежности к workflow.
• Поддерживайте отзыв с учётом потомков и делайте поведение распространения наблюдаемым.
• Считайте историю доказательством аудита, но не заменой авторизации в настоящем времени.

Проверка здесь бескомпромиссна: если агент делегирует работу, может ли среда доказать, что получатель приобрёл меньше полномочий — и никогда больше? Если нет, система переслала доверие, а не управляла им.