Agent 可以做嘢，但佢做嘢嗰陣，係用邊個身份？
呢個係一個好實際嘅安全問題。一個 AI Agent（人工智能代理）幫你改工單、讀客户資料，但佢代表邊個做呢啲事？如果佢喺錯嘅身份做錯嘅事，邊個問責？
AWS 同 Okta 喺2026年11月6日同一時間連發兩篇技術部落格，拆解呢個問題：第一篇示範點樣用 Okta Cross App Access（XAA，跨應用存取）同 Amazon Bedrock AgentCore，建立單一 Agent 嘅治理機制；第二篇將架構擴展至企業級規模，加入統一閘道、策略評估、多 Agent 接入同集中監察。
第一篇：單一 Agent 嘅權限鏈
架構好簡單：一個 Agent、兩個 Model Context Protocol（MCP，模型上下文協議）server。每個請求帶三個令牌——用户身份令牌（ID token）、Okta 嘅授權決定（ID-JAG）、同資源接受嘅存取令牌。
BFF（後端為前端）將用户 ID token 交換成 ID-JAG，交畀 AgentCore runtime，再換出短效存取令牌。AgentCore Identity 將呢個令牌放喺安全嘅「令牌庫」入面，agent 代碼根本見唔到。
測試數據：管理員將用户移除後，Okta 約1秒內拒絕該 Agent 新請求；已發出嘅令牌5分鐘內過期。AgentCore Identity 為一個約30秒嘅請求僅增添約0.6秒處理時間。
第二部分：企業級擴展
資料圖片：Pixabay
單一 Agent、兩個 MCP server 嘅架構好，但擴展唔到數百個 Agent、數千個工具嘅企業環境。
第二部分引入幾個關鍵組件：
- AgentCore Gateway：統一入口，代為換取各目標嘅授權。唔理 Agent 部署喺邊（雲上定 K8s 上），佢都通過同一個閘道。
- Cedar 策略：將每個工具綁定至指定 Agent 及 Okta 所授權嘅範圍。唔符合策略嘅調用，唔會換取 ID-JAG。
- AgentCore Observability + CloudWatch：集中檢視所有授權決策。每個步驟發出 OpenTelemetry span，Okta System Log 透過 EventBridge 流入 CloudWatch。
另加入一個運行喺 Amazon EKS（Kubernetes 服務）上、擁有獨立 Okta 身份嘅 Agent，證明統一閘道唔依賴部署位置。
點解呢個重要？
呢個唔係「加個 AI 字就值得買」嘅賣點。當企業成百上萬個 Agent 喺不同系統做嘢，權限治理就係安全嘅地基。冇呢個，Agent 就係一把冇鎖嘅鑰匙。
阿調搞兩下
呢兩篇教程好誠實：先講簡單情況，再講複雜情況，最後落到「點樣睇全部決策」。冇乜玄學，就係身份驗證、策略評估、日誌。但呢啲基礎嘢，好多公司仍然冇做好。
你哋公司嘅 Agent，有冇人攞住個令牌？邊個先可以攞返？
