Верифицируемые мандаты агентов: от технической идентичности к делегированным полномочиям

Как читать эту справку

Три вида утверждений разграничены, и каждый абзац снабжён меткой:

• Положения черновиков то, что определяют или утверждают сами интернет-черновики, — в близком к тексту пересказе и с короткими цитатами;
• Анализ Института прочтение Институтом того, что черновики решают и что оставляют открытым;
• Учебный вопрос — ARENOMICS Institute вопросы и позиции, которые Институт разрабатывает для преподавания Mandate Engineering.

Эта справка продолжает раздел 3 аналитического материала Института The 10,000-Agent Problem (12 октября 2026 г.), в котором сделан вывод: работа над стандартами идентичности агентов сходится, а работа над мандатами — нет. Статус документов проверен в IETF Datatracker 26 октября 2026 г.

A. Два черновика — два разных вопроса

Статус документов по данным IETF Datatracker на 26 октября 2026 г.

Положения черновиков AIMS начинается словами: «Настоящий документ предлагает рекомендуемые практики аутентификации и авторизации при взаимодействии ИИ-агентов». Черновик о мандатах называет более узкий пробел: «Не определено пока доказательство того, что сторона в корне мандата имела право его предоставить».

Анализ Института Два документа отвечают на разные вопросы. AIMS описывает, как агент доказывает, кто он, и получает доступ в рамках существующей инфраструктуры идентичности; черновик о мандатах спрашивает, как посторонняя сторона в другой организации может проверить, что агент действительно получил заявленные полномочия и что их предоставил тот, кто вправе это делать. Сам черновик о мандатах характеризует своё отношение к AIMS как взаимодополняющее. Ни один из документов не является стандартом; черновик о мандатах — один из восемнадцати индивидуальных черновиков, которые Datatracker в настоящее время относит к связанным с WIMSE, и несколько из них посвящены цепочкам делегирования и доказательствам авторизации.

B. Идентичность агента и аутенти­фикация рабочей нагрузки

Положения черновиков AIMS рассматривает агентов как рабочие нагрузки (workloads). «Агенту, участвующему в данной схеме, ДОЛЖЕН быть присвоен ровно один идентификатор WIMSE, который МОЖЕТ быть SPIFFE ID»; учётные данные агента следует делать краткосрочными, и они должны содержать явно заданный срок действия; агент проходит аутентификацию посредством взаимного TLS, WIMSE Workload Proof Token или HTTP Message Signatures. «Статические ключи API — антипаттерн для идентичности агента». Сама языковая модель «НЕ ДОЛЖНА иметь доступа к учётным данным агента».

Положения черновиков Черновик о мандатах указывает, что доказывает такая идентичность: Workload Identity Token, выданный оператором, удостоверяет идентификатор экземпляра, привязанный к ключу, и ничего не говорит ни о модели, ни о её конфигурации, ни о её поведении.

Анализ Института Идентичность отвечает на два вопроса: какая работающая нагрузка перед нами и может ли она это доказать? Она не сообщает, кто разрешил этой нагрузке действовать, от чьего имени и в каких пределах. Черновики согласуются с картиной, описанной в анализе «10 000 агентов»: идентичность — тот уровень, на котором работа над стандартами сходится.

C. Авторизация и организационные полномочия

Положения черновиков В части авторизации AIMS опирается на OAuth 2.0 как на схему делегирования. В токене доступа агент выступает клиентом, а пользователь или система, от имени которых он действует, — субъектом. Пользователи делегируют доступ через поток authorization code; агенты, действующие от собственного имени, используют client credentials или JWT-разрешение. Токены можно обменять на краткосрочные транзакционные токены, привязанные к одной транзакции, а пересылка токена агента нижестоящим сервисам названа антипаттерном. Сами транзакционные токены, связывание идентичностей и JWT-разрешение на основе утверждения об идентичности определены в интернет-черновиках, работа над которыми не завершена. Если действие должен подтвердить человек, агент «НЕ ДОЛЖЕН считать подтверждение в локальном интерфейсе само по себе достаточной авторизацией».

Анализ Института Разрешение OAuth (grant) фиксирует, что пользователь или система согласились предоставить клиенту доступ в определённых пределах. Оно не фиксирует, вправе ли было это лицо внутри своей организации наделять такими полномочиями, — например, имел ли сотрудник, подключивший казначейского агента к банковскому счёту компании, полномочия принимать от имени компании платёжные обязательства. Техническая авторизация и организационные полномочия — разные отношения: первая может быть безупречной при полном отсутствии вторых.

D. Мандаты, утверждения о полномочиях и верификация

Положения черновиков Черновик о мандатах разделяет роли, которые обычно сливаются: принципал, от имени которого действует агент; делегирующее лицо (delegator), предоставляющее корневой мандат, — сам принципал или лицо, уполномоченное действовать от его имени; источник сведений о полномочиях (authority source), удостоверяющий, что делегирующее лицо такими полномочиями обладает; эмитент мандата, подписывающий мандат по указанию делегирующего лица; экземпляр агента; и доверяющая сторона в другом домене. В качестве примеров приводятся казначейский агент компании, инициирующий платёж в банке компании, и агент брокера, направляющий поручение депозитарию.

Положения черновиков Далее черновик разводит два подписанных утверждения. Утверждение о мандате (Mandate Assertion) свидетельствует, что мандат был предоставлен; утверждение о полномочиях (Authority Assertion), выдаваемое источником сведений о полномочиях — например, реестром законных представителей, — свидетельствует, что делегирующее лицо было вправе его предоставить. Черновик указывает: «одно лишь утверждение о мандате никогда не устанавливает полномочий делегирующего лица». Черновик не предписывает, какие источники сведений о полномочиях допустимы; применительно к Европейскому союзу он отмечает, что утверждения могут формироваться на основе электронных удостоверений атрибутов согласно Регламенту (ЕС) 2024/1183.

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

Анализ Института Предложение прямо касается вопроса, с которого начинается Mandate Engineering: не только что агенту позволено делать, но и имел ли тот, кто это разрешил, право так распорядиться. Вклад черновика в том, что второй вопрос становится проверяемым для стороны, не доверяющей первой организации. Его зависимость столь же очевидна: проверка надёжна ровно настолько, насколько надёжны источник сведений о полномочиях и рамочная схема доверия, определяющая, какие источники признаются, — а их черновик намеренно не определяет.

E. Цепочки делегирования и сужение полномочий

Положения черновиков Согласно черновику о мандатах, агент может передоверять полномочия лишь в пределах допустимой максимальной глубины. Каждый дочерний мандат должен истекать не позднее родительского и должен быть сужен (attenuation): любой запрос, соответствующий дочернему мандату, должен соответствовать и родительскому. Накопительные бюджеты передаются по цепочке, поэтому действия субагентов засчитываются в тот же лимит. Черновик указывает и на ограниченность одного лишь сужения: «Цепочка, которая только сужается, доказывает, что ни одно звено не превысило родительское», — но не то, что корневой мандат находился в пределах собственных полномочий делегирующего лица.

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

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

F. Отзыв, срок действия, ограничения исполнения и доказательства для аудита

Положения черновиков Черновик о мандатах выражает ограничения в виде машинно-проверяемых предикатов — равенство, принадлежность множеству, максимум, минимум и временное окно, — а также двух предикатов с состоянием: накопительный бюджет за скользящий период и требование второй подписи сверх порога. Суммы записываются десятичными строками: «Для сумм НЕ ДОЛЖНЫ использоваться числа JSON». Каждый токен санкционирует однократное исполнение действия; срок его действия ограничен самым ранним сроком истечения в цепочке; статус отзыва проверяется при верификации и повторно при авторизации. О задержке черновик говорит, что отзыв после выдачи «вступает в силу не позднее момента истечения срока действия токена». Доверяющим сторонам следует сохранять результат проверки, решение и подтверждение исполнения, а записи, хранимые на случай споров, могут потребоваться в проверяемом виде годами.

Положения черновиков AIMS требует вести долговременные журналы аудита решений об авторизации и мер по устранению последствий с фиксацией, в частности, идентификатора агента, субъекта делегирования, ресурса, действия и решения: «Записи аудита ДОЛЖНЫ обеспечивать обнаружение изменений и храниться в соответствии с политикой безопасности развёртывания». Сигналы об отзыве и рисках могут распространяться через Shared Signals Framework, и получатели «ДОЛЖНЫ обеспечивать применение отозванной или пониженной авторизации без неоправданной задержки».

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

G. Нерешённый уровень: от организационного намерения к технически исполнимым разрешениям

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

Положения черновиков Черновик о мандатах не «определяет рамочную схему доверия, уровни доверия или юридическую силу мандата», равно как и то, как мандат предъявляется делегирующему лицу и как выражается его согласие, и то, верны ли рассуждения или результаты агента. «Формат позволяет выражать узкие мандаты, но не может заставить эмитентов их составлять». И о манипуляции: «Действительный мандат показывает, что действие находится в пределах делегированных полномочий, но не то, что агента не склонили к запросу этого действия путём манипуляции».

Анализ Института Черновики делают проверяемым результат перевода, но не выполняют и не проверяют сам перевод. Отражает ли мандат вида «оплачивать утверждённых поставщиков в пределах месячного бюджета» то, что имел в виду совет директоров, верны ли ограничения и кто отвечает, если действительный мандат приводит к вредному действию, — остаются вопросами организационными и правовыми. Именно этот уровень анализ «10 000 агентов» назвал неразработанным. После выхода этих черновиков он остаётся неразработанным, но теперь с одной стороны у него есть более чёткая техническая граница.

H. Что черновики решают для Mandate Engineering — и что оставляют открытым

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

Учебный вопрос — ARENOMICS Institute Институт рассматривает эти документы как свидетельство того, что вопрос о мандатах вошёл в обсуждение технических стандартов, а не как стандарты для преподавания. В программе Foundation они могут служить учебными примерами того, как ограниченный и отзываемый мандат может быть выражен и проверен. Программа не требует от слушателей их использования, и её спецификация не меняется.

Открытые исследовательские вопросы

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

Источники

1. C. Hulea (Braincap SRL). Verifiable Mandates for Agents Acting Across Administrative Domains. draft-hulea-wimse-agent-mandate-00, индивидуальный интернет-черновик, 24 октября 2026 г., истекает 27 апреля 2027 г. Datatracker · полный текст.
2. P. Kasselman, J.-F. Lombardo, Y. Rosomakho, B. Campbell, N. Steele, A. Parecki. AI Identity Management System. draft-ietf-wimse-aims-00, интернет-черновик рабочей группы WIMSE, 15 сентября 2026 г., истекает 19 марта 2027 г. datatracker.ietf.org/doc/html/draft-ietf-wimse-aims-00.
3. IETF, рабочая группа Workload Identity in Multi System Environments (WIMSE), страница документов, просмотрено 26 октября 2026 г. datatracker.ietf.org/group/wimse/documents.
4. ARENOMICS Institute. The 10,000-Agent Problem: Who Has the Authority to Let Machines Act? v0.1, 12 октября 2026 г.

Проверка: названия, авторы, даты, статус и все цитаты сверены с документами и Datatracker 26 октября 2026 г.; цитаты переведены с английского оригинала. Интернет-черновики часто меняются; прежде чем опираться на какую-либо деталь, проверьте текущую редакцию в Datatracker.