當企業開始將生成式 AI 代理（Agents）部署到多租戶（Multi-tenant）的生產環境中，開發者往往會面臨一個棘手的身分識別難題：當 AI 代理代表使用者呼叫下游 API 或工具時，系統該如何正確驗證「操作者」的身分？
過去，處理這類「代理呼叫」通常有兩種做法，但各有缺失。第一種是讓 AI 代理使用自己的服務身分（Service Identity）來進行呼叫。這種做法會導致稽核追蹤鏈斷裂，因為下游系統無法辨識出原始使用者是誰，必須無條件信任代理系統。第二種則是直接轉發原始使用者的權限代幣，但這會帶來「混淆代理人（Confused Deputy）」的安全風險，且當系統規模擴大、涉及多個租戶時，這種方式極難維護且不具備擴展性。
為了解決這個痛點，Amazon Bedrock AgentCore Identity 現在原生支援 OAuth 2.0 代幣交換（Token Exchange）規範（RFC 8693），並導入「代表執行（On-Behalf-Of, OBO）」模式。這項技術的核心在於身分轉換：當使用者觸發 AI 代理時，系統會將原始代幣轉換成一個專為該代理、該次任務所核發的新代幣。在這個過程中，JWT（JSON Web Token）的聲明（Claims）會在每一站進行轉換，確保下游系統既能確認是哪位使用者發起的請求，也能確保該請求是經由合法的 AI 代理轉發。
這項發展對於軟體產業，特別是 B2B SaaS 供應商具有深遠影響。在多租戶架構下，確保資料隔離與存取授權是生存命脈。透過 OBO 機制，開發者可以實現更細粒度的存取控制。例如在 AWS 提供的「TravelBot」參考案例中，即使同一個 AI 助理服務於不同的企業客戶（如 Acme 與 Globex），系統也能精準地根據 OBO 代幣，確保 AI 只能存取所屬企業的訂票資料，而不會發生資料外洩或權限越位的情況。
從技術趨勢來看，這標誌著 AI 應用從「單機運作」轉向「複雜協作」的重要里程碑。隨著企業對 AI 的期待不再只是聊天機器人，而是能實際操作後端系統、處理商業邏輯的自動化工具，身分安全將成為核心戰場。Amazon Bedrock 的這項更新，為開發者提供了一個標準化、可擴展的框架，讓 AI 代理在處理跨系統任務時，能擁有與傳統軟體架構同等、甚至更高規格的安全防護水準。這不僅簡化了開發流程，更為生成式 AI 在受規管行業（如金融、醫療）的大規模應用鋪平了道路。