對於許多剛接觸 AI Agent 開發的工程師來說，最容易陷入的誤區是認為只要把 LLM 接上工具（Tools）就能跑。但在企業環境中，真正的挑戰不在於 AI 能不能執行任務，而是在於治理（Governance）：誰有權限執行這個動作？如何確保 Agent 不會亂改資料？如何在大規模部署時管理數百個 Agent 而不陷入混亂？
AWS 最近發布的 Loom 是一個開源的參考平台（Reference Platform），旨在展示企業如何在 AWS 上建構、部署並治理 AI Agent。需要注意的是，Loom 並非一個開箱即用的託管服務，而是一個「範本」，告訴平台工程師應該如何設計一套符合企業安全標準的 Agent 管理系統。
解決 AI Agent 的身分傳遞難題
在複雜的企業流程中，Agent 經常需要代表使用者去呼叫其他服務。例如：使用者要求 Agent 查詢報表，Agent 呼叫一個 MCP 伺服器（Model Context Protocol，一種讓 AI 統一存取外部資料的標準協議），而該伺服器最後又去請求一個 REST API。
這裡會產生一個嚴重的安全問題：身分傳遞（Identity Propagation）。如果 Agent 使用自己的高權限帳號去跑所有流程，就失去了審計追蹤，且容易導致權限過大。Loom 解決這個問題的方式是實作完整的授權碼流程，並利用 RFC 8693 令牌交換（Token Exchange）機制。
簡單來說，當請求在 Agent、MCP 伺服器與 API Gateway 之間跳轉時，系統會不斷交換並產生「代表某人（on-behalf-of）」的 Token。這樣下游的 API 就能知道這個請求最初是由哪個使用者發起的，並僅回傳該使用者有權限查看的資料，而非讓 Agent 擁有上帝視角。
拒絕運行時生成程式碼，確保部署安全
許多 AI 框架允許 Agent 在運行時動態生成並執行程式碼（Runtime Code Generation），這在開發環境很方便，但在企業生產環境是極大的安全漏洞。
Loom 採取了一種截然不同的立場：配置驅動部署（Configuration-driven Deployment）。它使用 Strands Agents SDK 預先寫好可配置的 Python Agent，在部署時才注入行為指南、記憶體資源與 MCP 配置。
對工程師而言，這意味著程式碼在部署前後是不變的。平台團隊可以對這份程式碼進行一次性的安全掃描，加入標準的日誌紀錄（Logging）要求，然後將其重複部署到不同環境。如果不需要自定義邏輯，則可以使用 AgentCore 提供的無程式碼路徑。此外，所有機密資訊（Secrets）都統一存放於 AWS Secrets Manager，而非寫在配置或程式碼中。
企業級治理的實作維度
為了防止 Agent 數量失控（Agent Sprawl），Loom 引入了幾套治理機制：
首先是資源標記（Tagging）。所有部署的資源必須強制標記應用程式名稱、群組與擁有者，以便追蹤成本與責任歸屬。
其次是精細的存取控制。它結合了角色（Role）與群組標記（Group Tags）。管理員可以看到所有 Agent 的目錄，而一般使用者則只能看到屬於自己群組的 Agent 與對話紀錄。
最後是人機協作審核（Human-in-the-loop）。對於敏感的操作，Loom 透過 Strands Agents 的鉤子（Hook）框架或 MCP 的請求機制，讓 Agent 在執行高風險工具前必須暫停並等待人類核准。
總結與實務思考
Loom 提供了一個從身分驗證、部署管線到資源治理的完整藍圖。它告訴我們，企業級 Agent 平台的核心不在於模型有多強，而是在於如何將 AI 封裝在既有的企業安全體系（如 IAM、Secrets Manager）之中。
對於平台工程師來說，Loom 的價值在於它定義了 Agent 治理的七大挑戰：一致的標記、權限控制（RBAC/ABAC）、部署藍圖、部署前驗證、身分傳遞、規模化管理以及人工審核。雖然你可以快速搭建一個簡單的 Agent，但要構建一個能讓公司法務與資安部門放心通過的平台，則需要考慮上述這些工程細節。
來源：infoq.com
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。