Какая идентичность должна пережить процесс агента?

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

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

Одно имя не может выполнять пять функций

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

Существующие стандарты уже подсказывают отказаться от универсального идентификатора. NIST SP 800-207A переносит решения о доступе в cloud-native средах от сетевого расположения к идентичностям приложений и сервисов наряду с идентичностями пользователей. SPIFFE определяет идентичности рабочих нагрузок и SVID — криптографически проверяемые документы, которыми нагрузки подтверждают свою идентичность. OpenTelemetry отдельно определяет имя сервиса и service.instance.id для конкретного экземпляра сервиса. Kubernetes допускает повторное использование имени объекта после удаления, но присваивает UID, различающий исторические экземпляры.

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

Пятичастное связывание действия

AES рекомендует, чтобы каждое значимое действие несло либо позволяло однозначно получить пять идентификаторов. Это архитектурная рекомендация, собранная из разных понятий стандартов; это не формат записи, предписанный NIST, SPIFFE, Kubernetes, OpenTelemetry или W3C PROV.

1. ID организационного субъекта: стабильный идентификатор управляемой роли, например агента оплаты поставщикам. К нему привязываются ответственность, операционная цель и долгосрочные отношения с политиками.
2. Идентичность рабочей нагрузки: криптографически проверяемая идентичность исполняющего ПО. SPIFFE ID и его краткоживущий SVID дают конкретный паттерн этого слоя, но идентифицируют нагрузки, а не юридически или организационно ответственных субъектов.
3. ID экземпляра рантайма: неповторяемый идентификатор данного развёртывания или воплощения процесса. Он должен меняться при пересборке или перезапуске, даже если логическое имя и идентичность нагрузки сохраняются.
4. ID исполнения: идентификатор ограниченного запуска работы — отдельной задачи, попытки выполнения workflow или последовательности действий. Он различает две операции одного работающего экземпляра.
5. ID гранта полномочий: текущий ограниченный грант, разрешивший действие. ID субъекта сам по себе не даёт полномочий: действительность гранта нужно проверять в точке эффекта.

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

Непрерывность — записанная связь, а не совпадающая метка

Замещающий процесс может законно продолжить работу предшественника. Но это не делает два процесса одним и тем же. Новый контейнер, получивший после сбоя имя «агент оплаты поставщикам», является новым экземпляром рантайма. Он должен получить свежие краткоживущие учётные данные, обрести актуальные полномочия и новый ID экземпляра. Совпадающее имя агента, промпт или версия модели не доказывают непрерывности.

Вместо этого рантайм должен явно фиксировать непрерывность: экземпляр B сменяет экземпляр A для указанного субъекта, нагрузки и области работы в указанное время. Связь может включать переданное состояние или лизинг работы, но не должна стирать историческую идентичность A. Kubernetes даёт здесь полезный прецедент: повторно используемого имени объекта недостаточно для различения исторических объектов, поэтому системный UID сохраняет различие. Сам UID не является межкластерной организационной идентичностью. Важен принцип: логическая тождественность и исторический экземпляр — разные факты.

Такая дисциплина предотвращает типичный провал аудита. Если поздний экземпляр перезаписывает идентичность раннего, расследование установит лишь, что действовал «платёжный агент». Оно не сможет определить, было ли действие совершено нагрузкой до обновления, заменившей нагрузкой, скомпрометированным экземпляром или несанкционированным дубликатом. Стабильный ID субъекта сохраняет бизнес-подотчётность; ID экземпляра сохраняет криминалистическую точность.

Версии описывают исполнение, но не заменяют субъекта

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

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

Полномочие должно быть текущим и конкретным

W3C PROV полезен как концептуальное разделение агентов, активностей и отношений ответственности. Он допускает связь одной активности с несколькими агентами, включая людей, ПО и организации, а также описывает действие одного агента от имени другого. Управляемому рантайму стоит применить то же разделение к контрольным решениям: организационный субъект может отвечать за бизнес-действие; нагрузка может его исполнять; человек или сервис политик может выдать полномочие; а исполнение — это ограниченная активность, в которой эти связи сходятся.

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

Формируйте запись идентичности на границе эффекта

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

• Ведите реестр организационных субъектов независимо от развёртываний, провайдеров моделей и издателей учётных данных.
• Выдавайте учётные данные нагрузкам аутентифицированного ПО и ротируйте их по назначению; не используйте учётные данные как долговечную бизнес-идентичность.
• Создавайте ID экземпляров рантайма, которые никогда не используются повторно, и сохраняйте записи непрерывности от предшественника к преемнику.
• Создавайте ID исполнения для ограниченной единицы работы, а версии модели, промпта, кода, инструментов и политик фиксируйте как атрибуты исполнения.
• Требуйте действующий грант с ограниченной областью для значимых эффектов и включайте его ID в долговечное доказательство действия.
• Отдельно показывайте ID субъекта, идентичность нагрузки и ID экземпляра в аудитных и наблюдательных представлениях. service.instance.id может помогать наблюдаемости, но не является учётными данными аутентификации.

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

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