ARENOMICS INSTITUTE
Институциональный анализ · v0.1 · 12 октября 2026 г. · русская версия англоязычного исследовательского ресурса

Проблема 10 000 агентов: кто вправе разрешить машинам действовать?

Прочтение опубликованных материалов сентября–октября 2026 года об идентичности, разрешениях, согласовании, делегировании и аудите агентов — и о слое, который они оставляют без внимания: преобразовании миссии организации в ограниченный, машинно-обеспечиваемый и отзываемый мандат.

Статус. Исследовательский анализ в стадии разработки; позиции принадлежат Институту, за исключением случаев, где указана атрибуция. Институт не состоит в отношениях ни с одной из названных организаций. Статус проектов документов, даты дорожных карт и принятие стандартов часто меняются; проверяйте текущее состояние по первоисточникам. Русская версия является переводом англоязычного оригинала (The 10,000-Agent Problem: Who Has the Authority to Let Machines Act?). См. также: Agent Fleet Governance: Applied Case Lab (предложение) · Демонстрация ME-001

Резюме

За один год вопрос, стоящий перед предприятием, сместился с как правильно инструктировать модель к кто уполномочил этого актора, что он вправе легитимно делать, как далеко он может делегировать полномочия, кто за него отвечает, как его остановить и что доказывает, оставался ли он в рамках своего мандата. Поставщики теперь выпускают агентов, которые работают, пока пользователь отсутствует, обладают собственными идентичностями и оплачиваются по потреблению; органы по стандартизации готовят проекты профилей идентичности, делегирования и авторизации агентов; организации в области безопасности относят «избыточную агентность» к главным рискам года. Настоящий анализ рассматривает опубликованные материалы сентября–октября 2026 года и приходит к выводу, что три слоя быстро созревают — техническая идентичность, техническое разрешение и согласование во время выполнения, — тогда как четвёртый слой остаётся в основном без внимания: преобразование миссии организации или бизнес-инструкции в ограниченный, машинно-обеспечиваемый и отзываемый мандат, легитимность которого можно реконструировать по доказательствам. Этот четвёртый слой — предмет Mandate Engineering (инжиниринга мандатов) и причина, по которой Институт предлагает лабораторию Agent Fleet Governance: Applied Case Lab и учебный кейс ME-001.

1. Что изменилось в сентябре 2026 года

25 сентября 2026 года Microsoft объявила о реорганизации Copilot в три пространства — Home, Code и Autopilot — в публикации за подписью Джареда Спатаро (Jared Spataro), директора по маркетингу направления AI at Work [1][2]. Home объединяет чат с делегированными задачами «Cowork»; Code позволяет неразработчикам описывать приложения на естественном языке; Autopilot — постоянно действующий агент, который продолжает работать, пока пользователь отсутствует [1][2]. Вторичные источники добавляют, что Autopilot получает имя, роль и цель, обладает собственной идентичностью, памятью и рабочим пространством внутри арендатора (tenant), может быть упомянут через @ в Teams и Outlook и действует «в рамках разрешений и правил управления организации»; Home и Code развёртываются через программу Frontier, а Autopilot в конце сентября перешёл в закрытое предварительное тестирование [3].

Для вопроса о полномочиях важны две особенности объявления. Во-первых, агент больше не является сеансом: он постоянен, хранит состояние и действует между взаимодействиями. Во-вторых, модель оплаты Microsoft разделяет лицензию на пользователя и оплачиваемые по использованию «Copilot Credits» для агентной работы, с административными средствами управления политиками расходов для групп, месячными лимитами, лимитами на пользователя и запросами кредитов, которые согласовывает администратор [3][4]. Таким образом, потолок расходов для агентов — опубликованный продуктовый механизм контроля. Чего объявление не описывает — в рассмотренных нами опубликованных материалах — так это согласования каждого действия Autopilot, того, как пользователь или администратор приостанавливает или отзывает полномочия работающего Autopilot, как его действия проверяются постфактум и какие системы он вправе изменять [2]. Мы отмечаем отсутствие; мы не делаем вывода, что такого механизма не существует, поскольку Autopilot находится в закрытом предварительном тестировании и документация может появиться позже.

2. Опубликованные Microsoft механизмы разрешений и согласования

Стек управления агентами, документированный Microsoft, полнее, чем предполагает публикация о запуске, и его поучительно читать как слоистую систему.

Идентичность. С мая 2026 года каждый новый агент Copilot Studio получает Microsoft Entra Agent ID — идентичность в Entra с журналированием аудита, управлением жизненным циклом и интеграцией с Entra ID Governance; разрешения коннекторов привязываются к идентичности агента как разрешения API при публикации, видны администраторам, могут быть целью политик условного доступа (Conditional Access: сетевое расположение, соответствие устройства требованиям, риск) и повторно проверяются во время выполнения средой коннекторов на соответствие политикам данных [5]. Удаление агента удаляет идентичность [5]. Прочитанная нами документация не описывает отдельного процесса согласия, явной операции отключения или отзыва идентичности агента (помимо удаления и условного доступа) или семантики «от имени» (on-behalf-of), связывающей агента с создавшим его пользователем [5].

Согласование во время выполнения. Элемент дорожной карты Microsoft 365, опубликованный 1 сентября 2026 года (RM570434), позволяет создателям агентов требовать согласования человеком перед вызовом агентом конкретного инструмента: переключатель на уровне инструмента и агента приостанавливает выполнение, выводит запрос на согласование непосредственно в Teams или Microsoft 365 Copilot с описанием того, что агент намерен сделать, и позволяет проверяющему согласовать один раз, согласовать на сеанс или отказать; механизм представлен как детерминированный контроль, независимый от инструкций агента, и предназначен для таких действий, как отправка электронной почты, закрытие заявок или проведение платежей [6]. Кто вправе согласовывать, как назначаются проверяющие и что происходит по истечении времени ожидания, не указано [6].

Плоскость управления. Agent 365, описанный в публикациях сентября 2026 года, предоставляет единый реестр, в котором каждый агент перечислен с его идентичностью, владельцем, разрешениями и историей использования на платформах Microsoft и третьих сторон; представление инструментов, в котором администраторы блокируют рискованные серверы MCP, плагины и коннекторы и согласовывают или отклоняют новые запросы на инструменты; средства управления политиками, доступом и наблюдаемостью, обеспечиваемые через Entra, Purview, Defender и Intune; и изоляцию несанкционированных локальных агентов [7]. Аудит охвачен косвенно через историю использования; ни отзыв полномочий агента, ни аварийный выключатель в этих терминах не описаны [7].

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

3. Стандарты: идентичность сходится, мандат — нет

Рабочая группа IETF WIMSE (Workload Identity in Multi-System Environments, учреждена в 2024 году) — основная площадка для идентичности агентов; её архитектурный проект достиг версии 07 в марте 2026 года [8]. Индивидуальная заявка WIMSE Applicability for AI Agents (draft-ni-wimse-ai-agent-identity-03, 1 октября 2026 года) предлагает, чтобы агенты обладали собственными учётными данными рабочей нагрузки, криптографически привязанными к владельцу — ответственному лицу или организации — через учётные данные с двойной идентичностью, с моделями выпуска при посредничестве агента, владельца и сервера, аттестацией при начальной загрузке и обновлении и аппаратным корнем доверия [9]. Проект заявляет цели краткосрочных учётных данных и узких, ориентированных на задачу токенов, но не определяет модели области действия; цепочки делегирования, отзыв и записи аудита не рассматриваются, раздел о безопасности помечен TODO, а распространение якорей доверия явно вынесено за рамки [9]. Отдельный информационный проект (draft-klrc-aiagent-auth-00) профилирует обмен токенами OAuth 2.0 так, чтобы собственная клиентская идентичность агента была отделена от делегированного субъекта, разрешения не накапливались вдоль цепочек вызовов «агент — агент», токены были краткосрочными и ограниченными по аудитории, отзывы распространялись через OpenID Shared Signals Framework, а подробное журналирование аудита было базовым требованием [10]. Ни один из них не принят как документ рабочей группы и не продвинут до статуса Proposed Standard; терминология не сошлась; предлагаемая группа по обнаружению (DAWN) явно исключает стабильные идентификаторы и управление доверием из своей первой фазы [10].

Со стороны менеджмента ISO/IEC 42001:2023 определяет систему менеджмента ИИ (AIMS) — организационные политики, цели, оценку рисков и воздействия, средства контроля и сертификацию системы менеджмента, а не продукта [11]. Это естественная площадка для структур подотчётности, однако рассмотренные нами публичные описания не затрагивают автономных агентов или делегирование им полномочий конкретно [11].

Со стороны безопасности OWASP Top 10 для LLM-приложений 2026 года (3 августа 2026 года) переместил избыточную агентность (Excessive Agency) — больше автономии, разрешений или неконтролируемого охвата, чем требует задача, — с шестого на третье место, взвесив 6 639 реальных инцидентов; отдельный OWASP Top 10 для агентных приложений (декабрь 2025 года) называет злоупотребление идентичностью и привилегиями, неправомерное использование инструментов и каскадные многоагентные сбои; а Agent Control Standard версии 0.1, переданный проекту OWASP GenAI Security Project в сентябре 2026 года, предлагает точки обеспечения с «агентами-хранителями», трассировку OpenTelemetry/OCSF и Agent Bill of Materials — при этом обеспечение в режиме запрета/изменения запланировано на более позднюю версию, а требование шагов согласования человеком или аварийных выключателей не заявлено [12].

4. Слой без внимания: от миссии к мандату

Расположим опубликованные механизмы на одной оси от технического к организационному:

Слой Вопрос Опубликованное состояние (сент.–окт. 2026)
Техническая идентичность Какая это рабочая нагрузка и кто ею владеет? Поставляется (Entra Agent ID); проекты сходятся (WIMSE) [5][8][9]
Техническое разрешение Что она может вызывать и при каких условиях? Поставляется (разрешения API, условный доступ, блокировка инструментов) [5][7]
Согласование во время выполнения и расходы Может ли она сделать это сейчас и сколько она может потратить? Поставляется / развёртывается (согласование по инструментам; лимиты кредитов) [4][6]
Делегирование Как полномочия передаются по цепочке без накопления? В проекте (профиль обмена токенами); не принят [10]
Организационный мандат Чего она уполномочена достичь, в каких границах, с какими зарезервированными решениями и лимитами, под чьей ответственностью, и как это останавливается и верифицируется? Не рассматривается в изученной нами продуктовой документации и проектах
Юридическая правомочность Обладал ли принципал делегируемой властью? Вне всех перечисленных выше механизмов

Для предприятия с большой совокупностью агентов отсюда следуют три последствия, и каждое воспроизводимо как учебный сценарий в ME-001:

  1. Разрешено по отдельности, не санкционировано в совокупности. Разрешение и лимит кредитов на пользователя ограничивают каждого агента; они не ограничивают предприятие. Триста платёжных агентов, каждый в пределах лимита, могут превысить казначейский потолок, который ни один из механизмов раздела 2 по умолчанию не оценивает (ME-001 S2). Совокупные лимиты должны проектироваться как лимиты мандата с оценщиком, который завершается безопасным отказом, когда совокупное состояние неизвестно.
  2. Согласованный инструмент, изменённый план. Согласование по инструментам контролирует, какая возможность используется, а не является ли план, который агент теперь предлагает, тем планом, который был санкционирован. Агент, который не может отправить груз перевозчиком A и предлагает перевозчика B по более высокой цене, вызывает тот же инструмент (ME-001 S3). Повторное санкционирование при изменении плана — понятие мандата, а не разрешения.
  3. Зажурналировано — не значит легитимно. Журналирование аудита в каждом из описанных стеков фиксирует, что действие произошло под некоторой идентичностью. Оно не фиксирует, что для него существовал действительный мандат, что мандат находился в пределах полномочий владельца или что полномочия владельца были легитимны (ME-001 S6). Достаточность доказательств должна проектироваться: записи решений, называющие версию мандата, оценённые границы, совокупное состояние и акт согласования, хешированные и воспроизводимые.

К этому добавляются вопросы масштаба совокупности агентов, которые проекты оставляют открытыми: отзыв родительского мандата, пока делегированные задачи ещё ожидают исполнения (S5), наследование, которое сужает, а не создаёт (S1), и компрометация идентичности, обрабатываемая как приостановка и инцидент, а не как повторная попытка (S4).

5. Что поставщики могут сделать уже сегодня и что остаётся исследовательским вопросом

Установлено по опубликованным материалам: предприятия могут давать агентам идентичности и владельцев, перечислять и обусловливать их разрешения, требовать согласования человеком по каждому инструменту, ограничивать расходы, регистрировать и блокировать инструменты и изолировать несанкционированных агентов [4][5][6][7]. В проекте, но не стандартизировано: учётные данные с двойной идентичностью, привязанные к владельцам, делегирование через обмен токенами без накопления разрешений, распространяемые сигналы отзыва [9][10]. Исследовательские вопросы, по которым Институт занимает позицию: как цель организации декомпозируется в мандаты с проверяемыми границами и зарезервированными решениями; как специфицируются и обеспечиваются совокупные и портфельные лимиты для совокупностей агентов; что содержит достаточная запись доказательств полномочий (а не только действия); как верифицируются каскады отзыва полномочий; и как всё это оценивается как профессиональная компетенция, а не задача конфигурирования. Ни один из них не решается продуктовой функцией, и Институт не утверждает, что какой-либо поставщик или орган по стандартизации потерпел неудачу, — лишь то, что изученные нами опубликованные работы рассматривают другие слои.

6. Следствия для профессиональной подготовки

Если слой организационного мандата — это то место, где концентрируется подверженность предприятия риску, то компетенция, которой недостаёт экономике, — не ещё один оператор инструментов, а практик, способный написать мандат, который другой человек сможет эксплуатировать, тестировать и отозвать; спроектировать лимиты, которые совокупность агентов не сможет обойти; принимать и записывать решения об авторизации во время выполнения; выполнять и верифицировать отзыв полномочий; и реконструировать по одним лишь доказательствам, на каких полномочиях основывалось действие и где заканчивается доказательство. Программа Foundation Института (специфицирована, уровень рабочего проекта) готовит к случаю одного актора; предлагаемая лаборатория Applied Case Lab и ME-001 расширяют его до совокупностей. Обе остаются невалидированными, пока не проведена когорта; детерминированная демонстрация, сопровождающая ME-001, устанавливает лишь то, что заданный набор правил может быть обеспечен, — она ничего не устанавливает в отношении какого-либо реального продукта, предприятия или правовой позиции.

7. Заявление о неопределённости

Настоящий анализ опирается на публикации поставщиков, документацию, элементы дорожных карт, проекты IETF, а также отраслевые публикации и исследовательские заметки по состоянию на 12 октября 2026 года. Продукты в закрытом предварительном тестировании могут содержать средства контроля, ещё не документированные. Статус проектов документов, даты дорожных карт и принятие стандартов часто меняются; читателям следует проверять текущее состояние по первоисточникам. Вторичные источники ([3], [7], [10], [12]) обобщают первичные материалы, к которым мы не имели полного доступа; там, где их утверждения не подтверждены первичным источником, они приводятся как таковые.

Источники

[1] Microsoft, “Introducing the new Copilot with Home, Code and Autopilot”, Official Microsoft Blog, 25 сентября 2026 г., J. Spataro. https://blogs.microsoft.com/blog/2026/09/25/introducing-the-new-copilot-with-home-code-and-autopilot/ (дата обращения: 12 октября 2026 г., через вторичные обзоры; первичная страница на момент обращения не загружалась). [2] Microsoft Source EMEA, “New Microsoft Copilot brings Home, Code and Autopilot together”, 25 сентября 2026 г., K. Thurnher. https://news.microsoft.com/source/emea/2026/09/new-microsoft-copilot-brings-home-code-and-autopilot-together/ (дата обращения: 12 октября 2026 г.). [3] DEV Community, “The new Microsoft Copilot: Home, Code and Autopilot explained”, 28 сентября 2026 г. (вторичный источник; ссылается на страницы Microsoft Learn о тарификации, обновлённые 25 сентября 2026 г.). https://dev.to/getpack/the-new-microsoft-copilot-home-code-and-autopilot-explained-5f7i (дата обращения: 12 октября 2026 г.). [4] Microsoft Learn, “Usage-based billing overview — Copilot Credits” и “Manage Copilot Credits”, обновлены 25 сентября 2026 г. (цит. по [3]). https://learn.microsoft.com/en-us/microsoft-365/copilot/usage-based-billing-overview-copilot-credits [5] Microsoft Learn, “Microsoft Entra Agent IDs for Copilot Studio agents”, последнее обновление 15 сентября 2026 г. https://learn.microsoft.com/microsoft-copilot-studio/admin-use-entra-agent-identities (дата обращения: 12 октября 2026 г.). [6] Элемент дорожной карты Microsoft 365 RM570434, “Microsoft Copilot Studio: Enabling makers to require human approval for tool calls”, опубликован 1 сентября 2026 г., целевой срок общей доступности — сентябрь 2026 г. https://mc.merill.net/message/RM570434 (дата обращения: 12 октября 2026 г.). [7] Redmond Magazine, “Microsoft Agent 365 adds centralized controls”, 16 сентября 2026 г. (вторичный источник; обобщает публикацию Microsoft Mechanics). https://redmondmag.com/blogs/redmond-dispatch/2026/09/microsoft-agent-365-adds-centralized-controls.aspx (дата обращения: 12 октября 2026 г.). [8] IETF, draft-ietf-wimse-arch-07, “Workload Identity in Multi System Environments (WIMSE) Architecture”, март 2026 г. https://datatracker.ietf.org/doc/html/draft-ietf-wimse-arch-07 [9] Y. Ni, C. P. Liu, M. Richardson, draft-ni-wimse-ai-agent-identity-03, “WIMSE Applicability for AI Agents”, индивидуальная заявка, 1 октября 2026 г. (истекает 4 апреля 2027 г.). https://www.ietf.org/archive/id/draft-ni-wimse-ai-agent-identity-03.html (дата обращения: 12 октября 2026 г.). [10] Cloud Security Alliance, “IETF’s Race to Standardize AI Agent Identity”, исследовательская заметка, 2 сентября 2026 г. (вторичный источник; охватывает draft-klrc-aiagent-auth-00, DAWN, draft-sharif-agent-identity-framework-01, draft-ihsanullah-dnsid-01, авторизацию MCP). https://labs.cloudsecurityalliance.org/research/csa-research-note-ietf-agent-identity-standards-20260902-csa/ (дата обращения: 12 октября 2026 г.). [11] ISO/IEC 42001:2023, “Information technology — Artificial intelligence — Management system”, декабрь 2023 г.; обзор в блоге ANAB/ANSI, 23 августа 2024 г. (изменён 21 мая 2025 г.). https://blog.ansi.org/anab/iso-iec-42001-ai-management-systems/ (дата обращения: 12 октября 2026 г.). [12] Cloud Security Alliance, “OWASP’s 2026 LLM Top 10 and New Agent Control Standard”, исследовательская заметка, 4 сентября 2026 г. (вторичный источник; охватывает OWASP Top 10 for LLM Applications 2026 от 3 августа 2026 г., OWASP Top 10 for Agentic Applications от декабря 2025 г. и Agent Control Standard v0.1). https://labs.cloudsecurityalliance.org/research/csa-research-note-owasp-genai-top10-2026-agent-control-stand/ (дата обращения: 12 октября 2026 г.). [13] IETF RFC 8693, “OAuth 2.0 Token Exchange”, январь 2020 г.; RFC 9728, “OAuth 2.0 Protected Resource Metadata”, апрель 2025 г. — базовые стандарты, на которые ссылается [10].

Запросы о программах

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

Запросы о программах

research@arenomics.institute

Mandate Engineering — Foundation имеет статус «В разработке — набор не открыт»; Applied Case Lab — предлагаемая программа. Запрос не создаёт обязательств ни для одной из сторон.