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

Дальше токен меняют на временные учётные данные. В AWS для этого заводят поставщика удостоверений с издателем api.cursor.com, ставят аудиторию sts.amazonaws.com, описывают в политике доверия совпадение по субъекту и, если нужно, по идентификатору команды, и вызывают обмен по веб-удостоверению. GCP делает то же через федерацию рабочих нагрузок, Azure - через федеративные учётные данные, Vault - через вход по JWT, а собственный сервис - через любой стандартный проверяющий, потому что ничего нестандартного в токене нет. Ниже такая последовательность целиком:

Цена механизма измерима. Токен живёт пять минут, обновления не предусмотрено: истёк - выпускайте новый, а значит долгие операции надо либо укладывать в это окно, либо строить на временных учётных данных провайдера, которые живут дольше. Частота ограничена: тридцать токенов в минуту на машину со всплеском до десяти, не больше восьми одновременных соединений с сокетом, тело запроса до четырёх килобайт. Коды 429, 503, 500, 502 и 504 стоит повторять с отступом, а 403 повторять бессмысленно - он означает, что этой машине выпуск не разрешён. И отдельная строка расходов - настройка доверия на стороне каждого провайдера, которую делают руками один раз и потом сопровождают.

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

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