本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
临时政策
Amazon Bedrock 中的策略 AgentCore 支持临时策略：其决策取决于代理在会话中的操作历史记录，而不仅仅取决于当前请求。有了它们，您可以强制执行跨多个操作的规则，例如在操作之前要求获得批准，限制操作在一个时间范围内运行的次数，或者将运行总数保持在阈值以下。
临时策略是包含一个permit或多个时间运算符的或forbid规则。每个条件都匹配按其操作、主体以及操作的输入或输出字段为会话记录的先前事件，并且仅考虑所需时间窗口内的事件。条件可以将匹配的事件与当前请求相关联，因此，例如，规则可以要求当前请求对先前操作已批准的资源执行操作。策略引擎记录每个会话的事件并在每个请求上评估这些条件，因此您可以将会话感知规则表示为策略，而不是在代理或工具代码中跟踪事件。
临时政策是用 Dogwood 编写的，它与 Cedar 兼容，并支持 Cedar 的所有现有政策。标准 Cedar 政策是无状态的，仅考虑当前的请求。临时策略遵循相同的默认拒绝模式：只有在permit应用请求且不forbid覆盖请求时，才允许请求。时间条件不同于基于时间的条件，后者根据挂钟时间 (context.system.now) 而不是会话历史记录来限制访问。您还可以在LOG_ONLY模式下运行临时策略，以观察它在将其提升到之前会做出的决定ENFORCE；请参阅策略实施模式。
有关涵盖每种模式的时间策略的更多信息，请参阅策略编写指南中的临时策略示例。
重要概念
临时策略建立在两件事之上：Dogwood 策略语言，它表示会话感知规则，以及策略会话，它界定了规则可以看到的历史的范围。
Dogwood 政策语言
临时策略是用 Dogwood 编写的，这是一种用于会话感知授权的开源策略语言，即授权决策会考虑先前的事件，而不仅仅是当前的请求。Dogwood 扩展了 Cedar 的授权模式，增加了有状态的、会话感知的条件和其他政策信息提供者，例如 Amazon Bedrock Guardrails。您对委托人、操作permit和forbid资源进行撰写和统治。只有当 a permit 适用且不forbid覆盖请求时，才允许请求。您以 Dogwood 或 Cedar 撰写的现有时间点政策将继续有效，无需更改。只有在规则必须考虑超过当前请求的情况下，才可以添加临时条件。
使用 Dogwood，您可以将会话感知规则声明为策略，而不是在代理或工具代码中实现事件跟踪逻辑。策略引擎记录相关事件并评估每个请求的条件。例如，以下政策仅允许在前一小时内收到同一索赔的批准后才支付款项：
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, input.claimId: context.input.claimId, output.approved: true } };
Dogwood 为常见模式提供了时间运算符：formerly within（窗口中较早发生的匹配事件）、since within（自锚事件以来条件一直存在）以及聚合count和sum窗口中匹配的事件。
有关完整的时间语法，请参阅 Dogwood Policy 网站上的 Dogwood 语言指南
策略会话和会话 ID
临时策略根据策略会话进行评估：在一个会话 ID 下分组的一系列相关网关调用。时态历史的范围限于会话，因此条件仅考虑为被授权的请求在同一会话中记录的事件。您生成会话 ID 并在x-amzn-bedrock-agentcore-policy-session-id标头中的每个请求中发送该会话 ID，从您的第一个请求开始。网关不会代表您生成会话 ID。如果您省略标头或发送空值，则网关不会建立会话。如果关联的策略引擎包含临时策略，则没有会话 ID 的请求会因验证错误而失败。
有关传递会话 ID、会话生命周期以及身份如何在多跳呼叫之间传播的详细信息，请参阅策略会话和身份传播。
会话失效
临时策略通过查看同一会话早些时候发生的事情来决定是否允许采取行动。这段历史只有与会话开始时生效的临时政策相比才有意义。如果您在会话打开时更改引擎的临时策略，则记录的历史记录将不再与当前规则匹配，因此服务会结束会话，而不是针对不一致的数据做出决定。
在引擎上添加或更新临时策略会使引擎的活动临时策略会话失效。进行此类更改后，重用失效会话的下一个请求将失败，并显示 HTTP 409。ConflictException
要恢复，请启动新会话并重新发送请求。新会话以空白的历史记录开始，并根据您更新的政策进行评估。
支持 Amazon Regions
临时政策适用于下表中标记的 Amazon 区域。
| 区域名称 | 临时政策 |
|---|---|
|
亚太地区（海得拉巴） |
否 |
|
亚太地区（马来西亚） |
否 |
|
亚太地区（孟买） |
✓ 是的 |
|
亚太地区（首尔） |
✓ 是的 |
|
亚太地区（新加坡） |
✓ 是的 |
|
亚太地区（悉尼） |
✓ 是的 |
|
亚太地区（泰国） |
否 |
|
亚太地区（东京） |
✓ 是的 |
|
加拿大（中部） |
✓ 是的 |
|
欧洲地区（法兰克福） |
✓ 是的 |
|
欧洲地区（爱尔兰） |
✓ 是的 |
|
欧洲地区（伦敦） |
✓ 是的 |
|
欧洲地区（米兰） |
否 |
|
欧洲地区（巴黎） |
✓ 是的 |
|
欧洲（西班牙） |
✓ 是的 |
|
欧洲地区（斯德哥尔摩） |
✓ 是的 |
|
南美洲（圣保罗） |
✓ 是的 |
|
美国东部（弗吉尼亚州北部） |
✓ 是的 |
|
美国东部（俄亥俄州） |
✓ 是的 |
|
美国西部（北加利福尼亚） |
否 |
|
美国西部（俄勒冈州） |
✓ 是的 |
注意事项
Cross-account 和跨区域请求
临时策略会话不支持跨区域或跨账户传播。当 AgentCore 网关与其运行时目标位于不同的账户或不同 Amazon 区域时，临时策略不控制这些资源之间的请求。为了使临时策略能够控制代理的操作，网关及其所有目标必须位于同一个 Amazon 账户和 Amazon 区域中。
只有当工作负载访问令牌 (WAT) 通过请求链传输时，临时策略才会强制执行访问权限（请参阅策略会话和身份传播）。当您的请求链完全由 AgentCore Gateway 和 Runtime 组件组成时，会自动将 WAT 标头从一跳 AgentCore传播到下一跳。这种传播发生在单个 Amazon 区域和账户内。临时政策适用于整个链条。诸如 Gateway to Runtime 到 Gateway 到 Gateway to Runtime 之类的链可以端到端地携带代币，而
包含非 Gateway 或 Runtime 组件的链的行为方式不同。请求可能会通过您自己运营的基础设施，例如第三方 API 网关或 Kubernetes 集群。该组件必须转发 WAT 标头，并且您必须添加自定义逻辑才能通过这些跳点传播 WAT。这些非AgentCore 组成部分的实际位置不影响区域和账户范围。它们可以在任何地方运行，前提是两边的 AgentCore 组件都返回到适用临时政策的同一 Amazon 账户和 Amazon 区域。
所需的 IAM 权限
临时策略还带有 IAM 先决条件。为网关配置的 IAM 角色必须允许该bedrock-agentcore:GetWorkloadAccessToken操作。即使您使用 IAM 进行出站授权，此要求仍然有效。WAT 允许临时策略关联代理在会话中的操作。无论您如何验证出站呼叫，网关都必须能够获取 WAT。如果角色缺少此权限，则临时策略实施将失败。配置临时策略时授予bedrock-agentcore:GetWorkloadAccessToken网关角色。有关完整的权限策略，包括资源 ARN 和工作负载身份目录范围，请参阅临时策略的 IAM 权限。
Self-referential 条件包括当前请求
当时间条件引用正在授权的相同操作时，当前请求自身的事件将包含在评估中。例如，计算窗口内某项操作发生次数的条件也会计算当前的调用。
必须允许将先前的操作记录为回应
会话历史记录将每个操作记录为事件，其种类反映了结果：允许完成的操作记录为response事件，策略拒绝的操作记录为error事件。时间条件仅匹配其命名的事件，因此，与response事件匹配的条件仅考虑先前允许的操作。确保临时策略所依赖的先前操作本身为策略所允许；如果该操作被拒绝，则将其记录为error而不是response，并且response条件永远不会与之匹配。
对依赖先前响应的操作进行排序
操作完成后，会话历史记录会记录每个操作response的事件。当策略依赖于先前操作在同一会话中的响应（例如输出字段或since条件）时，请在收到先前操作的响应后发出相关请求。在启动依赖该操作的操作之前完成每个操作，可以使您的工作流程顺序与策略评估的历史记录保持一致。
配额
以下配额适用于临时策略：
| 配额 | 值 |
|---|---|
|
每个策略引擎的临时策略 |
20 |
|
每个策略的临时运算符 |
3 |
|
每个时间条件的最大时间窗口 |
24 小时 |
可观测性
Amazon Bedrock AgentCore 发布的指标和跨度数据可让您观察临时政策评估。默认情况下，指标会发布到AWS/Bedrock-AgentCore CloudWatch 命名空间。为附加的 Gate AgentCore way 资源启用跟踪后，Span 数据就会变为可用，并且可以在 CloudWatch aws/spans日志组中找到。
以下信号特定于临时策略：
-
TemporalLatency（指标）：评估临时策略所花费的时间，以毫秒为单位。每次时间评估都会生成一个样本，因此您可以使用SampleCount统计数据来计算评估次数。 -
aws.agentcore.policy.temporal.latency_ms（span 属性）：评估请求的时间策略所花费的时间，以毫秒为单位。 -
aws.agentcore.policy.temporal.evaluation_invoked（span 属性）：是否为请求运行时间评估。这并不表示临时政策匹配或决定了该决定。 -
aws.agentcore.policy.temporal.event_timestamp_ns（span 属性）：评估者用来对请求事件进行排序的确切事件时间戳，以纳秒为单位。
有关策略指标、维度和跨度属性的完整列表，请参阅AgentCore 生成的策略可观察性数据。该页面还说明了如何启用可观察性。
安全注意事项
使用临时策略的速率限制适用于单个会话。由于时间历史记录的范围仅限于会话，并且会话 ID 由调用者提供，因此 “每个会话最多 N 个呼叫” 之类的count基于限制仅计算该会话中记录的事件。启动新会话会开始新的计数，因此临时速率限制会限制会话内的活动，而不是所有来电者会话中的活动。