在 LOG_ONLY 模式中測試政策

使用政策層級強制執行模式，您可以在 ACTIVE和 之間切換LOG_ONLY以回答問題：「如果套用此政策，會如何處理我的流量？」 每個政策LOG_ONLY模式可讓您在實際流量上測試政策，而不會影響授權決策。政策會將每個請求視為強制執行，但只會將結果寫入日誌。由於強制執行模式為 的政策，因此不會封鎖或允許任何內容LOG_ONLY。一旦您信任結果，請將其提升為 ACTIVE。

LOG_ONLY 模式的運作方式

政策引擎中的每個政策都有 ACTIVE或 的強制執行模式LOG_ONLY。預設值為 ACTIVE，因此現有政策以及您建立但未指定 欄位的任何新政策都會繼續像以前一樣強制執行。當政策引擎評估請求時，它會並排評估您的ACTIVE政策和您的LOG_ONLY政策，但只會對ACTIVE政策強制執行。

ACTIVE 政策會決定傳回 AgentCore Gateway 並強制執行的決策。政策引擎會套用「default-deny」和「forbid-wins」語意，這表示只有在政策允許請求，且任何作用中政策的單一禁止拒絕請求時，才允許請求。

LOG_ONLY 政策會根據相同的請求進行評估，但其結果會保持個別。它們會以追蹤形式報告，並以 Amazon CloudWatch 指標的形式發出。它們永遠不會合併為強制執行的決策。

請求會以兩個階段評估：

ACTIVE 和 LOG_ONLY 被視為兩個隔離集；LOG_ONLY政策永遠無法變更來電者的體驗。請求收到的決策不受任何LOG_ONLY政策影響。

除了記錄與請求相符LOG_ONLY的政策之外，政策引擎還會報告哪些政策如果是 ，將會變更決策ACTIVE。這是評估政策的有效性和安全性 （即是否可以提升為 ACTIVE) 時要使用的關鍵訊號。例如，經常比對並出現在決策翻轉集中LOG_ONLY的政策，會在觀察時段期間封鎖您的流量。每個LOG_ONLY政策的評估都獨立於所有其他LOG_ONLY政策，以確定決策翻轉政策集。不過，每個LOG_ONLY政策評估都會考慮所有目前的ACTIVE政策。

LOG_ONLY 政策和 LOG_ONLY 政策引擎

AgentCore 中的政策有兩個不同的控制項，兩者都使用 LOG_ONLY 值。它們在不同層級操作並回答不同的問題，因此請務必了解您要設定哪個層級。

政策引擎強制執行模式： 控制引擎的整體行為。設為 時LOG_ONLY，不會強制執行引擎中的政策，無論其個別政策模式為何。會記錄所有決策。當您使用 CreateGateway或 UpdateGateway操作將政策引擎與閘道建立關聯policyEngineConfiguration時，這會使用 的 mode 欄位設定。mode 接受的兩個值為 ENFORCE（預設） 和 LOG_ONLY。

政策模式控制強制引擎內單一政策的行為。設為 LOG_ONLY 時，仍會評估該政策，但會記錄其決策而非強制執行。引擎中的所有其他ACTIVE政策會繼續正常強制執行。enforcementMode 接受的兩個值為 ACTIVE（預設） 和 LOG_ONLY。

使用政策層級 LOG_ONLY 在生產環境中陰影測試新的護欄，而不會影響流量。在啟用強制執行之前，使用引擎層級 LOG_ONLY 觀察所有政策的行為。

設定政策的強制執行模式

您可以在建立或更新政策 （即 CreatePolicy和 UpdatePolicy) 時，在政策上設定 enforcementMode 欄位，並由 GetPolicy和 傳回。 ListPolicies

在 LOG_ONLY 請求中將 enforcementMode設定為 ，以在 LOG_ONLY 模式下建立政策LOG_ONLYCreatePolicy。下列範例會在政策中建立護欄，以禁止超過可信度閾值的暴力內容，但只會觀察到該內容。如需政策中護欄的詳細資訊，請參閱政策中的護欄。

aws bedrock-agentcore-control create-policy \
--policy-engine-id my-policy-engine-id \
--name "LogOnlyViolenceFilter" \
--enforcement-mode LOG_ONLY \
--validation-mode IGNORE_ALL_FINDINGS \
--definition '{"policy":{"statement":"forbid (principal, action == AgentCore::Action::\"MyTarget\", resource == AgentCore::Gateway::\"arn:aws:bedrock-agentcore:us-east-1:111122223333:gateway/my-gateway\") when guardrails { BedrockGuardrails::ContentFilter([\"VIOLENCE\"], [context.input.userMessage])[\"VIOLENCE\"].confidenceScore.greaterThan(decimal(\"0.7\")) };"}}'

回應會以「enforcementMode」：「LOG_ONLY」回應政策。政策會開始針對流量進行評估，從該時間點開始，其相符項目會出現在追蹤和 CloudWatch 指標中，而不會影響任何決策。

列出政策及其強制執行模式

ListPolicies 會在每個政策摘要enforcementMode中傳回，因此您可以快速查看正在觀察和強制執行的政策。

aws bedrock-agentcore-control list-policies \
--policy-engine-id my-policy-engine-id \
--query 'policies[].{name:name,enforcementMode:enforcementMode,status:status}'

回應

[
  { "name": "LogOnlyViolenceFilter", "enforcementMode": "LOG_ONLY", "status": "ACTIVE" },
  { "name": "RefundLimit",           "enforcementMode": "ACTIVE",   "status": "ACTIVE" }
]

觀察 LOG_ONLY 結果

當發起人透過 AgentCore Gateway 提出工具/呼叫請求時，閘道會在傳回 MCP 回應給發起人之前評估所有政策，包括LOG_ONLY政策。發起人的回應永遠不會受到LOG_ONLY政策的影響；這些結果只會透過可觀測性報告。

您可以透過追蹤和 Amazon CloudWatch 指標觀察LOG_ONLY政策行為：

追蹤和範圍：當您在閘道上啟用追蹤時，政策評估範圍會包含LOG_ONLY比對資訊。您可以在 AgentCore 可觀測性主控台中檢查這些範圍，以查看在特定請求上觸發哪些LOG_ONLY政策，以及它們是否會翻轉決策。如需詳細資訊，請參閱在 Amazon Bedrock AgentCore 可觀測性上觀察您的代理程式應用程式。

CloudWatch 指標：AgentCore 中的政策會在 AWS/Bedrock-AgentCore 命名空間下發出指標。下列指標專屬於LOG_ONLY評估：

所有指標都包含用於篩選的 PolicyEngine 和 OperationName 維度。每個政策指標還會包含具有政策 ID 的政策維度。

如需檢視 AgentCore 資源指標的詳細資訊，請參閱 Bedrock AgentCore 產生的可觀測性資料。

將政策提升為強制執行

當您對LOG_ONLY政策有信心時，請使用 將其提升為強制執行UpdatePolicy，將 enforcementMode設定為 ACTIVE。不需要其他變更，且政策會保留其 ID、名稱和定義。

aws bedrock-agentcore-control update-policy \
--policy-engine-id my-policy-engine-id \
--policy-id LogOnlyViolenceFilter-a1b2c3d4e5 \
--enforcement-mode ACTIVE

也支援反向：您可以將ACTIVE政策移回 LOG_ONLY，使其脫離強制執行狀態，同時保持原狀並繼續觀察。

因此，典型的生命週期是在 中建立政策LOG_ONLY、觀察流量和指標，然後將其提升為 ACTIVE - 並在必要時將其降級回 ，LOG_ONLY而無需刪除並重新建立政策。

選擇具有 LOG_ONLY 模式的閾值

LOG_ONLY 模式對於護欄政策特別有用，其中您需要選取可信度分數閾值，以平衡安全性與對合法流量的中斷。太低的閾值會封鎖合法請求；太高的閾值可能會讓威脅通過。

建議的工作流程：使用您認為合理的閾值 （例如 0.7) 在LOG_ONLY模式下部署護欄。此政策會評估每個請求，並向 CloudWatch 指標發出可信度分數，但絕不會封鎖流量。

透過代表性時段累積資料 - 實際生產流量的天數或週數。ConfidenceScore 指標 （使用 PolicyEnforcementMode=LOG_ONLY) 可為您提供流量產生的分數分佈。

根據地面事實分析分數。如果您有標示的測試集 （標示為良性或惡意提示），您可以在每個閾值計算精確度和召回，然後選取最符合您目標的項目。如果您沒有已標記的資料，則範例提示來自高分數範圍 （例如 0.8–1.0)、低分數範圍 (0–0.2) 和不明確中間區域 (0.4–0.7)，然後分類每個範例以在您的閾值選擇中建立可信度。使用您選擇的閾值更新政策，並將其提升為 ACTIVE：

aws bedrock-agentcore-control update-policy \
--policy-engine-id my-policy-engine-id \
--policy-id LogOnlyViolenceFilter-a1b2c3d4e5 \
--enforcement-mode ACTIVE \
--definition '{"policy":{"statement":"forbid (principal, action == AgentCore::Action::\"MyTarget\", resource == AgentCore::Gateway::\"arn:aws:bedrock-agentcore:us-east-1:111122223333:gateway/my-gateway\") when guardrails { BedrockGuardrails::ContentFilter([\"VIOLENCE\"], [context.input.userMessage])[\"VIOLENCE\"].confidenceScore.greaterThan(decimal(\"0.65\")) };"}}'

此工作流程可確保閾值反映您的實際流量模式，而不是一般預設值。

考量和限制

LOG_ONLY 政策永遠不會影響決策。LOG_ONLY 政策無法導致允許或拒絕動作。請求收到的決策與其在LOG_ONLY政策不存在時將收到的決策相同。這是 功能的核心保證。

變更最終會一致。建立、更新或提升政策會在幾秒鐘內套用至評估路徑。相應地規劃觀察時段和提升步驟，而不是預期即時切換。

結果清單會受限。LOG_ONLY比對和決策翻轉清單每個請求上限為 1，000 個項目。對於具有大量LOG_ONLY政策的引擎，依賴 CloudWatch 指標進行完整的彙總計數。

評估可以是部分評估。當請求LOG_ONLY的評估未完成時，該請求的LOG_ONLY訊號可能會遺失項目。強制執行的決策永遠不會受到影響。