Claude API 驗證：API key、Bedrock、Vertex、Foundry

Claude API 驗證路徑

Claude API 驗證歸結為一項決定：用戶端將哪項認證憑證放入網路請求。Anthropic 列出直接使用 Claude API，以及 5 個雲端平台：Amazon Bedrock、AWS 上的 Claude Platform、Google Cloud 上的 Claude Models（Google 管理）、Google Cloud 上的 Claude Models（Anthropic 管理），以及 Microsoft Foundry。直接使用 Anthropic API 時，可在 Authorization: Bearer 標頭中傳送 API key 或短期 token，也仍接受舊版 x-api-key 標頭中的 API key。Amazon Bedrock 支援 AWS request signing 與 Bedrock API key；在此架構中不會使用 Anthropic key。Google Cloud 會傳送短期 Google access token。Microsoft Foundry 接受 Azure 核發的 key 或 Microsoft Entra token。以下 4 個章節說明這些認證設定，並將由 Anthropic 管理的 AWS 與 Google Cloud 方案，分別放在對應的雲端方案旁說明。

本指南適用於將 SDK（software development kit）接入 Linux 伺服器上執行的服務。如果你要設定的是 Claude Code command line tool，變數與流程都不同，請參閱 將 Claude Code 指向 Bedrock 或 Vertex。如果服務尚未建立，請先依照 在 VPS 上建立第一個 Claude API 應用程式 完成建立，再回到這裡設定認證憑證。

以下內容已於 August 2026 依 Anthropic 的平台文件完成檢查，並於 16 October 2026 依各提供者的文件重新檢查；Bedrock 的 model access 詳情則於 19 October 2026 依 AWS 文件重新檢查。Anthropic 關於這 4 條路徑、API key 與 API version 的頁面，已於 27 October 2026 重新檢查。Model identifier、價格、SDK version 與 endpoint 形式都可能變更，因此本指南連結至提供者的頁面，而不直接列出容易過時的值。

路徑 1：Anthropic API key

這是直接路徑，也是唯一由 Anthropic 核發 secret 的方式。請求會傳送到 Anthropic API host 上的 Messages endpoint，而且每個請求都會攜帶 3 個 headers。

curl https://api.anthropic.com/v1/messages \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "content-type: application/json" \
  -d '{"model": "MODEL_ID", "max_tokens": 64, "messages": [{"role": "user", "content": "Hello"}]}'

將 MODEL_ID 替換為 Anthropic models overview 中目前可用的 identifier。正常回應是包含 content array 和 usage object 的 JSON。錯誤或已過期的 key 會回傳 HTTP 401 和 authentication_error。缺少 anthropic-version header 是另一種錯誤，因為每個請求都必須包含這個 header；SDK 會自動為你設定。截至 October 2026，Anthropic 的文件將 Authorization: Bearer 列為傳送 key 的主要方式，並將 x-api-key 標示為 legacy，但兩者都接受，因此上方的 command 仍可運作。目前的 SDK major versions 也會將 key 傳送為 Authorization: Bearer，因此讀取 X-Api-Key 的 proxy 或 gateway 在升級時需要修改。command 中的 2023-06-01 version 仍可接受；Anthropic 最新的 API version 是 2026-10-21。這些 SDK versions 預設會傳送該 version，而它會拒絕部分較舊的 request parameters，例如 temperature。

這些設定中，建立 client 最簡單，因為不需要自行建構任何內容。所有官方 SDK 都會自行從環境讀取 ANTHROPIC_API_KEY。

import os
from anthropic import Anthropic

client = Anthropic()  # reads ANTHROPIC_API_KEY from the environment

message = client.messages.create(
    model=os.environ["CLAUDE_MODEL"],
    max_tokens=64,
    messages=[{"role": "user", "content": "Hello"}],
)
print(message.usage)

將 model identifier 與 key 一起放在環境中是值得的。Model names 會依你無法控制的排程變更，而為了修改一個字串重新部署程式碼是可以避免的工作。

Key 會在 Console 中建立。建立時可以選擇到期時間：預設的 3 hours、1 day、7 days 或 30 days、自訂期間，或 Never，但仍受組織的最長到期政策限制。到期時間在建立時固定，之後無法變更。長期 key 到期前，Anthropic 會寄 email 通知建立者；但生命週期較短的 key 到期時，完全不會寄出警告 email。已過期的 key 會回傳 401，且無法重新啟用，因此修正方式永遠是建立新的 key。

Direct API 不需要選擇 region，費用也會直接計入你的 Anthropic organization。Workspace 可將 key 限定在單一 project，這是查看單一服務支出的最清楚方式。建立 server 的 key 時，請將其限定在該 server 的 workspace：未限定至 workspace 的 personal 或 service account key，必須在每個請求中傳送 anthropic-workspace-id header，否則 API 會以 400 和 invalid_request_error 回應。服務應選擇 service account key，因為建立 personal key 的人離開 organization 後，該 key 便會停止運作。如需了解費用計算方式，請參閱 每 token API 定價與訂閱方案的比較。

這裡還有另一個選項，因為它可以完全移除 static secret。Workload Identity Federation 可讓 workload 將你已信任的 identity provider 所提供的 OpenID Connect (OIDC) token，交換為 POST /v1/oauth/token 上的短期 Anthropic token；SDK 會在該 token 到期前自動更新。不會在任何地方建立或複製 sk-ant-api... string。這適用於 Kubernetes、GitHub Actions 和 cloud VMs，因為這些環境本身已具備 platform identity。一般 VPS 通常沒有這類 issuer，因此在該主機上，將 API key 放在檔案中才是實際可行的答案，本指南其餘內容也都依此處理。

路線 2：Amazon Bedrock 上的 AWS 憑證

在 Bedrock 上完全不需要 Anthropic 金鑰。使用 AWS 憑證時，SDK 會以 AWS Signature Version 4（SigV4）為每個 HTTP 請求簽章，再由 AWS 判定該呼叫端是否可呼叫模型。

pip install -U "anthropic[bedrock]"
aws sts get-caller-identity

aws sts get-caller-identity 會輸出憑證解析出的身分之帳號號碼與 ARN（Amazon Resource Name）。使用 SigV4 時，請在其他操作前先執行此命令。對 SigV4 而言，SDK 會解析建構函式憑證、環境變數憑證與標準 AWS 憑證鏈；區域選擇則是獨立設定。透過用戶端或 AWS_BEARER_TOKEN_BEDROCK 提供的 Bedrock API key 優先於 SigV4 憑證，因此 STS 命令不會測試該驗證路徑。

建立用戶端時，只需變更類別與其中一個引數。

from anthropic import AnthropicBedrock

client = AnthropicBedrock(aws_region="us-east-1")

AnthropicBedrock 會驅動 Bedrock 的 InvokeModel 整合。截至 2026 年 10 月，Anthropic 也記載了 Amazon Bedrock 上的 Claude；Claude Opus 4.7 及更新模型可使用位於 https://bedrock-mantle.{region}.api.aws/anthropic/v1/messages 的 Messages API 端點，並透過同一套件中的 AnthropicBedrockMantle 用戶端存取。此端點支援 AWS 憑證與 Bedrock bearer token；兩個端點的模型存取要求不同，詳見下文。

請注意 pip install -U 那一行的升級。截至 2026 年 10 月 27 日，最新 SDK 預設傳送 API 版本 2026-10-21，包括透過 Bedrock 傳送時也是如此。Anthropic 的文件指出，該文件列出的 Claude Opus 4.6 及更早版本之 ARN 版本模型 ID，在 Bedrock 上不支援此版本，可能回傳 400 錯誤。若服務呼叫其中一個模型，請維持目前使用的 SDK 版本並加以固定，或先將服務移至 Claude 4.7 或更新版本的模型。

在這裡，區域不是裝飾性設定。Bedrock 端點依區域而異，各區域提供的 Claude 模型也不同，而且區域會納入 SigV4 簽章，因此針對某個區域計算的簽章會被另一個區域拒絕。請在服務環境中明確設定 AWS_REGION，因為各 SDK 對未設定此值時的處理方式並不一致。截至 2026 年 10 月的文件，Python 的 AnthropicBedrock 用戶端會讀取 AWS_REGION 或 AWS_DEFAULT_REGION，接著讀取 boto3 工作階段或 AWS profile 的區域（包括 ~/.aws/config）；若都無法解析，則會引發 ValueError。TypeScript 用戶端會讀取 AWS_REGION；未設定時改用 us-east-1，且不會以 ~/.aws/config 作為區域設定。因此，在同一台主機上，AWS CLI 可能可以成功列出 Claude 模型，但 Node 程序卻呼叫錯誤區域：CLI 讀取了設定檔，而用戶端沒有讀取。

在 EC2 執行個體上，您可以附加 IAM（identity and access management）角色，且不會有 secret 寫入磁碟，因為執行個體中繼資料服務會將臨時憑證提供給 SDK。AWS 外部的 VPS 同時沒有執行個體角色與中繼資料服務。此時您必須在下列兩者之間選擇：將長期存留的 IAM 使用者存取金鑰組放在主機上，其 secret 類型與 Anthropic 金鑰相同；或使用聯合驗證，向身分識別提供者進行驗證、呼叫 AWS STS（security token service），再使用它回傳的臨時憑證。Bedrock 也接受 Bedrock API key；這類 bearer token 會透過 AWS_BEARER_TOKEN_BEDROCK 傳送。AWS 文件記載了兩種類型。短期金鑰最長有效 12 小時；若產生該金鑰的工作階段較短，則有效期間以該工作階段為準。它會繼承產生金鑰之 IAM 身分的權限，也是 AWS 建議用於正式環境的類型。長期金鑰會持續到建立時指定的到期日，例如搭配 --credential-age-days 設為 30 或 90 天；它會在背後建立 IAM 使用者，AWS 僅建議將其用於探索。

費用會記入您的 AWS 帳戶，而不是 Anthropic；這通常就是使用此方案的主要原因。截至 2026 年 10 月的文件，區域端點比全域端點貴 10%。Claude Platform on AWS 是獨立產品：由 Anthropic 操作，AWS 透過 AWS Marketplace 收費，並使用 SigV4 或在 AWS Console 產生的 API key 驗證（Claude Console 產生的金鑰無法在此使用）。它透過 Anthropic 標示為 beta 的 AnthropicAWS 用戶端使用。請特別留意一個看似權限問題、實際上並非權限問題的 Bedrock 錯誤：Invocation of model ID ... with on-demand throughput isn't supported. Retry your request with the ID or ARN of an inference profile that contains this model. 這是模型路由問題，變更憑證無法修正。

路徑 3：Vertex AI 上的 Google 憑證

Anthropic 的文件目前將此路徑稱為 Google Cloud 上的 Claude Models（Google managed）。Google 會將其作為 Agent Platform 的一部分執行；Agent Platform 是 Google 對 Vertex AI 後續發展產品採用的新名稱。以下顯示的 aiplatform.googleapis.com 主機、anthropic[vertex] 額外項目及 AnthropicVertex 類別均未變更。

Google Cloud 使用 Application Default Credentials（ADC）。這是 Google 驗證函式庫用來尋找憑證的固定搜尋順序，不需要您指定憑證。ADC 會先檢查 GOOGLE_APPLICATION_CREDENTIALS，接著檢查由 gcloud auth application-default login 寫入的檔案，最後檢查透過 metadata server 附加的 service account。

pip install -U "anthropic[vertex]"
gcloud auth application-default login

在工作站上，登入會寫入 $HOME/.config/gcloud/application_default_credentials.json，完成後即可使用。在伺服器上，請避免儲存人類使用者的憑證；此命令也支援 service account impersonation。在 Google Cloud 外部沒有 Google metadata server，因此請使用 GOOGLE_APPLICATION_CREDENTIALS，將 ADC 指向 Workload Identity Federation 設定檔或 service account key 檔案。service account key JSON 檔案是長期有效的 secret，必須依照本指南稍後所述的方式妥善處理。在 Google Cloud 內部，請將 service account 附加至 VM，這樣便不需要保護檔案。無論 ADC 找到哪個身分，都必須具備包含 aiplatform.endpoints.predict 權限的 IAM 角色，例如 Agent Platform User（roles/aiplatform.user）。

from anthropic import AnthropicVertex

client = AnthropicVertex(project_id="my-project", region="global")

若不使用 SDK 而改用原始 HTTP，會有兩項變更。模型識別碼會從請求本文移至 URL 路徑，而 anthropic_version 會從標頭移至本文。截至 27 October 2026，Anthropic 的文件接受 vertex-2023-10-16，也接受較新的 API 版本 2026-10-21。憑證是一般的 Google access token。以下命令中的 gcloud auth print-access-token 使用 gcloud CLI 自己的登入狀態，而不是 ADC，因此請先在測試該命令的機器上執行 gcloud auth login 或 gcloud init。

curl https://aiplatform.googleapis.com/v1/projects/${PROJECT_ID}/locations/global/publishers/anthropic/models/${MODEL_ID}:rawPredict \
  -H "Authorization: Bearer $(gcloud auth print-access-token)" \
  -H "Content-Type: application/json" \
  -d '{"anthropic_version": "vertex-2023-10-16", "max_tokens": 64, "messages": [{"role": "user", "content": "Hello"}]}'

Region 是明確的參數。global 會依可用性動態路由，us 和 eu 是多區域識別碼，而 us-east5 這類名稱則會固定使用單一 region。截至 October 2026，Anthropic 僅針對 Claude Sonnet 4.6 及更早版本記錄單一區域端點；較新的模型會使用 global 或多區域端點。依 October 2026 的文件，多區域與區域端點的費用比 global 高 10%。計費會透過 Google Cloud project 處理，因此配額與發票由 Google 管理。

截至 27 October 2026，Anthropic 也記錄了另一項 Google Cloud 服務，其請求格式不同。在 Google Cloud 上的 Claude Models（Anthropic managed）中，Anthropic 會在 claude.googleapis.com 自行操作 Claude API，並透過 AnthropicGoogleCloud client 存取。該服務仍使用 Google Cloud 憑證進行驗證，包括 ADC，但請求格式與直接 API 相似：model 保留在本文中，而版本則放在 anthropic-version 標頭中。存取權來自其專用的 IAM 角色（roles/claude.user 及相關角色），設定程序會為該 project 建立新的 Anthropic organization，使用量則透過 Google Cloud Marketplace 計費。如果您的請求 URL 包含 aiplatform，且結尾為 :rawPredict，表示您使用的就是本節所述的 Google-managed 路徑。

路徑 4：Microsoft Foundry 是 Azure 路徑

如果您曾在 Azure 上搜尋 Claude，這就是您要找的章節，而且確實有受支援的路徑。Claude 在 Microsoft Foundry（前稱 Azure AI Foundry）中執行，並透過 Azure Marketplace 以 Claude Consumption Units 計費。您可以建立 Foundry 資源，在其中部署 Claude 模型，並呼叫位於 https://{resource}.services.ai.azure.com/anthropic/v1/* 的 Azure 託管端點。

有兩種憑證可用。第一種是從 Foundry 入口網站部署的 Details 分頁取得的 Azure 核發金鑰，放在 api-key 或 x-api-key 標頭中傳送。第二種是 Microsoft Entra token。伺服器環境較適合使用這種方式，因為 Azure role-based access control 會據此控管可呼叫端點的對象。

ACCESS_TOKEN=$(az account get-access-token --resource https://ai.azure.com --query accessToken -o tsv)

curl https://${RESOURCE}.services.ai.azure.com/anthropic/v1/messages \
  -H "content-type: application/json" \
  -H "Authorization: Bearer $ACCESS_TOKEN" \
  -H "anthropic-version: 2023-06-01" \
  -d '{"model": "DEPLOYMENT_NAME", "max_tokens": 64, "messages": [{"role": "user", "content": "Hello"}]}'

model 欄位承載的是您的部署名稱，不是模型識別碼。兩者預設相同，但只要您自行命名部署，兩者就會立即不一致。這通常是正確請求仍出現 Deployment not found 錯誤的原因。Python 和 TypeScript SDK 會從環境讀取 ANTHROPIC_FOUNDRY_API_KEY 和 ANTHROPIC_FOUNDRY_RESOURCE。並非所有 SDK 都支援 Foundry：截至 2026 年 10 月，支援 C#、Go、Java、PHP、Python 和 TypeScript。Go 使用專用的 foundry 套件（go get github.com/anthropics/anthropic-sdk-go/v2/foundry），而 Ruby SDK 仍需使用通用用戶端，並將其指向 Foundry base URL。

這種替代方式有一個明顯風險。如果您未明確將憑證傳給通用用戶端，而環境中仍設定 ANTHROPIC_API_KEY 或 ANTHROPIC_AUTH_TOKEN，用戶端就會讀取該憑證，並將您的 Anthropic 憑證傳送至 Microsoft 端點。請取消設定該變數，或明確將 Foundry 金鑰或 token 傳給用戶端。Entra access token 的預設有效期限會在 60 到 90 分鐘之間隨機決定，因此長時間執行的程序必須重新整理 token，不能只在啟動時取得一次。

伺服器上的憑證可使用多久？

[
  {
    "label": "Anthropic key, 30-day preset",
    "max_lifetime_hours": 720
  },
  {
    "label": "Anthropic key, 7-day preset",
    "max_lifetime_hours": 168
  },
  {
    "label": "AWS STS assumed role",
    "max_lifetime_hours": 12
  },
  {
    "label": "Bedrock short-term API key",
    "max_lifetime_hours": 12
  },
  {
    "label": "Entra ID access token, default upper bound",
    "max_lifetime_hours": 1.5
  },
  {
    "label": "Federated Anthropic token, default",
    "max_lifetime_hours": 1
  }
]

以下是各供應商公布的上限與預設值，資料讀取時間為 2026 年 10 月，並非實測數據。這些數值的重要性在於：它們告訴你，外洩的憑證在你確認外洩事件前，還能持續運作多久。圖表底部的聯合 Anthropic token 預設最長可使用 1 小時，且還受身分提供者 token 剩餘有效期限 2 倍的限制。Microsoft Entra access token 沒有單一固定的預設期限：Microsoft 會為每個 token 隨機設定 60 到 90 分鐘的有效期限，平均為 75 分鐘；圖表以其 1.5 小時的上限顯示，而實際預設值也會依 client、resource，以及租用戶是否啟用 Conditional Access 而異。當 client 與 resource 都支援 Continuous Access Evaluation 時，Entra 可能將有效期限延長至 24 到 28 小時，並在帳戶停用等事件發生時，改為接近即時地撤銷 token。租用戶的 token lifetime policy 可將期限設為 10 分鐘至 23:59:59。SDK 會自動更新聯合 Anthropic token；在 Foundry 上，請設定 Entra token provider 來更新 token，不要直接傳入固定的 token 字串。聯合規則可自行將 token 有效期限設為 1 分鐘至 24 小時，而 Console 的 Connect workload 精靈會預先填入 10 分鐘，因此請讀取規則內容，不要直接假設預設值。Assumed role 與 Bedrock short-term API key 的有效期限都為 12 小時。Bedrock long-term API key 沒有列在圖表中，因為它沒有固定上限：有效期限會持續到建立時選定的到期時間。因此 AWS 建議只在探索用途使用此類金鑰。使用 30-day 預設值建立的金鑰會維持有效 720 小時，而這就是會在伺服器上的檔案中保存一個月的憑證。

VPS 上憑證的存放位置

將 secret 放在只有 root 能讀取的檔案中，再由 systemd 將它提供給處理程序。這個做法不受 SDK 版本變動影響，因此值得一次正確完成。

sudo useradd --system --home /opt/claude-app --shell /usr/sbin/nologin claudeapp
sudo install -d -m 700 -o root -g root /etc/claude-app
sudo install -m 600 -o root -g root /dev/null /etc/claude-app/env
sudoedit /etc/claude-app/env

檔案內只放純 KEY=value 行。不要加入 export、引號或 shell 語法，因為 systemd 會自行剖析檔案，不會透過 shell 執行。

ANTHROPIC_API_KEY=sk-ant-api03-REPLACE-ME
CLAUDE_MODEL=REPLACE-ME

[Unit]
Description=Claude API service
After=network-online.target

[Service]
User=claudeapp
EnvironmentFile=/etc/claude-app/env
ExecStart=/opt/claude-app/venv/bin/python -m claude_app
Restart=on-failure

[Install]
WantedBy=multi-user.target

systemd 會以 root 身分讀取 EnvironmentFile=，之後才降權為 User=claudeapp，因此服務帳號不需要具備該檔案的讀取權限。由 root 擁有且權限設為 600 即可，這也是上方的 install 指令會如此設定的原因。使用 sudo systemctl enable --now claude-app 啟動服務，再以 systemctl status claude-app 確認 unit 已進入 active (running)，而不是陷入不斷重新啟動的迴圈。

以下有 4 件應避免的事項，每一項都有可自行驗證的原因：

• 不要在 unit 檔案中使用 Environment= 寫入金鑰。位於 /etc/systemd/system 下的 unit 可供所有使用者讀取，因此 systemctl cat claude-app 會將 secret 顯示給任何本機使用者。
• 不要將它提交至版本庫。.gitignore 只能讓新檔案不被提交，無法處理已提交的檔案，因為 git 歷史會保留曾經提供給它的內容。
• 不要將它嵌入 container image。ENV 值會持續存在於 image 設定中，而 build arguments 會出現在 image 歷史或 provenance metadata 中。在後續 layer 刪除檔案，也不會將它從先前的 layer 移除。請改用 --env-file 或掛載檔案，在執行時提供 secret。
• 不要將處理程序環境視為 root 無法存取的私有資料。sudo cat /proc/$(pgrep -u claudeapp -f claude_app | head -1)/environ | tr '\0' '\n' 會將金鑰顯示出來。讀取檔案的指令本身需要 sudo；shell 輸入重新導向會在 sudo 之前執行，並使用目前帳號的權限。目標是讓 secret 遠離主機上的其他帳號，而不是遠離 root；無論採取何種做法，root 都能讀取它。

最後一點界定了這項設計能提供的保護範圍。僅限 root 讀取的檔案可以保護儲存中的金鑰，但任何以服務帳號執行的程式碼都能讀取處理程序環境，子處理程序也會繼承該環境。若處理程序會執行並非由你撰寫的程式碼，這種容器就不適用，因為處理程序能執行的任何程式都能讀取自己的環境。讓 secret 遠離 AI agent 的存取範圍說明了這種情境；那是不同的問題，也需要不同的解法。

如何在不中斷服務的情況下輪替金鑰？

先部署新金鑰，最後撤銷舊金鑰。下列單一服務重新啟動期間會短暫中斷服務；若要維持不中斷的可用性，必須在重新啟動期間由另一個執行個體處理請求。

1. 在 Console 中建立新金鑰，並放在與舊金鑰相同的 workspace。
2. 使用 sudoedit 將金鑰寫入 /etc/claude-app/env。
3. 執行 sudo systemctl restart claude-app。
4. 確認服務能回應請求後，再在 Console 中撤銷舊金鑰。

服務啟動 unit 時會讀取 EnvironmentFile，因此執行中的程序會持續使用啟動時取得的值。systemctl daemon-reload 會重新讀取 unit 檔案，但不會變更執行中程序的環境，因此只有重新啟動服務後才會套用新金鑰。若在步驟 1 而非步驟 4 撤銷舊金鑰，服務就會中斷，直到步驟 3 完成為止。

雲端路由會在供應商端輪替。IAM 使用者可同時保有兩組啟用中的存取金鑰，因此先建立第二組、部署該金鑰，再刪除第一組。Google service account 金鑰也採用相同方式輪替。Foundry resource 會保有兩組金鑰；重新產生其中一組後，舊值會立即失效。因此，請先將服務切換到另一組金鑰，再重新產生目前使用的金鑰。Entra token 和 federated Anthropic token 不需要手動輪替；在可行的情況下使用這些 token，是採用它們的最充分理由。

在 Console 中操作時，請為 workspace 設定支出上限。金鑰外洩後，首先造成的通常是費用問題；限制 VPS 上 agent 可支出的金額 會逐步說明相關控制項。

為什麼用戶端會回傳 401 或 403？

直接 API 搭配 authentication_error 時回傳 401。 金鑰錯誤、已撤銷或已過期。最容易忽略的是過期，因為程式碼沒有變更，而請求昨天仍可正常運作。請在 Console 中查看金鑰的到期欄位，或從 Admin API 讀取 expires_at；未設定到期日的金鑰，其值為 null。個人金鑰的擁有者離開組織後，該金鑰也會停止運作。

SDK 忽略 federation 設定，改用金鑰。 在憑證優先順序中，ANTHROPIC_API_KEY 和 ANTHROPIC_AUTH_TOKEN 的優先順序高於 federation，因此其中任一項都會覆寫 federation。特別要注意的是，設為空字串的環境變數仍會占用該位置，因此 ANTHROPIC_API_KEY="" 會使 SDK 使用空金鑰進行驗證，而不會繼續往下尋找。請使用 unset ANTHROPIC_API_KEY。

federation 回傳單純訊息 Authentication failed 時的 401。 這則訊息刻意對所有可能原因保持一致，因此呼叫端無法透過錯誤文字探測規則設定。實際原因會記錄在 Console 的驗證歷程頁面。請先從該頁面開始排查，不要先猜測 JWT 的問題。

Foundry 回傳 403。 Token 已通過驗證，但 Azure 帳戶缺少允許執行該呼叫的角色。請將 Azure RBAC 角色指派給發出請求的身分，例如 Foundry User（前稱 Azure AI User）或 Cognitive Services User。

Bedrock 發生任何錯誤。 若使用 SigV4 驗證，請先以服務使用者執行 aws sts get-caller-identity。這可確認該主機是否具有可用的 AWS 憑證，藉此區分憑證問題、模型存取問題或區域不一致。截至 29 October 2026，AWS 會在具備必要 AWS Marketplace 權限的商業區域中，於首次使用時啟用許多模型的存取權，但部分模型仍需另外啟用帳戶層級的存取權。透過 InvokeModel 路由呼叫 Anthropic 模型時，每個帳戶首次都需要提交一次使用案例表單；若整個 AWS Organization 只需提交一次，但 opt-in 區域仍須再次提交。在申請核准前，呼叫會回傳 AccessDeniedException。AWS 說明該表單不適用於 bedrock-mantle endpoint。帳戶首次呼叫某個模型時，Bedrock 也會在背景中啟動 AWS Marketplace 訂閱；該訂閱需要具備 aws-marketplace:Subscribe、aws-marketplace:Unsubscribe 和 aws-marketplace:ViewSubscriptions 權限的身分。缺少這些權限不一定會使首次呼叫立即失敗：AWS 說明在設定訂閱期間，呼叫最多可能成功 15 分鐘；訂閱失敗後，後續呼叫會回傳相同的 AccessDeniedException。如果服務在最初幾分鐘正常運作，之後才開始失敗，問題較可能出在這裡，而不是憑證。授予權限後，AWS 最多需要 2 分鐘才能完成訂閱。若模型未在所呼叫的區域提供，無論憑證多麼正確，呼叫都會失敗。

FAQ

在 Bedrock 或 Vertex 上使用 Claude，是否需要 Anthropic API key？

不需要。在 Amazon Bedrock 上，SDK 會使用 AWS 憑證透過 SigV4 簽署請求，或傳送 Bedrock API key；在 Google Cloud 上，則會傳送透過 Application Default Credentials 取得的 Google access token。這兩種設定都不需要 Anthropic 核發的 secret，使用費用也會計入 cloud account，而不是 Anthropic。這也是為何留在 ANTHROPIC_API_KEY 的 Anthropic key 會對這些主機造成風險：指向 cloud endpoint 的通用 client 會直接將它傳送到該端點。

Azure 是否提供 Claude？

是，透過 Microsoft Foundry 提供。Microsoft Foundry 的舊名稱是 Azure AI Foundry。您需要建立 Foundry resource，將 Claude model 部署到其中，再使用 Azure 核發的 key 放在 api-key header 中，或使用 Microsoft Entra bearer token 呼叫 https://{resource}.services.ai.azure.com/anthropic/v1/messages。使用費用會透過 Azure Marketplace，以 Claude Consumption Units 計費。請求本體中的 model 欄位必須填入您的 deployment name。只有在建立 deployment 時保留預設名稱，該名稱才會與 model identifier 相同；之後無法變更名稱。

Linux server 上應將 Claude API key 儲存在哪裡？

將它儲存在 root 擁有且 mode 為 600 的檔案中，並透過 systemd unit 中的 EnvironmentFile= 載入。systemd 會先以 root 讀取該檔案，再切換至 unit 的 User=，因此 service account 不需要存取該檔案。不要將 key 放入 repository、unit file 本身，或 container image 的設定、layers 與 build metadata 中。unit file 可由所有使用者讀取，也會由 systemctl cat 顯示。

Claude API request 為何在沒有變更任何設定時開始回傳 401？

key 到達建立時指定的到期時間後，就會回傳 401。到期時間在建立時設定，之後無法編輯；短期 key 到期前也不會寄送警告 email。到期的 key 無法重新啟用，因此請建立 replacement，將它寫入 environment file，重新啟動 service，之後再撤銷舊 key。若確認 key 仍在有效期限內，請檢查是否有過時的 credential 覆蓋它：設為空字串的 ANTHROPIC_API_KEY 仍會優先於其下方的 federation 與 profile 來源。