# Идентичность рабочей нагрузки для ИИ-агентов заменяет статические ключи

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

ИИ-агент, который может открыть запрос на слияние, запустить развертывание, обратиться к продакшену и вызвать сервис в другом облаке, это рабочая нагрузка с необычно широкими возможностями. Выдать ему ключ JSON или секрет клиента легко. Но тогда полномочия отделяются от места, процесса и момента, где они должны действовать. После копирования в переменную окружения, настройку CI или конфигурацию инструмента агента учетные данные могут пережить запуск и оказаться где угодно.

Идентичность рабочей нагрузки для ИИ-агентов заменяет такой переносимый секрет утверждением о запущенной нагрузке. Облачная служба токенов безопасности проверяет утверждение и выдает временные учетные данные для одной заданной роли. Добиться рабочего обмена токенами не так трудно. Гораздо труднее выбрать достаточно точную идентичность, которая выдержит скомпрометированную инструкцию, повторно используемый рабочий процесс и перенос между облаками.

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

## Идентичность агента должна быть привязана к выполнению

Полезная идентичность агента описывает запущенную рабочую нагрузку, а не имя бота на экране продукта. Имена вроде `research-agent` или `deploy-agent` сообщают оператору, для чего предназначена программа. Они не доказывают, какой репозиторий, среда, пространство имен кластера, сервисная учетная запись, рабочий процесс или версия сборки ее запустили. Если политика доверия принимает одно лишь имя, злоумышленнику достаточно запустить другой процесс с той же меткой.

Начните с идентичности выполнения, которую платформа может аттестовать. В Kubernetes это может быть издатель кластера вместе с пространством имен и сервисной учетной записью в поле субъекта токена. В размещенной системе CI это может быть организация, репозиторий, ветка или защищенная среда и идентичность рабочего процесса, которую сообщает издатель. На облачной виртуальной машине используйте идентичность экземпляра или управляемой рабочей нагрузки, доступную через провайдера, а не учетные данные, скопированные в образ.

Назначение агента оставьте атрибутом авторизации после установления идентичности выполнения. Одна реализация агента может работать как `planner` в среде разработки и как `release-controller` в продакшене, но эти запуски не должны получать одну облачную роль. В то же время несколько реплик одного одобренного развертывания могут разделять идентичность рабочей нагрузки, если у них одинаковые путь выполнения, граница доверия и разрешения. Детализация идентичности должна соответствовать наименьшей единице, которую можно отозвать или изолировать без остановки посторонней работы.

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

## Федерация проверяет утверждения и выдает локальные полномочия

Федерация позволяет целевому облаку доверять учетным данным, выданным средой выполнения агента, а затем преобразовать их в локальные полномочия. Она не делает идентичности AWS, Microsoft Entra ID, Google Cloud, Kubernetes и SPIFFE взаимозаменяемыми. Каждый получатель применяет собственную конфигурацию доверия и выдает токен или ролевую сессию, понятные его сервисам.

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

RFC 8693 описывает обмен токенами OAuth с обязательным `subject_token` и необязательным `actor_token`. Поле `audience` указывает целевой сервис, где должен работать запрошенный токен. Спецификация также предупреждает по существу: обмен не аннулирует входной токен и не создает постоянной связи между входными и выходными учетными данными. Для агентов эта оговорка особенно важна: отзыв источника после предупреждения может не остановить уже выпущенную сессию получателя до окончания ее собственного срока.

Облачные реализации различаются. AWS STS принимает OIDC JWT через `AssumeRoleWithWebIdentity` и возвращает временные учетные данные роли. Google Cloud Security Token Service обменивает внешние учетные данные на федеративный токен, который может напрямую обратиться к ресурсу или олицетворить сервисную учетную запись. Федерация идентичности рабочих нагрузок Microsoft Entra сопоставляет внешний токен с федеративными учетными данными идентичности и возвращает токен доступа. Спроектируйте один концептуальный поток, но напишите и проверьте три политики получателя. За OIDC не скрывается универсальная политика.

## Для поля субъекта нужна модель владения

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

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

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

Для доверия используйте неизменяемые идентификаторы, а понятные имена оставьте журналам. Если репозиторий можно переименовать или передать, привяжите его стабильный ID, а текущее имя скопируйте в атрибут сессии для операторов. Если сервисную учетную запись Kubernetes может заново создать команда с правом записи в пространство имен, решите, разрешено ли этой команде получать облачную роль. Сопоставление пространства имен и сервисной учетной записи не исправит слабое администрирование Kubernetes. Цепочка идентичности не сильнее органа, который может создать аттестованную рабочую нагрузку.

Не используйте глобальный субъект вроде `agent-prod` для нескольких кластеров. Даже если издатели сейчас различаются, кто-нибудь со временем упростит условие или повторно использует провайдера. Формат вроде `system:serviceaccount:payments:reconciler` полезен только тогда, когда получатель также фиксирует точного издателя кластера и нужную аудиторию. Идентичность задается набором проверенных утверждений, а не одной красивой строкой.

## Аудитория ограничивает токен, а не украшает его

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

Kubernetes может проецировать токен сервисной учетной записи для выбранной аудитории и срока. Агенту, которому нужен AWS, следует получить токен для AWS STS, а не стандартный токен для вызова Kubernetes API. Минимальный фрагмент пода делает эту границу явной:

```yaml
apiVersion: v1
kind: Pod
metadata:
  name: release-agent
spec:
  serviceAccountName: release-agent
  automountServiceAccountToken: false
  containers:
    - name: agent
      image: registry.example/release-agent:42
      volumeMounts:
        - name: aws-identity
          mountPath: /var/run/identity
          readOnly: true
  volumes:
    - name: aws-identity
      projected:
        sources:
          - serviceAccountToken:
              path: token
              audience: sts.amazonaws.com
              expirationSeconds: 900
```

Такая конфигурация не дает поду автоматически получить широкий стандартный токен сервисной учетной записи и выделяет отдельный файл токена для обмена AWS. Она не мешает коду в том же контейнере прочитать файл и не превращает контейнеры в границу безопасности. В документации AWS по EKS сказано, что контейнеры на одном узле по-прежнему используют общее ядро, а неограниченный доступ к метаданным экземпляра может открыть учетные данные узла. Федерация убирает хранимый секрет; изоляцией во время выполнения нужно заниматься отдельно.

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

## Каждой облачной роли нужна узкая политика доверия

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

В AWS привяжите точного провайдера OIDC, аудиторию, пространство имен и сервисную учетную запись. Ниже показана форма политики доверия. Значения учетной записи, региона, кластера и нагрузки нужно заменить:

```json
{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": {
      "Federated": "arn:aws:iam::111122223333:oidc-provider/oidc.eks.us-east-1.amazonaws.com/id/CLUSTER_ID"
    },
    "Action": "sts:AssumeRoleWithWebIdentity",
    "Condition": {
      "StringEquals": {
        "oidc.eks.us-east-1.amazonaws.com/id/CLUSTER_ID:aud": "sts.amazonaws.com",
        "oidc.eks.us-east-1.amazonaws.com/id/CLUSTER_ID:sub": "system:serviceaccount:release:release-agent"
      }
    }
  }]
}
```

Главное свойство здесь, точное совпадение. Если заменить `StringEquals` шаблоном для всех сервисных учетных записей в `release`, управление облачным доступом перейдет к каждому, кто может создавать или менять сервисные учетные записи в этом пространстве имен. Иногда именно так и задумано владение. Обычно это незамеченный путь к повышению привилегий.

В Google Cloud сопоставьте внешний субъект с `google.subject`, добавьте условия по атрибутам доверенного клиента и рабочей нагрузки, затем выдайте прямой доступ к ресурсу либо право олицетворять сервисную учетную запись. Сейчас документация Google рекомендует прямой доступ там, где его поддерживает API. Олицетворение остается полезным для совместимости, но отдельная сервисная учетная запись для каждого приложения не дает разным агентам сойтись на одной идентичности. Не выдавайте разрешения всему пулу идентичностей рабочих нагрузок лишь потому, что при создании пул казался границей.

В Microsoft Entra ID федеративные учетные данные идентичности сопоставляют издателя, субъект и аудиторию. В документации указана стандартная аудитория `api://AzureADTokenExchange`, а шаблонные символы в свойствах этих учетных данных не поддерживаются. Такая точность полезна, но локальное приложение или управляемая идентичность все равно могут иметь избыточные разрешения для каталога или ресурсов. Добейтесь точного совпадения, а затем проверьте, что может запросить совпавшая идентичность.

## Делегирование агенту и идентичность нагрузки говорят о разном

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

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

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

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

Многие агентные фреймворки останавливаются на полпути именно здесь. Их внутренние ID агентов помогают направлять сообщения и бюджеты. Облачная IAM не знает, пришел ли такой ID от аттестованного планировщика или из строки запроса инструмента. Свяжите идентичность фреймворка с рабочей нагрузкой платформы в брокере и отклоняйте любое расхождение до обмена.

## Временные учетные данные ограничивают ущерб, но не злоупотребление

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

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

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

Bearer-токен можно повторно применить до истечения срока, если система не добавляет подтверждение владения или одноразовые правила. Руководство SPIFFE по основным понятиям рекомендует по возможности X.509-SVID, потому что JWT после кражи можно воспроизвести. Идентичность рабочей нагрузки X.509 с взаимной TLS лучше подходит для вызовов между подконтрольными сервисами, а облачные точки STS обычно требуют подписанное утверждение. Используйте вид учетных данных, который поддерживает получатель, сокращайте места появления bearer-токенов и изолируйте компонент обмена от модели и недоверенных инструментов.

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

## Журнал аудита должен сохранять исходного агента

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

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

Проверьте, что именно записывает каждое облако. AWS CloudTrail умеет фиксировать действия принятой роли, но полезность принципала зависит от сведений о ролевой сессии, которые вы передаете и разрешаете. Google Cloud отмечает, что `google.subject` появляется в Cloud Logging для федеративных принципалов, поэтому туда стоит сопоставлять уникальное неизменяемое значение. Журналы входа Microsoft Entra и журналы целевого ресурса охватывают разные части пути; убедитесь, что корреляционное поле доходит до действия над ресурсом, а не заканчивается на выпуске токена.

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

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

## Широкая федерация сначала ломается незаметно

Самые опасные сбои федерации выглядят как успешные развертывания. Представим компанию, которая создает одного провайдера OIDC для издателя CI, сопоставляет имя репозитория с облачным субъектом и разрешает любой ветке принимать роль `deployment-agent`. Агент работает, статический ключ исчезает, задача безопасности закрывается.

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

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

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

Третий сбой, аварийные учетные данные в образе на случай поломки обмена. Они остаются, потому что никто не хочет проверять их удаление. Во время сбоя SDK первым находит этот секрет, а после восстановления агент продолжает им пользоваться. Обнаруживайте это проверкой времени выполнения, которая завершает работу при наличии переменных окружения со статическими учетными данными или известных файлов ключей. Надежность должна опираться на резервирование инфраструктуры идентичности и ограниченные очереди, а не на постоянный обход.

## При миграции секреты нужно удалить, а не переименовать

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

1. Соберите для каждого агента источник учетных данных, целевые API, фактические разрешения, владельца и среду выполнения. Используйте облачные журналы доступа и хранилища секретов, затем подтвердите результат контролируемым запуском, потому что конфигурационные файлы редко дают полную картину.
2. Выберите одного агента с низким риском и понятной идентичностью выполнения. Создайте целевой принципал только с его наблюдаемыми и одобренными действиями, затем настройте проверки издателя, субъекта и аудитории.
3. Запустите федерацию в непродуктивной среде и проверьте отрицательные наборы утверждений. До работы с продакшеном проверьте срок действия, реакцию на расхождение часов, корреляцию журналов и сообщения об отказах.
4. Разверните федеративный путь, отключив статические учетные данные для этого процесса. Проследите за успешными обменами и отказами ресурсов, затем удалите учетные данные из хранилищ секретов, настроек CI, образов и аварийных инструкций. Отзовите их у провайдера.
5. Добавьте проверки политик в процесс доставки, чтобы последующие правки не могли незаметно расширить условия субъекта или аудитории. Назначьте владельцев ключей издателя, сопоставлений доверия, целевых ролей и отзыва при инциденте.

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

SPIFFE и SPIRE стоит рассмотреть, если вы контролируете разнородные среды выполнения и вам нужен общий слой идентичности рабочих нагрузок. SPIFFE назначает идентичности URI внутри доменов доверия, а федерация распространяет открытые пакеты, нужные для проверки идентичностей из другого домена. Спецификация требует, чтобы проверяющая сторона использовала пакет домена доверия, названного в SPIFFE ID. Так корни остаются разделенными; обмен пакетами не объединяет два домена. Сопоставления облачных ролей по-прежнему требуют узкой политики на границе.

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

В oleg.is я включаю такую работу с идентичностью в операционную модель инженерной команды, а не оставляю ее уборкой IAM после выхода агентов в продакшен. Владелец инструментов и развертывания агента должен также отвечать за набор доверия, целевые роли и проверку отзыва.

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