# Что использовать MCP-агентам в продакшене, OAuth 2.1 или облачные учетные данные?

> MCP-агентам в продакшене нужны OAuth на границе MCP и краткосрочные облачные учетные данные дальше. Разбираем области доступа, отзыв, ротацию и аудит.

MCP-агентам в продакшене обычно нужен OAuth 2.1 для доступа к защищенному удаленному MCP-серверу, а также идентичность рабочей нагрузки, чтобы получать краткосрочные учетные данные для облачных API. Эти механизмы защищают разные участки пути. Вопрос о том, какой из них лучше, скрывает границу, которую на самом деле нужно защитить.

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

Для удаленного MCP по HTTP разумная исходная схема включает два обмена. Агент проходит аутентификацию на сервере авторизации MCP и получает access-токен, целевой аудиторией которого указан этот MCP-сервер. Затем рабочая нагрузка подтверждает свою идентичность на платформе и получает данные доступа именно к тому облачному аккаунту, роли, сервисному аккаунту или managed identity, которые нужны нижестоящему инструменту. Если агент и MCP-сервер работают в одном доверенном процессе через stdio, первый обмен может исчезнуть, но требование к облачной идентичности остается.

## Не считайте эти два вида учетных данных взаимозаменяемыми

OAuth 2.1 и краткосрочные облачные учетные данные отвечают на разные вопросы. OAuth определяет, может ли этот клиент обращаться к защищенному ресурсу от своего имени или от имени пользователя. Облачный IAM определяет, может ли эта рабочая нагрузка выполнить действие провайдера над конкретным облачным ресурсом. Bearer-токен для MCP-сервера не должен одновременно открывать доступ к объектному хранилищу, базе данных или API развертывания.

Текущая спецификация Model Context Protocol Authorization считает защищенный HTTP-сервер MCP ресурсным сервером OAuth. При запросе авторизации и токена клиент обязан передать параметр `resource`, который описан в RFC 8707. Сервер обязан проверить, что токен выпущен для него как для целевой аудитории, и вернуть HTTP 401 для просроченного или недействительного токена. Та же спецификация запрещает принимать или пересылать токены, предназначенные другому сервису.

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

Корректный путь запроса выглядит так:

1. Среда выполнения подтверждает свою идентичность рабочей нагрузки серверу авторизации или службе токенов безопасности.
2. Она получает access-токен MCP, ограниченный нужным MCP-сервером и необходимыми областями доступа.
3. MCP-сервер разрешает или запрещает запрошенный инструмент до его запуска.
4. Инструмент получает отдельные краткосрочные облачные учетные данные для нижестоящего ресурса.
5. MCP-сервер записывает решение и связывает его с записью запроса у облачного провайдера.

Не позволяйте четвертому шагу повторно использовать токен со второго шага. Даже если нижестоящий API принимает OAuth, MCP-серверу все равно нужен новый обмен на токен с другой аудиторией. Одинаковый формат токенов не делает их одними и теми же учетными данными.

## Какую идентичность дать автономному агенту

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

Если нагрузка работает внутри облака, используйте встроенную идентичность этого облака: роль AWS IAM для вычислительного ресурса, сервисный аккаунт Google Cloud через Workload Identity Federation или Azure managed identity. В Kubernetes применяйте интеграцию провайдера, которая связывает сервисный аккаунт с облачной идентичностью. Для другого облака, CI-системы или локального сервера настройте федерацию: передавайте подписанное OIDC-утверждение среды выполнения или аналогичные штатные данные в службу токенов безопасности целевого провайдера.

AWS прямо рекомендует временные учетные данные от ролей IAM и федеративных субъектов вместо постоянных ключей доступа пользователей IAM. Google Cloud называет Workload Identity Federation предпочтительным вариантом для внешних нагрузок и предупреждает, что при работе с ключами сервисного аккаунта оператор сам отвечает за защиту закрытого ключа. Microsoft указывает, что managed identities позволяют ресурсу Azure получать токены Microsoft Entra без учетных данных, которыми владелец управляет вручную. Названия разные, но рабочая схема одна: сначала платформа подтверждает среду выполнения, затем код при необходимости получает ограниченные учетные данные.

Конфиденциальный клиент OAuth с `client_credentials` может представлять агента на границе MCP. Это не повод размещать постоянный общий секрет клиента в каждой реплике. Лучше выбрать `private_key_jwt`, взаимный TLS или поддерживаемую сервером авторизации федерацию, а операцию с закрытым ключом выполнять через управляемый ключ или идентичность среды. Если сервер авторизации поддерживает только секрет клиента, создайте отдельный секрет для каждой нагрузки и среды, ограничьте круг читателей и считайте его ротацию отдельной обязанностью, которая не совпадает с обновлением access-токена.

Не используйте refresh-токен основателя, SRE или владельца сервиса для демона. Refresh-токены представляют уже выданное разрешение и часто живут достаточно долго, чтобы пережить много циклов access-токена. Кроме того, они связывают жизненный цикл агента с человеческим аккаунтом, изменением согласий, увольнением и интерактивной повторной авторизацией. Рабочему заданию нужна собственная идентичность нагрузки и документированная процедура ее удаления.

## Область доступа не заменяет облачную политику

Области OAuth должны описывать возможности MCP, которые вправе запрашивать клиент, а облачная политика должна ограничивать действия, ресурсы и условия у провайдера. Области `deploy` недостаточно, если за ней незаметно скрывается административный доступ ко всем аккаунтам. Роль в облаке с названием `MCPAgent` ничем не лучше, если ее получает каждый вызов инструмента.

Спецификация авторизации MCP рекомендует выбирать области из ответа `WWW-Authenticate` сервера и поддерживает повышение уровня доступа после ответа `insufficient_scope`. Для интерактивных клиентов это полезно. Автономный клиент не должен автоматически запрашивать более широкие области, пока операция не сработает. У него должен быть заранее объявленный потолок. При запросе дополнительных прав агент закрывает доступ и отправляет операцию на согласование либо требует изменить конфигурацию.

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

Практическая запись политики может быть достаточно короткой для обычного ревью:

```yaml
agent: release-notes-prod
mcp_resource: https://mcp.internal.example/releases
mcp_scopes:
  - releases:read
  - releases:draft
cloud_identity: releases-writer-prod
allowed_actions:
  - object.get
  - object.create
resource_prefix: releases-prod/drafts/
max_credential_ttl_seconds: 900
auto_scope_upgrade: false
human_approval:
  - object.delete
  - release.publish
```

Этот фрагмент создает два полезных варианта отказа. Инъекция в промпт с вызовом `release.publish` останавливается до облачного запроса, потому что политика инструмента требует согласования. Взломанный агент, который обращается к другому префиксу хранилища, доходит до провайдера с учетными данными, чья ресурсная политика отклоняет запрос. Если провайдер не умеет выразить такое ограничение, поместите перед ним брокер, который выпускает более узкие данные доступа, либо переделайте инструмент. Инструкция внутри промпта модели не считается средством авторизации.

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

## Короткий срок действия помогает только при безопасном выпуске

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

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

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

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

У кэша токенов должен быть владелец и жесткий верхний предел. Разделяйте кэш по аудитории, области, облачной роли и арендатору, а не складывайте все под расплывчатой меткой `cloud_token`. Обновляйте токен незадолго до истечения с небольшим запасом, но не запускайте фоновый цикл, который бесконечно продлевает неиспользуемые данные доступа. Изолируйте кэши арендаторов и агентов. Если из-за коллизии кэша система вернула действительный токен от чужого аккаунта, это нарушение авторизации, даже когда все криптографические проверки прошли успешно.

## Ротация и отзыв устраняют разные сбои

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

OAuth 2.1 требует, чтобы конфиденциальные клиенты проходили аутентификацию на конечной точке токенов, и связывает refresh-токены с клиентом. Для публичных клиентов спецификация требует refresh-токены с привязкой к отправителю или одноразовые токены, чтобы система замечала повторное использование. Это защищает обновление, но не гарантирует мгновенное отключение каждого уже выпущенного access-токена. Самодостаточный токен может приниматься до окончания срока, если ресурсный сервер не проверяет отзыв и система авторизации не применяет другой блокирующий механизм.

У временных облачных учетных данных есть та же операционная особенность. AWS указывает, что временные учетные данные действуют до истечения, хотя разрешения проверяются при каждом запросе. Изменение политики роли или явный запрет могут остановить следующие запросы, не дожидаясь конца сессии. В других системах кэшированные токены или групповые claims задерживают изменение прав. Microsoft описывает, что из-за кэширования токенов managed identity изменения членства в группах или ролях могут применяться несколько часов. Если время реакции жестко ограничено, нужны прямые назначения и проверенный механизм запрета.

До запуска подготовьте последовательность отзыва:

1. Отключите идентичность конкретного агента или доверие федерации.
2. Запретите затронутое действие или ресурс на уровне облачной политики.
3. Отзовите разрешение OAuth, семейство refresh-токенов или учетные данные клиента.
4. Остановите рабочую нагрузку и очистите внешний кэш токенов.
5. Ротируйте исходный секрет, только если он существует и мог утечь.

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

Проверьте эту последовательность на практике. Выпустите учетные данные в тестовом аккаунте, начните безвредные повторяющиеся чтения, отключите идентичность и измерьте момент прекращения вызовов. Запишите, какой механизм перекрыл доступ и какие журналы это подтверждают. Максимально допустимое окно риска должно опираться на этот результат, а не на одно заявленное поле `expires_in` токена.

## Обмен токенов должен сохранять границы аудитории

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

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

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

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

Следите за перенаправлениями и повторными попытками. HTTP-библиотека не должна передавать заголовок `Authorization` другому хосту после перенаправления. Агент не должен отвечать на 401 получением более широкого токена без проверки политики. Инструмент, который следует по URL от провайдера, обязан применять список разрешенных адресов и получать учетные данные лишь после определения окончательной доверенной аудитории.

## Проверяйте всю цепочку, а не последний вызов API

Полезный аудит связывает запуск агента, решение об авторизации, вызов инструмента MCP, выпуск токена и облачный запрос, но не записывает сами учетные данные. Журналы провайдера редко объясняют, почему модель выбрала инструмент и какая политика его разрешила. Трассировки агента редко доказывают, какой облачный субъект изменил ресурс.

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

Минимальное событие должно быть достаточно предсказуемым для поискового запроса и сценария разбора инцидента:

```json
{"event":"mcp_tool_authorization","run_id":"run_01J...","tool":"release.create_draft","caller_subject":"agent:release-notes-prod","mcp_audience":"https://mcp.internal.example/releases","scope":"releases:draft","policy_version":"git:8f31c2a","decision":"allow","cloud_principal":"releases-writer-prod","cloud_request_id":"req_7b...","credential_expires_at":"2026-07-27T14:15:00Z","token_fingerprint":"sha256:4ab..."}
```

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

Рекомендации Google Cloud по Workload Identity Federation наглядно показывают, зачем нужны журналы выпуска. Data Access logs для Security Token Service и IAM API записывают обмен токена и impersonation сервисного аккаунта, а последующая активность ресурса может показывать этот сервисный аккаунт. Google рекомендует уникальное сопоставление субъекта и связь с внешним поставщиком идентичности, чтобы расследователь мог восстановить инициатора цепочки. Включите эти журналы явно, не предполагая, что каждое событие доступа к данным записывается автоматически.

AWS CloudTrail записывает обращения к AWS STS и последующие вызовы под принятой ролью. Осмысленное имя сессии роли и `SourceIdentity`, когда оно поддерживается, помогают сохранить исходного инициатора после принятия роли. Azure предоставляет журналы входов managed identity, но общая user-assigned identity все равно может представить несколько ресурсов одним вызывающим. Выбирайте system-assigned identity, когда связь с одним ресурсом важнее повторного использования.

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

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

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

Перед выпуском выполните хотя бы такие проверки:

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

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

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

Не отдавайте авторизацию модели. Модель может предложить инструмент и аргументы. Детерминированный код проверяет схему, определяет арендатора и ресурс, применяет политику, получает учетные данные и выполняет вызов. Человек должен согласовать точную нормализованную операцию с ограниченным сроком, а не добавить расплывчатый флаг `approved=true` в диалог.

В oleg.is я использую Team & AI Audit, чтобы разобрать эти границы вместе с правами агентов и операционными расходами: небольшой команде с AI нужны средства контроля, которые она действительно умеет проверять и обслуживать. Такой разбор можно провести и своими силами. Назначьте одного владельца каждой идентичности, один репозиторий политик каждому набору разрешений и одну процедуру инцидента каждому издателю учетных данных.

Не принимайте архитектурную схему за доказательство. Сохраните ответы 401 и 403, отказ провайдера, измеренное время отзыва и связанный поисковый запрос к журналу в CI или плановом тесте безопасности. Системы учетных данных постепенно отклоняются от замысла, когда провайдер меняет стандартное поведение SDK, роль получает wildcard или прокси начинает повторно использовать заголовки.

## Когда делегирование OAuth остается правильным выбором

Используйте поток authorization code с PKCE, когда агент действует от имени присутствующего пользователя, а нижестоящее действие должно нести согласие или идентичность этого пользователя. Спецификация MCP требует от клиентов MCP применять PKCE и проверять, что сервер авторизации объявляет его поддержку. Такая схема подходит ассистенту, который читает личное рабочее пространство пользователя во время активной сессии.

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

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

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

## Что развернуть для MCP-агентов в продакшене

Разверните многоуровневую цепочку: привязанную к среде идентичность рабочей нагрузки, OAuth-токен с отдельной аудиторией для каждого защищенного MCP-сервера и отдельные краткосрочные облачные учетные данные для каждого набора нижестоящих разрешений. Уберите пользовательские refresh-токены, постоянные облачные ключи и общие для разных сервисов bearer-токены из штатного пути.

Для MCP-сервера по HTTP обеспечьте обнаружение защищенного ресурса, передачу параметра `resource`, проверку издателя и аудитории, короткий срок access-токенов и точное различие ответов 401 и 403. Для локального сервера stdio спецификация MCP предписывает получать учетные данные из среды вместо HTTP-потока авторизации. В продакшене такая среда должна предоставлять конечную точку платформенных учетных данных или внедренную одноразовую ссылку, но не постоянный облачный ключ.

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

OAuth 2.1 дает участку MCP строгий протокол авторизации. Краткосрочные облачные учетные данные дают нагрузке ограниченную идентичность у провайдера. Идентичность рабочей нагрузки убирает секрет, который иначе позволял бы выпускать эти учетные данные бесконечно. В продакшене нужны все три идеи на своих местах. Если один токен пересекает все границы, измените схему до того, как агент получит рабочий инструмент.