Self-hosted gateway: Bedrock guardrails and assume_role, plus telemetry and Desktop policy options

What

Claude Code includes a gateway that organisations can run to route requests to model providers. An upstream is one of the providers the gateway forwards to. The gateway config gained several options.

• Bedrock upstreams accept an optional guardrail with id and version. When set, every request to that upstream carries the X-Amzn-Bedrock-GuardrailIdentifier and X-Amzn-Bedrock-GuardrailVersion headers.
• The guardrail must be set on all Bedrock upstreams or none. Config validation refuses a partial setup, because failover could otherwise send requests to a Bedrock upstream without the guardrail.
• On /v1/messages, clients can no longer supply their own amazon-bedrock-* fields; such requests are rejected with a 400 error.
• Bedrock upstreams accept assume_role with role_arn, external_id and session_name (email or sub). The gateway then calls sts:AssumeRole using access keys or the ambient AWS credential chain, and the Bedrock client uses the resulting shared credentials. An STS temporary-credentials provider was added for this.
• assume_role cannot be combined with aws_bearer_token: the error says it needs SigV4 source credentials, which a bearer token cannot provide.
• telemetry gains resource_attributes.
• managed.policies gains serve_to_desktop. When a request's user-agent identifies Claude Desktop, a policy is withheld unless it sets serve_to_desktop.

Why

Admins who route Claude Code through the gateway can enforce Bedrock Guardrails centrally without clients being able to override or strip them, use cross-account AWS roles for Bedrock, and choose which policies reach Claude Desktop sessions.