Claude Code 2.1.281: Bedrock-апстримы получили кросс-аккаунтный IAM и принудительный Guardrail

Claude Code 2.1.281 вышел 23 сентября с длинным списком исправлений. Среди них — три новых поля в конфигурации Claude apps gateway, которые меняют модель аутентификации и применения политик для Bedrock-апстримов в мультиаккаунтных AWS-развёртываниях.

Поля: assume_role на Bedrock-апстриме, guardrail: {id, version} на Bedrock-апстриме и telemetry.resource_attributes на самом gateway. Ни одно из них не попало в заголовки release notes. Все они влияют на поведение в production.

Модель доверия Bedrock до 2.1.281

Claude apps gateway аутентифицируется в Bedrock с помощью долгосрочных IAM-учётных данных — как правило, пары ключей доступа или роли IAM, которую уже принял исполнительный контейнер gateway. В однаккаунтном деплое это работает нормально. В мультиаккаунтной или организационной схеме возникает проблема: gateway либо хранит учётные данные для каждого аккаунта, где запущен Bedrock-эндпоинт, либо каждая команда деплоит собственный gateway.

assume_role решает эту проблему. Когда поле задано на апстриме, gateway во время запроса вызывает STS AssumeRole и обменивает собственные учётные данные на краткосрочный сессионный токен, ограниченный ролью в целевом аккаунте. Именно этот токен используется для вызова Bedrock.

Что меняет assume_role в мультиаккаунтной схеме

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

С assume_role gateway хранит единственную идентичность — собственную исполнительную роль — и делегирует доступ к каждому аккаунту через STS. Поверхность учётных данных сокращается до одного набора. Управление доступом к каждому аккаунту переходит в политики доверия IAM на целевых ролях — туда, где ему и место.

Формат конфигурации в блоке апстрима: assume_role: { role_arn: "...", external_id: "..." } (параметр external_id необязателен, но рекомендуется в кросс-аккаунтных сценариях). При session_per_developer: true gateway создаёт отдельный STS-токен для каждого разработчика, а не использует общий пул. Это важно для аудита: события CloudTrail на стороне Bedrock теперь будут содержать контекст сессии конкретного разработчика, а не единую идентичность gateway.

Принятие кросс-аккаунтной роли следует стандартным правилам AWS: исполнительная роль gateway нуждается в разрешении sts:AssumeRole на ARN целевой роли; целевая роль должна содержать политику доверия, допускающую принципала исполнительной роли gateway. Ничего нестандартного, но всё это нужно настроить до того, как апстрим заработает.

Что меняет guardrail для operator'ов

Второе поле, guardrail: {id, version}, привязывает Amazon Bedrock guardrail к каждому запросу, отправляемому через данный апстрим. После настройки каждый вызов проходит через указанный guardrail перед тем, как достичь модели.

В release notes есть ограничение, заслуживающее внимания: «задайте либо на всех Bedrock-апстримах, либо ни на одном». Причина — последовательность применения. Если одни апстримы имеют guardrail, а другие нет, запросы, уходящие на незащищённые апстримы, обходят политику. Для организаций, рассматривающих Bedrock guardrails как compliance-контроль, а не лучший способ фильтрации, непоследовательное применение сводит защиту на нет.

До этого поля принудительное применение guardrail происходило на уровне приложения или через AWS-конфигурацию вне gateway. Теперь gateway становится точкой применения политики, а Bedrock-аккаунт — исполнительной средой ниже по цепочке. Граница доверия смещается.

id и version guardrail фиксируются на этапе конфигурации, не per-request. Если разным группам пользователей или типам запросов нужны разные guardrails, потребуется несколько отдельных записей апстримов с разными конфигурациями guardrail.

telemetry.resource_attributes: фиксированные метки для телеметрии gateway

Третье поле, telemetry.resource_attributes, добавляет фиксированные пары ключ-значение ко всей телеметрии Claude apps gateway — включая телеметрию Claude Desktop и /login-сессий, маршрутизируемых через него.

Это преимущественно observability-изменение. Если телеметрия gateway агрегируется в Datadog, Grafana или CloudWatch, resource_attributes позволяет стабильно прикреплять метки окружения (env: production, region: us-east-1, team: platform) без изменений в downstream telemetry pipeline. Метки появятся на всех span'ах и метриках.

Практический сценарий: мультисредовые деплои, где один telemetry pipeline получает трафик от нескольких экземпляров gateway. Без resource attributes различить production- и staging-трафик можно только по именам хостов или через инъекцию заголовков. С ними достаточно установить env: staging в конфигурации staging-gateway — метка появится везде.

Настройка attribution:false

Четвёртое изменение с широким операционным влиянием: "attribution": false в settings.json скрывает атрибуцию коммитов и PR во всём workspace. В release notes есть замечание о совместимости: старые версии Claude Code пропускают файл settings, содержащий этот ключ, поэтому при использовании файла в разных версиях рекомендуется объектная форма ({ "attribution": false }), а не просто булев литерал.

Для команд, использующих Claude Code в CI-пайплайнах или общих workspace, где атрибуция коммитов несёт compliance- или policy-значение, это первый контроль атрибуции на уровне settings.

Что проверить в существующих конфигурациях Bedrock gateway

При использовании Claude apps gateway с Bedrock-апстримами изменения 2.1.281 создают три точки аудита:

Однааккаунтные деплои со статическими учётными данными: изменений не требуется. assume_role — аддитивное поле.

Мультиаккаунтные деплои: оцените, снизит ли замена per-аккаунтных статических учётных данных на assume_role + IAM trust policies поверхность управления секретами. При наличии более двух Bedrock-аккаунтов в списке апстримов это почти наверняка выгоднее.

Организации, использующие Bedrock guardrails как compliance-контроль: поле guardrail делает принудительное применение на уровне gateway явным. Если сейчас применение опирается на вызовы на уровне приложения или AWS-конфигурацию вне gateway, рассмотрите перенос в конфигурацию апстрима. Ограничение «все или ни одного» означает, что нужно проверить каждую запись апстрима, а не только те, которые вы считаете обрабатывающими чувствительный трафик.

Телеметрия gateway без меток окружения: если в telemetry pipeline есть логика различения окружений по именам хостов или regex по эндпоинтам, telemetry.resource_attributes предлагает более чистую альтернативу — изменение в конфигурации, а не в pipeline.

Claude Code 2.1.281 также содержит значительный набор исправлений истории сессий и prompt-cache — устраняет случаи скрытого повреждения сессии при resume. Стоит прочитать при высокой нагрузке или длительных сессиях через gateway, но изменений конфигурации не требует.