Amazon Web Services 正在為 Amazon Bedrock AgentCore 加入時間性政策，讓開發者能根據 AI 代理在同一個工作階段稍早所做的事情，來授權其當前動作。這項控制專為這類工作流程設計：單一工具呼叫看起來可能安全，但因為前面的流程順序而變得有風險。

這項變更處理了傳統存取控制中的缺口。傳統應用程式權限通常是獨立評估每個請求，而 AI 代理則會在執行時選擇工具、引數與執行順序。AWS 表示，新的方法可強制執行必要的工作流程步驟、維持工具呼叫之間的資料完整性、限制累積的財務曝險，並在敏感動作前要求人工核准。

AWS 正在改變什麼

AWS 將時間性政策描述為 Bedrock AgentCore 既有政策控制的狀態式延伸。政策引擎不再只問某個主體是否可呼叫特定工具，而是可以檢視代理最近的軌跡，並判斷當前請求在該情境下是否獲得授權。

例如，代理可能使用客戶查詢工具、取得一組帳號，然後將不同的號碼傳給資金轉帳工具。這兩次呼叫都可能符合無狀態權限。時間性政策可以要求轉帳引數必須與先前的工具輸出相符，若代理改動或捏造了數值，便會封鎖該請求。

AWS Machine Learning Blog 內的其他例子包括：在交易前必須先查詢投組、確保資料查詢發生的時間足夠近期以支援決策，以及當累積交易曝險達到定義上限時終止工作階段。AWS 也描述了用於防止相互矛盾行為的控制，例如代理在短時間內先核准又拒絕同一筆保險理賠。

這項功能屬於 Amazon Bedrock AgentCore，也就是 AWS 用來建置與營運 AI 代理 的服務組合。其執行點是 AgentCore Gateway，會將支援的模型、工具與代理對代理流量透過中央端點進行路由。

時間性授權如何運作

被時間性政策評估的請求會帶有 x-amzn-bedrock-agentcore-policy-session-id 標頭。這個識別碼會把請求連結到一條軌跡，而其中包含相關的先前動作、輸入與輸出。應用團隊可自行決定一個工作階段代表對話、多步驟任務，或較長時間執行的工作流程。

AWS 建議將工作階段範圍維持得相對狹窄，因為同一個工作階段在任何時間點只能有一個授權請求處於活動狀態。此服務會將工作階段識別碼與最終使用者身分結合，因此即使兩位使用者提供相同識別碼，系統仍會以不同軌跡進行評估。AWS 表示，可回溯的時間窗限於 24 小時，超過後較舊的事件會自動刪除。

時間性政策是在閘道層執行，而不是在代理自己的程式碼內執行。這個架構很重要：代理無法改寫政策邏輯，也不能直接操控用於授權的狀態。AWS 表示，該引擎會回傳確定性的允許或拒絕結果、記錄決策脈絡、預設拒絕，且在允許與禁止規則衝突時，以禁止為優先。

這些控制並不是協調層。它們不會轉換請求、分析資料，也不會決定代理應該呼叫哪個工具。它們的角色更窄：根據觀察到的歷史，判定經由閘道路由的請求是否允許。

證據與實作細節

這項變更的主要證據來自 AWS 自己的技術文章，其中提供了功能說明，以及一個涉及私人銀行代理的完整範例。在該情境中，代理會擷取客戶資訊、載入投組持股、取得市場價格、進行分析，並代表財務顧問執行交易。

AWS 表示，該範例使用 Amazon Cognito 做身分識別、JSON Web Tokens 做入口驗證，並透過 AgentCore Gateway 暴露 MCP 工具。範例所使用的政策語言是 Dogwood，AWS 將其描述為用於代理及其工具的開源治理語言。根據 AWS 的說法，Dogwood 可以評估既有的 Cedar 政策，同時新增對時間性條件的支援，讓客戶無需遷移即可保留現有 Cedar 規則。

來源並未提供獨立測試結果、客戶採用數據，或證明這些控制能防止所有類型的代理失敗。關於規避抵抗力與運作行為的說法，屬於 AWS 的產品與架構主張。可取得的媒體項目只是重複公告標題，並未補充任何獨立報導的細節。

對於評估此功能的團隊，也存在操作上的限制。若缺少工作階段標頭，AgentCore 可能會產生新工作階段，這表示政策引擎看到的是空白軌跡，而不是預期中的歷史。AWS 表示，政策變更會使既有工作階段失效，讓後續決策使用目前的政策集合與預期的事件結構。這些行為使工作階段管理與政策部署成為安全設計的一部分，而不只是設定細節。

為何這對開發者與企業很重要

對 AI 開發者來說，時間性政策提供了處理一個難以僅靠提示詞或應用層檢查可靠解決的問題的控制點：在模型選擇的一連串動作中維持不變量。政策可以要求某個工具呼叫必須使用先前已驗證的輸出、高影響動作必須遵循定義好的程序，或必須先出現人工核准事件才能執行。

對企業而言，主要價值在於，當代理流量抵達工具與模型的邊界時，可以維持一致性。只要請求經過 AgentCore Gateway，共用閘道就能對 MCP 呼叫、模型推論呼叫與代理對代理互動套用規則。這可降低每個代理實作都必須自行重建工作流程控制的需求，不過團隊仍須設計政策、身分模型、工作階段邊界與核准流程。

這種做法也可能有助於控制有限的財務或營運風險。例如，無狀態規則可以限制單筆交易的規模，但無法自行判定某個工作階段累積了多少曝險。時間性狀態讓這類累積式限制得以表達。代價是更依賴準確的事件擷取與仔細界定的軌跡。新的工作階段也可能抹去政策原本預期要檢視的歷史。

這使 AgentCore 更直接地對上強調執行期治理、工具權限與 human-in-the-loop 控制的代理平台。現有證據不足以在延遲、政策表達能力或部署成本方面，將 AWS 的實作與競品進行比較。

接下來要關注什麼

下一步值得觀察的訊號會偏向實務，而非宣傳。開發者應關注 Dogwood 與其時間語義的更完整文件、銀行流程以外的更多範例，以及在生產規模下政策評估延遲與記錄的細節。

企業買家也應檢視團隊如何測試依賴軌跡的規則、如何從失敗或中斷的工作階段中復原，以及如何在不干擾合法工作流程的情況下管理政策變更。獨立的客戶回報將有助於確認，相較於內嵌於代理程式碼的控制，閘道層強制執行是否能降低事件或實作成本。

支援流量的範圍也很重要。AWS 表示，時間性政策可以治理透過閘道路由的模型、MCP 工具與代理對代理呼叫；採用與否將取決於組織的代理架構有多少能走這條路徑，而不形成瓶頸。

Creati.ai 觀點

AWS 正在回應代理安全中的一個真實弱點：授權決策往往需要記憶。最關鍵的風險不一定是被禁止的工具呼叫，而可能是發生在不受信任查詢、過時資料擷取、缺少核准或過度先前活動之後的允許呼叫。

時間性政策本身不會讓代理變得可靠。它們在代理行為周圍建立了更強的執行邊界，前提是開發者要定義可信的工作階段身分、擷取正確的事件，並以失敗序列來測試政策。對於將代理導入金融、客服或其他高影響工作流程的團隊來說，這種差異——政策強制執行，而非模型遵循——可能才是更有意義的發展。