時間政策範例

本節中的政策會從先前在相同工作階段中發生的情況決定。它們可讓您在支出之前要求核准、使已過時的許可過期、限制執行中總數，或在失敗後封鎖動作。沒有單一請求攜帶足夠的資訊來決定其中任何一項。

每個範例都會授權 資源組態中針對範例所述的參考閘道。如需暫時事件結構描述、運算子、工作階段 IDs、配額和區域可用性，請參閱暫時政策和編寫暫時政策。

使用這些範例之前

有四件事可判斷時間政策的行為是否符合您的預期。

需要工作階段 ID

時間歷史記錄的範圍為您命名的工作階段。在每個請求的 x-amzn-bedrock-agentcore-policy-session-id 標頭中傳送工作階段 ID，從第一個請求開始。閘道不會為您產生閘道，而且如果引擎保留時間政策，則沒有工作階段 ID 的請求會驗證失敗。

只有允許的動作會變成response事件

只有在政策允許且已完成時，動作才會記錄response事件。拒絕動作會改為記錄error事件。因此，下列每個範例也需要先備動作permit的純文字，否則會拒絕先決條件、永遠不會記錄為 response，且時間條件永遠不會相符。每個範例都說明允許 與之配對。

eventResource: resource 為必要

每個述詞都必須包含 eventResource: resource，其會將相符的事件連結到政策範圍內的資源。省略它會被 拒絕temporal predicates do not constrain the matched event to the current request’s resource。您不需要撰寫 sessionId- 事件結構描述範圍已是目前工作階段的每個述詞。

排序比較需要整數；等式不需要

在temporal { }區塊內，兩種比較類型接受不同的類型。

• 訂購 - <、>、 >= - ⇐需要兩側integer的 。當您使用 建立政策時， decimal或 string會遭到拒絕comparison requires numeric operands on both sides。

• 等式 — ==和 != — 適用於任何類型，只要兩端都是相同的類型。這是相互關聯使用的： input.claimId 與 的比對會context.input.claimId比較兩個支援的字串。

因此，將時間政策必須總或閾值的任何值建模為 integer。因此，參考閘道會在這些範例彙總的工具上以整數次要單位陳述金錢。總和有相同的需求和自己的訊息： sum需要 總integer和。如需詳細資訊，請參閱 條件中的參數類型。

相同宣告需要事先核准

目的：僅允許針對先前在工作階段中核准的宣告進行付款，因此客服人員無法針對其所建立的宣告 ID 進行付款。

::response 述詞符合已完成的 approve_claim。將 output.claimId與目前請求的 相關聯context.input.claimId，是將支出與該特定核准相關聯 - 在沒有相互關聯的情況下，工作階段中的任何核准都會授權任何宣告的支出。

permit (
    principal,
    action == AgentCore::Action::"InsuranceAPI___disburse_payment",
    resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/insurance-gw-a1b2c3d4e5"
)
when temporal {
    formerly within 1h AgentCore::Action::"InsuranceAPI___approve_claim"::response{
        eventResource: resource,
        output.claimId: context.input.claimId
    }
};

重要

output.* 只有當目標宣告工具的輸出結構描述時，才會在response事件上存在 欄位。許多目標不會 – 例如，Lambda 目標通常只會宣告輸入，然後事件只會攜帶 eventPrincipal、eventResource、input.*、 requestId和 sessionId。

如果您為事件未宣告的欄位命名，服務會拒絕政策，而錯誤會列出可用的項目：

predicate `AgentCore::Action::"MyTarget___verify_purchase"::response` mentions field
`output.orderId`, which is not declared on that event (declared fields: eventPrincipal,
eventResource, input.orderId, requestId, sessionId)

使用該清單來查看您可以相互關聯的項目。如果沒有輸出欄位，請在共用輸入欄位上建立關聯 — input.claimId: context.input.claimId 將兩個呼叫連結到相同的宣告，而不需要先前的工具來傳回任何內容。

兩者不相等，因此請謹慎選擇。輸入相互關聯符合先前請求的呼叫；輸出相互關聯符合其傳回的內容。如果您的規則取決於先前工具產生的值 — 核准 ID、計算數量 — 只有輸出相互關聯才會強制執行它，這需要目標宣告輸出結構描述。

將此項目與一般許可配對，以便允許並記錄核准：

permit (
    principal,
    action == AgentCore::Action::"InsuranceAPI___approve_claim",
    resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/insurance-gw-a1b2c3d4e5"
);

工作階段中的請求序列	決策
disburse_payment 沒有事先核准	拒絕
approve_claim 對於宣告，然後disburse_payment對於相同的宣告	允許
approve_claim 一個宣告，另一個disburse_payment宣告	拒絕

需要先決條件動作

目的：只有在有人在工作階段中查詢其狀態後，才允許核准宣告。

比對::request表示只需要嘗試先決條件，而不是成功。與 的許可配對get_claim_status。

permit (
    principal,
    action == AgentCore::Action::"InsuranceAPI___approve_claim",
    resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/insurance-gw-a1b2c3d4e5"
)
when temporal {
    formerly within 5m AgentCore::Action::"InsuranceAPI___get_claim_status"::request{
        eventResource: resource
    }
};

最近需要成功的先決條件

目的：只有在狀態查詢在過去五分鐘內完成時，才允許核准，因此過時查詢會停止授予許可。

與上一個範例唯一的變更是::response取代 ::request，它是「嘗試過」和「成功」之間的差異。視窗長度會設定成功必須達到的新鮮程度；一旦通過，許可就會失效，直到先決條件再次執行為止。

permit (
    principal,
    action == AgentCore::Action::"InsuranceAPI___approve_claim",
    resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/insurance-gw-a1b2c3d4e5"
)
when temporal {
    formerly within 5m AgentCore::Action::"InsuranceAPI___get_claim_status"::response{
        eventResource: resource
    }
};

工作階段中的請求序列	決策
approve_claim 任何完成的查詢之前	拒絕
查詢完成，然後在approve_claim視窗中	允許
approve_claim 視窗經過之後	拒絕

限制動作執行的次數

目的：在工作階段的任何五分鐘延伸中最多允許三個支出。

count 會計算視窗中的相符事件，包括正在授權的請求，因此視窗中的第四個呼叫是第一個被拒絕的呼叫。exists (n: Long) 綁定器會擷取計數，讓n > 3篩選條件可以進行測試；彙總需要在 左側的括號==。與 的許可配對disburse_payment，以便允許最多呼叫限制。

forbid (
    principal,
    action == AgentCore::Action::"InsuranceAPI___disburse_payment",
    resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/insurance-gw-a1b2c3d4e5"
)
when temporal {
    exists (n: Long).
        (count for (t: Timepoint).
            where (formerly within 5m (AgentCore::Action::"InsuranceAPI___disburse_payment"::request{ eventResource: resource } && tp(t)))) == n
        && n > 3
};

重要

這不是安全控制。發起人提供工作階段 ID，以便他們可以透過啟動新的工作階段來重設計數。使用它來塑造合作工作階段內的行為，例如停止迴圈代理程式，而不是對控制自己的工作階段 ID 的發起人強制執行限制。如需詳細資訊，請參閱安全性考量。

限制執行中總數

目的：允許支出，直到五分鐘內總計達到 3，000.00，然後停止。

sum 會在比對事件中新增具名輸入欄位，包括目前的請求，因此會超過閾值的請求會遭到拒絕。使用 300000 美分的上限和 100000 的支出，允許前兩個，並拒絕第三個。

forbid (
    principal,
    action == AgentCore::Action::"InsuranceAPI___disburse_payment",
    resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/insurance-gw-a1b2c3d4e5"
)
when temporal {
    exists (total: Long).
        (sum amt for (amt: Long), (t: Timepoint).
            where (formerly within 5m (AgentCore::Action::"InsuranceAPI___disburse_payment"::request{ eventResource: resource, input.amountCents: amt } && tp(t)))) == total
        && total >= 300000
};

for (amt: Long), (t: Timepoint)需要兩個變數的網域 ： amt 是要加總的值並t區分時間點，因此相同數量的兩個支出會計算兩次，而不是重複資料刪除為一個。

注意

amountCents 是工具結構描述integer中的 ，也是讓此政策運作的原因。sum 彙總需要整數總和，而 的排序比較需要兩側total的整數，因此結構描述宣告為 的欄位number無法驅動像這樣的上限。如需這些範例相依的類型規則，請參閱使用這些範例之前。

讓每個核准適合一次使用

目的：每次核准允許一個支出。支付後， 需要新的核准。

當錨點在視窗內發生時，since運算子會保留它右邊的錨點，而且從那時起，它左邊的 條件會持續保留。在這裡讀取：核准在過去一個小時內完成，而且自此之後就沒有完成任何支出。核准後的第一個支出會用掉它。

permit (
    principal,
    action == AgentCore::Action::"InsuranceAPI___disburse_payment",
    resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/insurance-gw-a1b2c3d4e5"
)
when temporal {
    !AgentCore::Action::"InsuranceAPI___disburse_payment"::response{ eventResource: resource }
    since within 1h AgentCore::Action::"InsuranceAPI___approve_claim"::response{ eventResource: resource }
};

在否定端::response進行比對至關重要。授權的請求尚未產生回應，因此不會封鎖自己 – 符合 ::request 會使每個支出拒絕自己。

工作階段中的請求序列	決策
approve_claim，然後 disburse_payment	允許
disburse_payment 沒有新核准的秒數	拒絕
新的 approve_claim，然後 disburse_payment	允許

注意

response 事件會在通話完成後不久記錄。等待核准傳回，再發出支出，而不是傳回。如需詳細資訊，請參閱依先前回應排序動作。

強制冷卻

目的：防止相同的動作在完成後一分鐘內重複。

此條件是指其授權的相同動作。 ::response 是安全的原因：目前的請求尚無回應，因此不符合本身。使用 編寫::request，目前的請求將與其自己的事件相符，並且將永久禁止該動作。如需詳細資訊，請參閱自我參考條件包含目前的請求。

forbid (
    principal,
    action == AgentCore::Action::"InsuranceAPI___disburse_payment",
    resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/insurance-gw-a1b2c3d4e5"
)
when temporal {
    formerly within 1m AgentCore::Action::"InsuranceAPI___disburse_payment"::response{
        eventResource: resource
    }
};

需要尚未失效的先決條件

目的：在核准存在時允許支出，並在之後重新開啟宣告進行狀態檢閱時撤銷許可。

這與one-time-use具有相同的形狀，但否定動作與授權的動作不同，這會將「使用核准」轉換為「驗證核准」。授予 approve_claim和 的許可get_claim_status。

permit (
    principal,
    action == AgentCore::Action::"InsuranceAPI___disburse_payment",
    resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/insurance-gw-a1b2c3d4e5"
)
when temporal {
    !AgentCore::Action::"InsuranceAPI___get_claim_status"::response{ eventResource: resource }
    since within 5m AgentCore::Action::"InsuranceAPI___approve_claim"::response{ eventResource: resource }
};

工作階段中的請求序列	決策
disburse_payment 在任何核准之前	拒絕
approve_claim，然後 disburse_payment	允許
get_claim_status 發生，然後 disburse_payment	拒絕
新的 approve_claim，然後 disburse_payment	允許

需要動作鏈的順序

目的：需要查詢序列狀態，然後進行核准，然後進行分配。

每個連結一個政策，鏈會從其組成中出現。授予第一個動作的純許可，讓鏈結可以啟動。在先決條件完成之前，會拒絕嘗試不按順序執行的步驟。

// Link 1: approve only after a completed status lookup
permit (
    principal,
    action == AgentCore::Action::"InsuranceAPI___approve_claim",
    resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/insurance-gw-a1b2c3d4e5"
)
when temporal {
    formerly within 5m AgentCore::Action::"InsuranceAPI___get_claim_status"::response{ eventResource: resource }
};

// Link 2: disburse only after a completed approval
permit (
    principal,
    action == AgentCore::Action::"InsuranceAPI___disburse_payment",
    resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/insurance-gw-a1b2c3d4e5"
)
when temporal {
    formerly within 5m AgentCore::Action::"InsuranceAPI___approve_claim"::response{ eventResource: resource }
};

任何順序都需要兩個先決條件

目的：只有在狀態查詢和核准都已完成之後，才允許依任一順序進行支出。

加入 的兩個formerly條件&&需要兩者，而且兩個條件都不限制順序。這使用單一政策可能包含的三個暫時運算子中的兩個。

permit (
    principal,
    action == AgentCore::Action::"InsuranceAPI___disburse_payment",
    resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/insurance-gw-a1b2c3d4e5"
)
when temporal {
    formerly within 1h AgentCore::Action::"InsuranceAPI___get_claim_status"::response{ eventResource: resource }
    && formerly within 1h AgentCore::Action::"InsuranceAPI___approve_claim"::response{ eventResource: resource }
};

讓兩個動作互斥

目的：在兩分鐘內，允許支出或刪除宣告，但不能同時允許兩者。

排除需要兩個對稱政策，每個方向一個；一個政策forbid只會封鎖一個順序。比對::request表示只嘗試一個動作會封鎖另一個動作，無需等待它完成。

// Forbid deletion if a disbursement was requested within 2m
forbid (
    principal,
    action == AgentCore::Action::"InsuranceAPI___delete_claim",
    resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/insurance-gw-a1b2c3d4e5"
)
when temporal {
    formerly within 2m AgentCore::Action::"InsuranceAPI___disburse_payment"::request{ eventResource: resource }
};

// Forbid disbursement if a deletion was requested within 2m
forbid (
    principal,
    action == AgentCore::Action::"InsuranceAPI___disburse_payment",
    resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/insurance-gw-a1b2c3d4e5"
)
when temporal {
    formerly within 2m AgentCore::Action::"InsuranceAPI___delete_claim"::request{ eventResource: resource }
};

需要事件的閾值數量

目的：僅允許在至少兩次付款完成後刪除宣告。

input.claimId 與目前請求的宣告建立關聯會將計數範圍限定為該宣告，而不是計算工作階段中的每個支出。

permit (
    principal,
    action == AgentCore::Action::"InsuranceAPI___delete_claim",
    resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/insurance-gw-a1b2c3d4e5"
)
when temporal {
    exists (n: Long).
        (count for (t: Timepoint).
            where (formerly within 5m (AgentCore::Action::"InsuranceAPI___disburse_payment"::response{ eventResource: resource, input.claimId: context.input.claimId } && tp(t)))) == n
        && n >= 2
};

注意

count 計算事件，而不是不同的發起人。它無法表達「由兩個不同的人核准」，因為沒有任何東西會阻止一個委託人產生所有相符的事件。對於多方核准，請在政策外部關聯eventPrincipal或強制執行差異性。

在先前的拒絕之後封鎖動作

目的：在拒絕任何核准嘗試之後，停止工作階段進行分發。

error 事件會記錄遭拒絕或失敗的請求，政策對先前失敗的反應::error也是如此。將此與 的純許可配對，disburse_payment以便在正常情況下允許。

forbid (
    principal,
    action == AgentCore::Action::"InsuranceAPI___disburse_payment",
    resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/insurance-gw-a1b2c3d4e5"
)
when temporal {
    formerly within 3m AgentCore::Action::"InsuranceAPI___approve_claim"::error{
        eventResource: resource
    }
};

這是一個有用的遏制模式：探查其沒有被切斷敏感動作許可的代理程式，而不是被允許繼續嘗試。

結合時間、護欄和請求條件

目的：允許發起人提出宣告，前提是工作階段在過去 24 小時內少於三個申請，宣告描述沒有銀行詳細資訊，而且發起人不是受限制的角色。

這三種條件類型組成在一個政策中，每個子句都必須保留 permit才能套用。temporal 區塊會強制執行上限、when區塊畫面內容，而unless區塊會排除角色。每個 都會獨立評估。

permit (
    principal is AgentCore::OAuthUser,
    action == AgentCore::Action::"InsuranceAPI___file_claim",
    resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/insurance-gw-a1b2c3d4e5"
)
when temporal {
    exists (n: Long).
        (count for (t: Timepoint).
            where (formerly within 24h (AgentCore::Action::"InsuranceAPI___file_claim"::request{ eventResource: resource } && tp(t)))) == n
        && n <= 3
}
when {
    BedrockGuardrails::SensitiveInformation(["US_BANK_ACCOUNT_NUMBER"], [context.input.description]).count() == 0
}
unless {
    principal.hasTag("role") &&
    principal.getTag("role") == "restricted"
};

護欄畫面 description，這是唯一file_claim採用的任意文字參數。將敏感資訊防護機制指向可能合理攜帶您正在篩選之資料的欄位。如果您將其指向識別符或數字，則它沒有可偵測的項目，且子句以無提示方式傳遞。 description是選用的，因此省略的請求不會為護欄提供文字，且子句會保留。

編輯時間政策時有何變更

在引擎上新增或更新暫時政策會使該引擎的開放暫時工作階段失效，因為記錄的歷史記錄不再符合要套用到它的規則。使用 HTTP 409 重複使用失效工作階段的下一個請求會失敗ConflictException。啟動新的工作階段並重試；新的工作階段會從空白歷史記錄開始，並根據更新的政策進行評估。

重要

當您推出暫時政策變更時，請對此進行規劃。用戶端必須將 409 視為「開始新的工作階段」。任何進行中的多步驟工作流程都會重新啟動，而不是繼續。