使用 Amazon Bedrock AgentCore 中的策略保护 AI 代理-青云TOP-AI综合资源站平台|青云聚合API大模型调用平台|全网AI资源导航平台

📢 转载信息

原文链接：https://aws.amazon.com/blogs/machine-learning/secure-ai-agents-with-policy-in-amazon-bedrock-agentcore/

原文作者：Bharathi Srinivasan, Anil Nadiminti, and Pushpinder Dua

在受监管的行业中安全地部署 AI 代理是一项挑战。如果没有适当的界限，访问敏感数据或执行事务的代理可能会带来重大的安全风险。与传统软件不同，AI 代理通过调用工具、访问数据并利用其环境和用户的数据来适应其推理，从而选择操作以实现目标。这种自主性正是代理如此强大的原因，也是安全成为一项不可或缺的关注点的原因。

将代理安全与外部世界隔离是一个有用的心智模型。要做到这一点，可以想象在代理周围设置墙壁，定义代理可以访问什么、它可以与之交互什么以及它对外部世界可能产生什么影响。没有明确定义的边界，能够发送电子邮件、查询数据库、执行代码或触发金融交易的代理是存在风险的。这些功能可能导致数据泄露、意外访问代码或基础设施，或提示注入攻击。如何才能在不减缓创新的情况下，可靠地、大规模地执行 AI 安全？Amazon Bedrock AgentCore 中的策略（Policy）提供了一种原则性的方法，可以在运行时、大规模地执行这些边界。

策略通过拦截网关上的所有流量并应用确定性规则，为代理提供安全层

在本文中，我们使用一个医疗预约调度代理来理解 Amazon Bedrock AgentCore 中的策略如何创建一个独立于代理自身推理的确定性执行层。医疗保健是探索的天然合适领域。在此领域运行的代理必须处理敏感的患者数据，遵守严格的访问边界，并一致地执行业务规则。这需要确定性的策略执行来维护患者数据的安全性和安全的运行时操作。完整的示例可在 GitHub 上找到，地址为 amazon-bedrock-agentcore-samples。

您将学习如何将业务规则的自然语言描述转化为 Cedar 策略，然后使用这些策略来执行细粒度的、与身份相关的控制，以便代理只能访问其用户授权使用的工具和数据。您还将看到如何通过 AgentCore Gateway 应用策略，在运行时拦截和评估每一次代理到工具的请求。

缺失的一环：为什么代理需要外部策略执行

保护 AI 代理比保护传统软件更难。使代理强大的因素，例如开放式推理、灵活的工具使用和对新情况的适应性，也可能导致难以安全控制的不可预测行为。代理依赖于大型语言模型 (LLM) 推理，LLM 可能会产生幻觉，并且在受信任的指令和无关文本之间没有内置的硬性分隔。这使得代理容易受到提示注入和相关的对抗性攻击，这些攻击利用 LLM 的弱点来绕过安全措施并破坏预期行为。这些风险通常通过在代码中限制代理来管理。这可以奏效，但会带来微妙的成本。代理的行为现在只与其包装代码的正确性一样安全，而该包装代码现在是一个隐式的安全边界。推断策略是否完整需要仔细审查可能庞大的代码库。当安全团队需要审计是否已到位正确的规则时，他们会阅读应用程序代码，而不是清晰、可审计的策略定义。Amazon Bedrock AgentCore 中的策略采取了不同的方法：将策略完全移出代理。现在，策略在代理通过 AgentCore Gateway 调用工具之前执行。因此，无论代理做什么、如何被提示或操纵，以及代理代码中存在什么错误，策略都会被执行。有了这种分离，您就可以专注于能力，而无需将每一行工具调用代码都视为潜在的安全边界。

Cedar：确定性策略执行的语言

与将规则嵌入代理代码不同，外部策略执行提供了可审计的安全边界，并将能力开发与安全问题分开。要使这种确定性的外部执行实用化，您需要一种既机器高效又人类可审计的策略语言。Amazon Bedrock AgentCore 中的策略使用的 Cedar 语言提供了这一缺失的环节，它将安全意图转化为精确、可分析的策略。

Cedar 是 AgentCore 策略中使用的授权语言，因为它被设计为一种实用的授权语言，也是自动化数学分析的目标。每个策略指定一个主体 (principal)、一个操作 (action) 和一个资源 (resource)，并在 when 子句中包含条件。以下示例显示了如何只允许 Alice 查看度假照片：

permit( principal == User::"alice", action == Action::"view", resource == Photo::"VacationPhoto94.jpg");

除了主体、资源和操作上的属性之外，您还可以使用 Cedar 来传递一个上下文对象，其属性（例如 readOnly）可以在策略中引用，以根据运行时信息来条件化决策。以下示例显示了如何创建允许用户 alice 执行只读操作的策略：

permit( principal == PhotoFlash::User::"alice", action, resource) when { context has readOnly &amp;&amp; context.readOnly == true };

Cedar 的语义，包括默认拒绝、禁止优先于允许以及独立于顺序的评估，使得组合推理策略变得简单。由于其有限的无循环结构，评估延迟也很小。Cedar 策略没有副作用，如文件系统访问、系统调用或网络通信。因此，即使是由不受信任的作者编写的，也可以安全地评估它们，而无需进行沙箱处理。

Amazon Bedrock AgentCore 中的策略

基于对确定性、外部执行的需求，Amazon Bedrock AgentCore 中的策略提供了具体的机制，根据明确定义的 Cedar 策略评估每一次代理到工具的请求。策略引擎是一组用 Cedar 表示的策略。为了方便策略编写，可以通过两种方式创建策略：直接以 Cedar 形式编写以进行细粒度的编程控制，或从自然语言语句生成，这些语句会自动形式化为 Cedar。从自然语言开始，该服务会生成语法正确的 Cedar 代码，根据网关架构对其进行验证，并对其进行分析，以便在强制执行之前发现过于宽松、过于严格或存在其他问题的策略。定义后，AgentCore 中的策略会通过 Amazon Bedrock AgentCore Gateway 拦截代理流量，在授予或拒绝工具访问之前，根据策略引擎中的策略评估每一次代理到工具的请求。

将策略应用于医疗预约调度代理

为了使这些概念具体化，让我们逐步了解如何将 Amazon Bedrock AgentCore 中的策略应用于医疗预约调度代理。这是一个 AI 系统，用于查询当前的免疫接种状态/时间表、检查预约时间段并预订预约。我们希望使用策略来保护 AI 系统，以帮助防止对患者记录的未经授权访问、对受保护健康信息 (PHI) 的意外泄露，或患者取消其他患者的预约。

由 Amazon Bedrock AgentCore 中的策略保护的医疗预约调度代理的架构

Amazon Bedrock AgentCore 中的策略具有默认拒绝模式，并且禁止优先于允许默认拒绝模式，并且禁止会自动优先于允许。结合这些原则，我们展示了如何从一组可读、可审计的 Cedar 规则组合策略，以提高 AI 代理在生产环境中的安全性。

入门

要亲自尝试此示例，请先克隆 Amazon Bedrock AgentCore 示例存储库，然后导航到医疗预约代理文件夹：

git clone https://github.com/awslabs/amazon-bedrock-agentcore-samples.git
cd amazon-bedrock-agentcore-samples/02-use-cases/healthcare-appointment-agent

从那里，按照此目录中 README 中的设置和部署说明来配置您的 AWS 环境，部署示例堆栈，并端到端地调用代理。

先决条件

要在您的代理应用程序中使用 Amazon Bedrock AgentCore 中的策略，请验证您是否已满足以下先决条件：

一个活动的 AWS 账户
确认 Policy in AgentCore 可用的 AWS 区域可用
创建、测试和将策略引擎附加到您的 AgentCore Gateway 所需的 IAM 权限。（注意：IAM 策略应细粒度，并使用正确的 ARN 模式限制为必要的资源以供生产使用）：

[ {
    "Sid": "PolicyEngineManagement",
    "Effect": "Allow",
    "Action": [
        "bedrock-agentcore:CreatePolicyEngine",
        "bedrock-agentcore:UpdatePolicyEngine",
        "bedrock-agentcore:GetPolicyEngine",
        "bedrock-agentcore:DeletePolicyEngine",
        "bedrock-agentcore:ListPolicyEngines"
    ],
    "Resource": "arn:aws:bedrock-agentcore:${aws:region}:${aws:accountId}:policy-engine/*"
}, {
    "Sid": "CedarPolicyManagement",
    "Effect": "Allow",
    "Action": [
        "bedrock-agentcore:CreatePolicy",
        "bedrock-agentcore:GetPolicy",
        "bedrock-agentcore:ListPolicies",
        "bedrock-agentcore:UpdatePolicy",
        "bedrock-agentcore:DeletePolicy"
    ],
    "Resource": "arn:aws:bedrock-agentcore:${aws:region}:${aws:accountId}:policy-engine/*/policy/*"
}, {
    "Sid": "NaturalLanguagePolicyGeneration",
    "Effect": "Allow",
    "Action": [
        "bedrock-agentcore:StartPolicyGeneration",
        "bedrock-agentcore:GetPolicyGeneration",
        "bedrock-agentcore:ListPolicyGenerations",
        "bedrock-agentcore:ListPolicyGenerationAssets"
    ],
    "Resource": "arn:aws:bedrock-agentcore:${aws:region}:${aws:accountId}:policy-engine/*/policy-generation/*"
}, {
    "Sid": "AttachPolicyEngineToGateway",
    "Effect": "Allow",
    "Action": [
        "bedrock-agentcore:UpdateGateway",
        "bedrock-agentcore:GetGateway",
        "bedrock-agentcore:ManageResourceScopedPolicy",
        "bedrock-agentcore:ManageAdminPolicy"
    ],
    "Resource": "arn:aws:bedrock-agentcore:${aws:region}:${aws:accountId}:gateway/*"
} ]

替换 <region> 和 <account-id> 为您的值。对于生产环境，请将资源 ARN 限制为特定的策略引擎和网关 ID，而不是使用通配符。有关包括网关执行角色配置在内的完整权限集，请参阅 AgentCore Gateway 和策略 IAM 权限。

策略实施步骤

首先，创建一个策略引擎，用于存放我们将为医疗预约调度代理创建的所需策略。
有三种不同的选项可以编写策略。您可以从自然语言规则生成 Cedar 语句，使用基于表单的方法创建 Cedar 策略，或直接提供 Cedar 语句。在下一节中，我们将介绍一些涵盖这些编写选项的示例。
最后，可以将策略引擎与网关关联。这可以在 LOG_ONLY 模式下完成，以验证策略如何为您的代理工作，而不会中断生产流量。这是通过观察可观察性日志中记录的行为来完成的。当您确信代理的行为符合预期时，可以将策略引擎以强制模式与网关关联。

将策略引擎与 AgentCore Gateway 关联

医疗预约代理具有以下工具：

getPatient: GET /get_patient_emr — 使用必需的查询参数 patient_id (string) 获取患者记录。
searchImmunization: POST /search_immunization_emr — 使用必需的参数 search_value (string; patient ID) 搜索免疫接种记录。
bookAppointment: POST /book_appointment — 通过提供 date_string (string; “YYYY-MM-DD HH:MM”) 来预订预约。
getSlots: GET /get_available_slots — 使用必需的查询参数 date_string (string; “YYYY-MM-DD”) 获取可用时间段。

现在，让我们为该代理编写一些策略来保护代理如何访问这些工具！

基于身份的策略

医疗代理中的基本规则是患者只能操作自己的记录。我们希望创建一个策略，允许患者读取自己的患者/免疫接种记录。对于每个工具，您可以声明工具参数（对于 getPatient 工具是 patient_id，对于 searchImmunization 工具是 search_value）必须与用户的已认证 ID 匹配。在下面的图片中，我们向您展示了如何通过使用自然语言语句来编写这些策略，并生成相应的 Cedar 策略。

使用 NL2Cedar 创建基于身份的策略的控制台视图

读写分离

医疗系统中的常见模式是允许广泛的读取访问，同时严格限制写入操作。此代理的一个示例策略是仅允许经过身份验证的用户使用适当的作用域（例如，fhir:read）进行读取，并将写入操作单独控制。在下图的基于表单的策略创建方法中，您可以选择效果、主体、资源、操作，并提供条件来创建策略。该图像显示了创建策略的过程，该策略允许用户访问医疗应用程序网关中的工具，前提是主体包含 fhir:read 在主体作用域中。

基于表单的策略创建的控制台视图

就像这个作用域读访问的策略一样，您现在可以使用主体作用域中的作用域 appointment:write 来控制写访问。

调度风险控制

除了访问控制之外，策略还可以执行业务规则或危险模式，以帮助防止滥用。通过使用显式的禁止来硬性阻止工具的危险输入模式，即使代理被泄露，您也可以保护您的应用程序。例如，让我们创建一个策略来阻止在限制时间之外显示预约时间段。在下图中，您可以看到自然语言语句“只允许用户在 UTC 时间上午 9 点到晚上 9 点之间获取时间段”被转换为 Cedar 策略。

用于滥用控制的策略

现在，您可以为您的用例构建更多策略，并创建一套连贯的策略集，以建立完整的安全态势。策略引擎的评估模型是默认拒绝的：如果没有允许策略匹配请求，则该请求将被阻止。对常见的低风险操作使用广泛的允许规则。为高风险工具、敏感数据边界和已知滥用途径添加有针对性的禁止规则。这种分层方法可以帮助您创建一个策略集，该策略集既可供安全审计员阅读，又可在运行时强制执行，并且独立于代理的 LLM 推理所产生的内容。在这里，代理不需要“知道”这些规则。它不需要被提示去遵守它们，也不需要经过微调来遵循它们，或者在对抗性条件下被信任来正确应用它们。Amazon Bedrock AgentCore 中的策略在网关处执行这些规则，在工具调用执行之前，无论代理如何得出其决策。

测试策略执行

现在让我们了解我们为医疗预约调度代理创建并与网关关联的策略的行为。以下两个测试用例演示了在代理代表用户调用 getPatient 工具时，基于身份的作用域访问策略如何生效。在这两种情况下，已认证的用户都是患者 adult-patient-001。正在测试的 Cedar 策略是患者只读访问规则。此规则仅当请求中的 patient_id 与已认证用户的 patient_id 声明匹配时，才允许 getPatient 工具调用：

permit( principal, action == AgentCore::Action::"Target1___getPatient", resource == AgentCore::Gateway::"{gateway_arn}") when {
    principal.hasTag("role") && principal.getTag("role") == "patient" &&
    context.input has patient_id &&
    principal.hasTag("patient_id") &&
    context.input.patient_id == principal.getTag("patient_id")
};

测试 1a — 允许：患者访问自己的记录

代理向网关发送一个 tools/call 请求，以调用 getPatient，并将 patient_id 的工具参数设置为 adult-patient-001。由于工具输入中的 patient_id 与已认证用户的 patient_id 声明匹配，因此 Cedar 策略允许该请求：

提示：“获取我的患者信息，患者 ID 为 adult-patient-001”

策略决策：允许

结果：成功返回患者记录

测试 1b — 拒绝：患者访问其他患者的记录

现在代理发送相同的 tools/call 请求来获取 getPatient，并将 patient_id 设置为 pediatric-patient-001。Cedar 策略将工具输入与已认证用户的 patient_id 声明进行比较，发现不匹配，并拒绝请求，因为没有匹配的允许策略。

提示：“获取患者 ID 为 pediatric-patient-001 的患者信息”

策略决策：拒绝

结果：工具执行被策略强制执行拒绝

这两种情况都使用了相同的代理代码、相同的模型和相同的工具。唯一的区别是网关边界处的策略评估。由于网关在工具执行前拦截了被拒绝的请求，因此该工具免受该请求的影响。以下示例演示了另一种强制模式：一个 forbid 规则，用于阻止在允许时间之外进行调度操作。之前的“调度风险控制”部分使用自然语言生成了一个 permit 规则，该规则允许在上午 9 点到晚上 9 点之间访问时间段。相同的约束可以表示为 forbid，用于明确阻止在该窗口之外的请求。两种方法都产生相同的强制结果；我们使用 forbid 形式来说明 Cedar 的“禁止总是优先”语义如何硬性阻止危险模式：

forbid( principal, action == AgentCore::Action::"Target1___getSlots", resource == AgentCore::Gateway::"{gateway_arn}") when {
    context.input has date_string &amp;&amp; (context.time.hour &lt; 9 || context.time.hour &gt; 21)
};

测试 2a — 允许：在允许的时间内请求时间段

代理请求在诊所营业时间（例如，UTC 下午 2 点）内的可用时间段。此策略的 when 子句不匹配，因为请求的小时数落在 9-21 范围内，因此请求会继续执行相应的 permit 策略并成功。

提示：“显示 2025-08-15 的可用预约时间段”（下午 14:00 UTC 请求）

策略决策：允许

结果：成功返回请求日期的可用时间段

测试 2b — 拒绝：在允许时间之外请求时间段

代理发出相同的请求，但在 UTC凌晨 3 点。forbid 规则匹配，因为请求的小时数小于九，并且由于 Cedar 中的禁止优先于允许，因此无论其他允许策略如何，该请求都会被阻止。

提示：“显示 2025-08-15 的可用预约时间段”（UTC 凌晨 03:00 请求）

策略决策：拒绝

结果：工具执行被策略强制执行拒绝

这些测试用例共同说明了两种强制模式：带有身份作用域条件的 permit 和带有时间限制的 forbid。这就是外部策略执行之所以成为确定性的原因。结果取决于策略定义和请求上下文，而不是代理的推理。

清理资源

为避免持续产生费用，请删除 Amazon Bedrock AgentCore 策略，移除测试代理，并使用提供的 CDK 销毁命令和策略清理脚本清理所有相关资源。要运行清理脚本：

python policy/setup_policy.py --cleanup

结论

AI 代理的可靠性取决于其边界的强度。这些边界必须确定性地执行。Amazon Bedrock AgentCore 中的策略提供了一种原则性的方法来定义这些边界，并在网关层对每一次代理到工具的请求强制执行它们。这些策略独立于代理的推理进行强制执行，并且可以由您安全团队中的任何人进行审计。对于在受监管行业部署代理的企业来说，能力与执行的分离是使生产级代理系统成为可能的基础。在本系列文章的下一篇中，我们将深入探讨 Lambda 拦截器和 AgentCore Gateway 中的策略之间的关键区别，并介绍如何单独以及一起使用它们来构建健壮的、受管的代理应用程序的架构模式。

后续步骤

准备好为自己的代理添加确定性策略执行功能了吗？以下资源将帮助您快速上手：

策略开发人员指南涵盖了 Cedar 策略编写、自然语言到 Cedar 的形式化、AWS KMS 加密以及用于基础设施即代码 (IaC) 部署的 CDK 构造。
AgentCore 入门工作坊将引导您完成端到端代理的构建和保护，包括将策略与 AgentCore Gateway 集成。

对在特定用例中实现这些策略有疑问吗？请在此帖子的评论中分享您的想法，或在 AWS 论坛中与社区联系。

致谢

特别感谢所有为发布做出贡献的人：由 Pushpinder Dua、Raja Kapur、Sean Eichenberger、Jean-Baptiste Tristan、Sandesh Swamy、Maira Ladeira Tanke、Tanvi Girinath 和 Amanda Lester 领导的团队。

关于作者

🚀 想要体验更好更全面的AI调用？

欢迎使用青云聚合API，约为官网价格的十分之一，支持300+全球最新模型，以及全球各种生图生视频模型，无需翻墙高速稳定，文档丰富，小白也可以简单操作。

目录CONTENT

使用 Amazon Bedrock AgentCore 中的策略保护 AI 代理