AI Agent 要真正做事，就一定會碰到身分問題。
它要代表誰存取 Google Drive？能不能讀 Slack？能不能開 GitHub issue？憑證放哪裡？使用者撤銷授權後，agent 還能不能繼續存取？
Amazon Bedrock AgentCore Identity 解的就是這一層問題。
AgentCore Identity 是什麼？
AgentCore Identity 是 Amazon Bedrock AgentCore 的身分與憑證管理服務。
AWS 文件將它定位為讓 AI agents 安全存取外部服務的 authentication infrastructure。
它處理的不是模型推理，而是 agent 存取外部工具時的身分、授權、token 與憑證生命週期。
常見連接對象包括：
- Google Drive。
- Slack。
- GitHub。
- 企業內部 API。
- MCP tools。
- 第三方 SaaS。
為什麼 agent 需要自己的身分？
傳統程式常用 service account 或 API key。
但 AI Agent 的行為比較複雜。
| 傳統自動化 | AI Agent |
|---|---|
| 流程固定 | 會依任務選工具 |
| 權限通常固定 | 權限應依使用者與任務變化 |
| 較容易預測 | action chain 可能很長 |
| log 較單純 | 需要記錄 prompt、tool call、授權與結果 |
如果所有 agent 共用一組憑證，資安團隊會很難回答：
- 哪個 agent 讀了資料？
- 是代表哪個使用者？
- 這次 action 是否符合授權？
- token 是否已過期或被撤銷？
- 出錯後要停用哪個 agent？
它適合什麼情境？
AgentCore Identity 適合需要 agent 存取外部服務的場景。
例如：
- 研究 agent 讀 Google Drive 文件。
- 工程 agent 開 GitHub issue。
- 客服 agent 查 Slack 對話與知識庫。
- 業務 agent 讀 CRM 與行事曆。
- 財務 agent 呼叫內部報表 API。
- 多 agent 系統需要一致身分與稽核。
如果 agent 只在本機處理文字，不連任何工具，身分管理壓力較低。
但只要開始連 SaaS 或企業 API，就應該把 Identity 當成基礎設施，而不是應用程式裡隨便寫幾個 token。
導入時要檢查什麼？
| 問題 | 檢查方向 |
|---|---|
| Agent 是誰？ | 每個 agent 是否有可追蹤身分 |
| 代表誰做事？ | 是否能對應使用者或服務帳號 |
| 權限多大？ | 是否做到最小授權 |
| Token 放哪？ | 是否避免硬編碼與外洩 |
| 授權能否撤銷？ | 使用者或管理者是否能停用 |
| 有沒有 log？ | tool call 與授權結果是否可追查 |
這些問題比模型選型更早該處理。
和 Zero Trust 的關係
AgentCore Identity 和 AI Agent 零信任架構高度相關。
零信任要求不要預設信任任何 actor。AI Agent 也不例外。
比較健康的架構是：
User → Agent Identity → Scoped Authorization → Tool Access → Audit LogAgent 不應該直接拿著一把萬能鑰匙到處跑。
每次工具存取都要有身分、範圍、授權與紀錄。
結論
AgentCore Identity 的重要性不在於它讓 agent 更會回答問題，而是讓 agent 更接近可以進 production 的系統。
AI Agent 真正要上線，必須從「模型會不會做」進一步走到「誰允許它做、它能做多少、做完能不能追查」。
這正是 agent 身分管理開始變成新基礎設施的原因。