用时序策略保护 Bedrock Agent

在 AI 智能体出现之前，访问控制通常只需将每个操作视为独立事件即可。应用程序依赖确定性的业务逻辑来确保操作是否按正确顺序执行，以及数据是否为最新状态。AI 智能体的行为方式与传统应用程序有着根本区别。它们会在运行时决定调用哪些工具、使用哪些参数，以及按什么顺序调用。这种灵活性与日益智能的模型相结合，使智能体既能力强大，又难以控制。孤立来看，某次工具调用可能被认为是安全的，但结合前一次调用的上下文来看却可能造成危害，例如此前刚从不可信的数据源读取了内容。于是，问题变成了：如何实施能够考虑智能体会话历史记录的授权规则，同时确保智能体无法规避这些规则？

Amazon Bedrock AgentCore 中的时序策略允许你定义有状态规则，通过结合智能体轨迹中的先前事件评估当前请求，确定是否授权访问 AgentCore Gateway 目标。由于这些策略运行在 AgentCore Gateway 的边界层，位于智能体自身代码之外，因此智能体无法拦截或操纵它们。

本文将介绍什么是时序策略、它们如何工作，并通过一个示例进行演示。我们将展示如何使用时序策略强制执行工作流顺序、防止工具调用之间的数据伪造、限制每个会话的累计财务风险敞口，以及要求高价值操作必须经过人工审批。你还将了解如何在智能体没有人工参与的情况下自动收紧权限。不过，我们首先会更详细地探讨有状态策略的需求和使用场景。

为什么智能体需要有状态的策略执行

AgentCore Policy 中现有的访问控制会针对每个请求执行无状态、确定性的规则：谁可以调用哪个工具，以及在什么条件下可以调用。无状态控制必不可少，但对于智能体来说往往并不足够。请考虑以下现有无状态控制无法发现关键问题的场景：

智能体调用 lookup_customer 工具，却幻觉出了一个与返回结果不同的账户编号，并将其传递给 transfer_funds 工具，导致资金被转入错误客户的账户。

一个失控的智能体在循环中执行了数十笔交易，因为没有任何机制跟踪累计风险敞口是否已经超过风险限额。

智能体在几秒钟内既批准又拒绝了同一笔保险理赔。

在这些场景中，每一次单独的工具调用都能通过无状态策略检查。只有查看智能体的轨迹，也就是一个会话中按顺序排列的操作序列时，问题才会显现出来。时序策略为 AgentCore 中的 Policy 扩展了这一轨迹感知的执行层。时序策略运行在网关中，位于智能体代码之外，因此无论智能体做了什么、收到了怎样的提示，或者智能体代码中存在什么缺陷，都无法绕过这些策略。常见的时序策略使用场景包括：

强制保证链式工具之间的输出完整性。要求传递给当前工具调用的参数与先前工具调用的输出完全匹配，防止智能体在步骤之间幻觉或替换值。

强制执行工具调用顺序。要求先调用某个工具，再调用另一个工具，以验证是否遵循标准操作程序（SOP）。

在执行特权操作前要求人工审批。在轨迹中记录明确的人工审批事件之前，阻止破坏性或敏感的工具调用。

强制保证数据时效性。要求在授权某个依赖操作之前，必须在指定时间范围内完成数据查询，以防止基于过时信息作出决策。

时序策略是一种授权控制，用于回答这样的问题：“根据 AgentCore Gateway 观察到的近期轨迹，这个特定请求是否获得授权？”它们根据当前请求和近期轨迹（即会话中的事件），评估是否应允许经由网关路由的请求。它们不会转换请求、调用工具、执行分析，也不会直接编排智能体。

时序策略作用于流经 AgentCore Gateway 的流量。由于 Gateway 会通过单一端点路由智能体的 Model Context Protocol（MCP）工具调用、智能体间调用和模型推理调用，因此，只要智能体通过网关发起这些调用，时序策略就可以对这三类调用实施管控。无论智能体发起的是哪种调用，这都提供了一个统一的位置，用于分析智能体随时间变化的行为。

时序策略的工作原理

时序策略构建在现有的策略引擎之上，该引擎已经用于无状态访问控制。它们引入了智能体轨迹这一概念，即由主体和会话 ID 标识的、有边界的操作序列。智能体永远看不到策略逻辑，无法接触状态存储，也不能更改这些控制。与现有的 AgentCore Policy 功能一样，时序策略默认拒绝，并且禁止规则优先于允许规则。

网关收到工具调用时，策略引擎会：

查询轨迹状态，获取与当前所评估策略相关的操作、输入和输出。

结合其历史范围（即客户定义的轨迹中的先前事件），针对当前请求评估每一条时序策略。

返回确定性的 ALLOW 或 DENY 决策，并记录该决策的完整上下文。

时序策略评估的每个请求都必须携带 x-amzn-bedrock-agentcore-policy-session-id 请求头，用于标识该请求所属的会话。你可以自行决定什么构成会话的开始和结束。会话边界可以对应任何适合应用程序的工作单元，无论是一次用户对话、一项多步骤任务，还是持续时间更长的工作流。由于每个会话最多只能同时处理一个授权请求，因此我们建议尽可能缩小会话的范围。如果未传递该请求头，系统会代为生成一个。但请注意，新的会话 ID 意味着策略引擎将基于一条没有任何历史记录的全新空轨迹进行评估。

会话绝不会仅由其 ID 定义。AgentCore 会将会话 ID 与最终用户的身份相结合，生成唯一会话。这意味着两个不同身份即使提供相同的会话 ID，仍会被视为拥有完全独立的会话。由于底层身份不同，策略会分别独立应用于每条轨迹。在活跃会话中，智能体轨迹的最大回溯窗口为 24 小时。早于该时间范围的所有轨迹事件都会被自动删除。会话与策略本身之间的关系还受到另一条规则约束：每当策略引擎中的策略发生变更时，现有会话都会失效。这可以确保每个会话都根据当前策略集进行评估，并且每个相关的轨迹事件都按照预期的 schema 记录。

将时序策略应用于私人银行投资组合智能体

为了让这些概念更加具体，我们将逐步介绍时序策略如何保护一个假想的私人银行智能体。该智能体帮助某金融服务公司的财富顾问管理客户投资组合。它会检索客户资料、加载投资组合持仓、获取实时市场价格、执行分析，并代表顾问执行交易。

在此场景中，以下 MCP 工具通过 AgentCore Gateway 对外提供：

顾问分为三种不同角色：初级顾问（交易权限有限）、高级顾问（拥有完整交易权限）以及合规官（仅拥有只读监控权限）。在本例中，我们将使用 Amazon Cognito 管理身份，并将 JWT 传递给托管智能体工具的 AgentCore Gateway，用于入站身份验证。要了解 AgentCore Gateway 以及如何为 Gateway 配置身份验证，请阅读 AgentCore Gateway 文档。时序策略使用 Dogwood，这是一种专为智能体及其工具设计的新型开源治理语言。Dogwood 支持评估现有 Cedar 策略，并支持时序条件。由于 Dogwood 与现有 Cedar 策略兼容，客户可以继续使用当前的 Cedar 策略，无需迁移。如需进一步了解 Dogwood 及其语义，可以阅读该语言的文档或相关博客文章。

合规团队要求智能体在投入生产之前满足以下时序控制要求：

智能体必须先拉取客户资料，然后加载投资组合，之后才能执行任何交易。

交易中使用的 portfolio_id 必须与 get_client_profile 的输出完全匹配。

必须在交易执行前 1 分钟内获取市场价格。

单个会话的交易总价值不得超过 60,000 美元。

任何一笔超过 25,000 美元的交易都需要顾问批准，每笔交易需要单独批准一次。

如果卖出会产生亏损，AI 智能体不能在同一轨迹中先买入再卖出同一证券。

如果顾问连续 15 分钟未进行交互，AI 智能体将失去写操作权限。

通过网关和策略的请求流程

图 1：通过 AgentCore Gateway 和 Policy 的请求流程

此图展示了发送到网关的请求如何被 AgentCore 中的 Policy 拦截和评估。当投资组合 AI 智能体发起工具调用时，会执行以下步骤：

请求到达 AgentCore Gateway。顾问已通过 AgentCore Identity 完成身份验证。请求中携带当前会话的轨迹 ID。

策略引擎检索该轨迹的累积状态。

每项时序策略都会根据这段历史记录评估当前请求。

如果所有策略均允许，请求将继续发送到 MCP 工具。如果任一策略禁止，请求将被拒绝，并记录拒绝事件。

执行成功后，该操作及其结果会追加到轨迹状态中，供后续评估使用。

实现时序策略

如果现有策略引擎处于 ENFORCE 模式，你可以将其强制执行模式更新为 LOG_ONLY，也可以更改单项策略的强制执行模式。不建议对生产工作负载将现有策略或策略引擎切换为 LOG_ONLY 模式，因为这些策略将不再强制执行相应的安全规则。

在实现此解决方案之前，请确认已满足以下先决条件：

• 拥有已启用 Amazon Bedrock AgentCore 的有效 AWS 账户。

• 拥有至少配置了一个 MCP 目标的 AgentCore Gateway。

• 已将策略引擎附加到网关。

• 拥有创建和管理策略资源所需的适当 Identity and Access Management（IAM）权限（请参阅文档）。

策略 1：工作流顺序（多跳链）

合规团队要求 AI 智能体依次执行 get_client_profile、load_portfolio 和 rebalance_portfolio。如果没有客户资料，AI 智能体就没有经过系统验证的上下文，无法确定哪些投资组合属于该客户、客户的风险承受能力如何，以及适用哪些账户限制。

permit (principal, action == AgentCore::Action::"FinTarget___load_portfolio", resource == AgentCore::Gateway::<GATEWAY_ARN>)
when temporal {
    formerly within 5m (AgentCore::Action::"FinTarget___get_client_profile"::response{eventResource: resource})
};

permit (principal, action == AgentCore::Action::"FinTarget___rebalance_portfolio", resource == AgentCore::Gateway::<GATEWAY_ARN>)
when temporal {
    formerly within 5m (AgentCore::Action::"FinTarget___load_portfolio"::response{eventResource: resource})
};

除非 get_client_profile 和 load_portfolio 都已在此轨迹中按正确顺序完成，否则此策略会禁止执行 rebalance_portfolio。无论 AI 智能体收到什么指令，只要它跳过加载资料的步骤，直接进行再平衡，请求就会被拒绝。

策略 2：输出到输入的完整性

传递给 execute_trade 的 portfolio_id 必须与 get_client_profile 返回的某个投资组合 ID 完全匹配。AI 智能体不能伪造或替换为其他投资组合 ID。

permit (
    principal,
    action == AgentCore::Action::"execute_trade",
    resource
)
when temporal {
    formerly within 24h (
        AgentCore::Action::"get_client_profile"::response{
            input.profile_id: context.input.profile_id,
            eventResource: resource
        }
    )
};

此策略可防止攻击者利用提示词注入，诱导 AI 智能体对其他客户的投资组合执行交易。攻击者可以说服 LLM 使用伪造的 ID，但该策略会将此值与 CRM 系统实际返回的值进行验证。

策略 3：数据新鲜度

在授权 execute_trade 之前，必须在最近 30 秒内成功完成一次 get_market_price 调用。AI 智能体不能根据过时的报价采取行动。

permit (
    principal,
    action == AgentCore::Action::"execute_trade",
    resource
)
when temporal {
    formerly within 30s (
        AgentCore::Action::"get_market_price"::response{eventResource: resource}
    )
};

在市场剧烈波动时，即使是 60 秒前的报价，也可能已经出现显著的价格偏移。此策略强制 AI 智能体在每笔交易前刷新市场数据，确保交易决策基于当前信息。

策略 4：每条轨迹的累计预算上限

单个策略会话（或轨迹）中的交易总额不能超过 60,000 美元。这可以控制失控 AI 智能体或成功攻击所造成的影响范围。

permit (
    principal,
    action == AgentCore::Action::"execute_trade",
    resource
)
when temporal {
    exists (total: Long). ((sum amount for (amount: Long), (t: Timepoint). where (formerly within 24h (
        AgentCore::Action::"get_market_price"::request{input.cost: amount, eventResource: resource} && tp(t)))) == total && total < 60000
    )
};

一个遭到入侵的 AI 智能体可能执行数十笔单独看来都没有问题的小额交易，但累计起来仍可能造成灾难性的风险敞口。达到 60,000 美元后，所有交易都会被拒绝，直到开始一条新轨迹。

策略 5：大额交易需人工批准（一次性消费）

任何超过 25,000 美元的交易都需要顾问明确批准。每次批准只能用于一笔交易。第二笔大额交易需要重新批准。

permit (
    principal,
    action == AgentCore::Action::"execute_trade",
    resource
)
when {
    context.input.cost < 25000 || temporal {
        !(
            AgentCore::Action::"execute_trade"::response{eventResource: resource}
        )
        since within 24h (
            AgentCore::Action::"approve_trade"::response{ input.status: "approved", eventResource: resource}
        )
    }
};

这可以防止 AI 智能体将单次批准解读为可执行多笔大额交易的概括性授权。每次批准仅涵盖一次交易执行。

策略 6：互斥

如果卖出会产生亏损，AI 智能体不能在同一轨迹中先买入再卖出同一证券。

permit (
    principal,
    action == AgentCore::Action::"execute_sell",
    resource
)
unless {
    context.input.profit < 0 && temporal {
        formerly within 24h (
            AgentCore::Action::"execute_buy"{
                stock_symbol: context.input.stock_symbol, eventResource: resource}
        )
    }
}
};

如果 AI 智能体两分钟前卖出了 AAPL，现在又试图买入 AAPL，请求将被拒绝。这种矛盾本身就是出现问题的信号，应对该会话进行审查。

策略 7：渐进式信任衰减

如果顾问连续 15 分钟未进行交互，AI 智能体将失去写操作（execute_trade、rebalance_portfolio）权限。顾问可以随时重新参与交互，以恢复完整权限。

permit (
    principal,
    action in [
        AgentCore::Action::"execute_trade",
        AgentCore::Action::"rebalance_portfolio"
    ],
    resource == AgentCore::Gateway::"<arn>"
)
unless temporal {
    formerly within 15m AgentCore::Action::"interact_advisor"::response{eventResource: resource}
};

如果顾问离开，AI 智能体将自然收敛为只读行为。这可以确保长时间的自主运行不会累积未经检查的风险。

你只需为 AI 智能体执行期间发起的授权请求付费。每当 AI 智能体通过 AgentCore Gateway 调用工具时，Policy 都会根据你的规则检查该操作，以确定是允许还是拒绝。每个策略引擎的前 100 项时序策略均包含在现有的单次授权请求价格中（详情请参阅 AgentCore 定价页面）。

为避免持续产生费用，请删除在本演练中创建的资源。请按以下顺序删除资源：首先从策略引擎中删除时序策略，然后解除策略引擎与网关的关联，最后删除策略引擎本身。如果策略引擎仍包含策略或仍附加到网关，则无法将其删除。如果网关及其 MCP 目标也是专门为本演练创建的，也请将它们删除。请注意，删除或更改策略会使所有活动的策略会话失效，因此请仅在测试会话完成后执行清理。

列出并删除策略引擎中的策略。对七项策略中的每一项重复执行 delete-policy 命令：

aws bedrock-agentcore-control list-policies $
  --policy-engine-id <POLICY_ENGINE_ID>

aws bedrock-agentcore-control delete-policy $
  --policy-engine-id <POLICY_ENGINE_ID> $
  --policy-id <POLICY_ID>

通过更新网关且不提供策略引擎配置，解除策略引擎与网关的关联：

aws bedrock-agentcore-control create-gateway $
  --name my-gateway $
  --role-arn arn:aws:iam::123456789012:role/my-gateway-service-role $
  --protocol-type MCP $
  --authorizer-type CUSTOM_JWT $
  --authorizer-configuration '{
    "customJWTAuthorizer": {
      "discoveryUrl": "https://cognito-idp.us-west-2.amazonaws.com/some-user-pool/.well-known/openid-configuration",
      "allowedClients": ["clientId"]
    }
  }'

删除策略引擎：

aws bedrock-agentcore-control delete-policy-engine $
  --policy-engine-id <POLICY_ENGINE_ID>

（可选）如果你为本演练创建了网关目标和网关，请将其删除：

aws bedrock-agentcore-control delete-gateway-target $
  --gateway-identifier <GATEWAY_ID> $
  --target-id <TARGET_ID>

aws bedrock-agentcore-control delete-gateway $
  --gateway-identifier <GATEWAY_ID>

本文介绍了时间策略如何为智能体式 AI 系统带来有状态、可感知执行轨迹的授权机制。你将七种策略模式应用到了一个假设的私人银行投资组合 AI 智能体中。这些模式涵盖工作流顺序控制、输出到输入的完整性、数据时效性、累计预算上限、人在回路审批、互斥以及渐进式信任衰减。这些模式可以推广到 AI 智能体在运行时与敏感工具交互的各种领域。由于执行发生在 AgentCore Gateway 边界，独立于 AI 智能体自身的推理循环，因此无论模型如何运行，这些保护机制都无法被篡改。这为你提供了一种声明式、可审计的方式来实施操作边界，同时不会限制 AI 智能体之所以有价值的灵活性。要开始使用，请查阅 AgentCore 文档。