Авторизуйте агента в момент фиксации, а не в момент планирования

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

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

План — это предложение, а не выдача полномочий

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

Между этими моментами могут пройти секунды, часы или весь срок длительного процесса. За это время сотрудник может отозвать делегирование, согласование — истечь, бюджет — исчерпаться, целевая запись — сменить версию, а состояние безопасности — ухудшиться. Раннее рассуждение агента может оставаться понятным, но его полномочия уже исчезли.

Июльский препринт 2026 года называет нужное свойство «авторизацией в момент фиксации» (commit-time authorization): основание полномочий, лежащее под производным состоянием агента, должно оставаться свежим, причинно предшествовать действию, быть связано с тем же эффектом и сохранять применимость на момент фиксации. В контролируемых тестах авторы часто наблюдали сохранение видимого завершения задачи после того, как авторизующий путь был аннулирован. Это полезное исследовательское свидетельство, а не сложившийся отраслевой стандарт. Однако архитектурный вывод уже очевиден: исполнительная среда не может выводить текущие полномочия только из исторического плана.

Граница фиксации превращает управление в рабочий механизм

Это не означает, что каждому действию нужен двухфазный коммит в стиле базы данных. Многие SaaS API и бизнес-инструменты не предлагают семантику prepare/commit, атомарный откат или даже осмысленную отмену. Практическое правило уже: нужно найти последнюю контролируемую точку перед тем, как внешний побочный эффект станет устойчивым, и сделать её управляемой границей runtime.

На этой границе runtime должен заново собрать запрос из актуальных фактов, а не воспроизводить устаревшее решение. Архитектура Zero Trust от NIST описывает решения через точки принятия и применения политик, использующие идентичность, ресурс и контекстные факторы. AWS IAM аналогично оценивает контекст запроса: субъект, запрошенное действие, ресурс, среду и данные ресурса; по умолчанию запрос отклоняется, а явный запрет имеет приоритет над разрешением. Это не специфические для агентов модели. Именно такая дисциплина нужна агентным runtime в момент возникновения эффекта.

Проверка должна установить: кто действует; какая организация и какая цепочка делегирования участвуют; какое именно действие предлагается; какой неизменяемый объект или версия объекта его получит; какая политика действует сейчас; и какой актуальный бизнес- или security-контекст меняет решение. Если основанием служит токен доступа, важен и его текущий статус. OAuth 2.0 Token Introspection создан для проверки того, активен ли токен сейчас, включая проверки срока действия, истечения и отзыва.

“Согласование должно разрешать названный эффект в заданных условиях, а не выдавать агенту многоразовый чистый чек.

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

Согласование человека, делегированный мандат, исключение из политики или сервисные учётные данные — это свидетельство полномочий. Runtime должен проверить, что оно всё ещё существует, применимо и связано именно с действием, которое вот-вот произойдёт. Формулировка «платёж поставщику согласован» — слабое свидетельство, если получатель, сумма, валюта, счёт, платёжные реквизиты или версия политики затем могут измениться, не отменяя согласования.

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

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

Сделайте эффект безопасным для повторов и понятным для расследования

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

Для каждого значимого действия runtime должен нести ключ идемпотентности, отпечаток эффекта, классификацию точки невозврата и, где возможно, путь компенсации. Руководства по распределённым транзакциям на основе саг прямо называют устаревшие данные, идемпотентность, наблюдаемость и компенсацию отдельными задачами и рекомендуют семантическую блокировку, когда параллельные оркестрации могут действовать на устаревшем состоянии. Компенсация полезна, но не стирает прошлое. Руководство Microsoft отмечает, что она может не сработать, потребовать вмешательства человека и не восстановить точно прежнее состояние — особенно при необратимых шагах или параллельных изменениях.

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

Трасса — не запись об авторизации

Распределённая трассировка по-прежнему необходима. W3C Trace Context стандартизирует идентификаторы, связывающие работу между сервисами; это важно, когда один агент делегирует работу другим, а фиксация происходит далеко от исходного запроса. Но корреляция отвечает на вопрос «какой путь привёл сюда?». Она не отвечает на вопрос «был ли этот эффект авторизован именно в этот момент?».

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

Что это меняет для автономной организации

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

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

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