使用策略与 Lambda 拦截器在 Amazon Bedrock AgentCore 网关中保护 AI 代理

标题：使用策略和 Lambda 拦截器在 Amazon Bedrock AgentCore 网关中保护 AI 代理 | Amazon Web Services

来源链接：https://aws.amazon.com/blogs/machine-learning/secure-ai-agents-with-policy-and-lambda-interceptors-in-amazon-bedrock-agentcore-gateway/

发布时间：2026-06-01T09:54:22-08:00

Markdown 内容： 在构建代理式解决方案时，确保 AI 代理的行为安全是客户面临的关键挑战。随着企业迅速采用 AI 代理自动化工作流，他们面临着跨组织管理工具安全访问的扩展性难题。现代统一的企业级 AI 平台通常包含数百个代理，服务于整个组织的用户。这些代理需要访问跨越不同团队、部门和业务单元的数千个模型上下文协议（MCP）工具。此类平台的规模带来了一个根本性的治理问题。传统应用程序执行的是固定逻辑，而由大型语言模型（LLM）驱动的代理则在运行时动态决定调用哪些工具、使用哪些参数以及调用顺序。由于这种工作流的动态特性，提前审计调用图变得困难。您必须为 LLM 构建机制，使其行为符合您的预期。

您可以使用 Amazon Bedrock AgentCore 网关 通过两种互补机制来保护代理和工具：Amazon Bedrock AgentCore 中的策略 用于确定性访问控制，以及 AgentCore 网关拦截器 用于动态验证。Amazon Bedrock AgentCore 中的策略允许您对附加到网关的工具定义策略。策略使用 Cedar 编写——一种声明式策略语言，它根据 _主体_、_操作_ 和 _资源_ 对每个请求进行评估，并可选地基于请求上下文添加条件。结果是一个确定性的允许或拒绝决策，并自动记录在审计日志中。Lambda 拦截器允许您定义在每次工具调用前后运行的自定义代码，支持动态验证、负载增强、令牌交换和响应过滤。您可以结合这两种机制，为您的代理式解决方案构建分层安全架构。

在本文中，我们使用一个湖仓数据代理演示如何使用策略实现确定性访问控制，以及使用 Lambda 拦截器实现动态验证。随后，我们将展示如何结合 Lambda 拦截器与策略，实现基于地理位置的访问控制——这既需要动态验证，也需要确定性访问控制。

前提条件

在实施本方案前，您需要：

• 一个 AWS 账户。
• 访问 GitHub 仓库。
• AWS 身份与访问管理 (IAM) 权限，以设置 前提条件。

解决方案概览

湖仓数据代理是一款 AI 助手，允许保险公司员工查询理赔数据。数据存储在 Amazon S3 表（Apache Iceberg）中，并通过 Amazon Athena 和 AWS Lake Formation 进行查询。应用中存在三种用户角色：保单持有人（仅可查看自己的理赔）、理赔员（管理分配给自己的理赔）和管理员（拥有完整数据访问权限，包括审计日志）。Streamlit 用户界面通过 Amazon Cognito 对用户进行身份验证，并将 JSON Web Token (JWT) 传递给代理。

MCP 服务器暴露了五个工具：query_claims、get_claim_details、get_claims_summary、query_login_audit 和 text_to_sql。角色到工具的访问权限、租户 IAM 角色映射以及用户 geography 信息均存储在 Amazon DynamoDB 中。AWS Lake Formation 在查询时强制执行行级和列级安全控制。在此场景下，即使代理构造了一个宽泛的 SQL 查询，其结果也会自动限制为调用者 IAM 角色所允许查看的内容。

下图展示了湖仓数据代理的架构：

用户通过 Streamlit UI 访问湖仓代理，Amazon Cognito 对其进行身份验证并颁发持有者令牌。AgentCore Runtime 托管湖仓代理，验证这些令牌，并为每位用户建立隔离会话。当代理调用工具时，AgentCore Gateway 通过 Lambda 拦截器路由请求。拦截器提取持有者令牌，通过租户角色映射验证工具访问权限，并生成包含租户范围声明的令牌。AgentCore 策略引擎在允许访问前，根据预定义策略评估每次工具调用。随后，湖仓 MCP 服务器使用作用域凭证查询数据。AWS Lake Formation 根据用户表和声明表强制执行行级和列级安全策略，确保每位用户仅能查看其被授权访问的数据。AgentCore 可观测性和会话日志流式传输至 Amazon CloudWatch，用于实时监控和合规审计。

请求流程

下图展示了工具调用在此解决方案中的流转路径：

当湖仓代理通过 AgentCore Gateway 发起工具调用时，请求会被 Request Interceptor Lambda 函数拦截。该拦截器将请求中的持有者令牌替换为租户作用域凭证，并注入额外上下文。随后，策略引擎基于 Cedar 策略评估转换后的请求。转换后的请求用于通过湖仓 MCP 服务器调用工具。响应随后由 Response Interceptor Lambda 函数评估，该函数在响应返回给用户前过滤工具列表。

网关在 Cedar 策略之前评估请求拦截器。此顺序是设计模式的核心，即先使用拦截器丰富请求上下文，再使用策略评估该丰富后的上下文。

AgentCore Gateway 中的策略执行

Amazon Bedrock AgentCore 中的策略使用 Cedar 策略语言，在网关层强制执行确定性、可审计的访问控制。Cedar 策略以 permit 或 forbid 规则形式表达，针对主体、操作和资源进行评估，并可根据操作上下文设置条件。

当授权规则可通过身份属性、操作标识符和请求上下文的逻辑条件表达时，我们使用 Cedar 策略实现细粒度访问控制。典型应用场景包括限制特定角色可调用的工具，或阻止某些用户组访问敏感操作。Cedar 还可根据拦截器注入的上下文属性强制执行数据驻留规则，并支持在请求到达下游服务前于网关层实施作用域检查或时间窗口限制。

设计 1：仅策略

首先，我们来看一个策略作为湖仓代理安全层的示例。假设业务决定保单持有人不应能够调用 get_claims_summary。保单持有人可以查看自己的个人理赔记录，但汇总摘要仅限理赔员和管理员访问。为此，您可以将策略引擎附加到网关，并定义两个协同工作的 Cedar 策略：一条基础 permit 规则和一条定向 forbid 规则。

当策略引擎附加到网关时，它遵循“默认拒绝”语义：若无策略明确允许请求，则予以拒绝。因此，您首先需要一条基础 permit 策略，允许代理在网关上调用工具：

permit(
    principal,
    action,
    resource == AgentCore::Gateway::"<gateway_arn>"
);

仅凭此策略，所有经过身份验证的用户均可调用任意工具。

接下来，添加一条 forbid 规则，对保单持有人施加特定限制。由于 Cedar 中 forbid 规则优先于 permit 规则，这条单一规则足以阻止目标工具调用，同时保留其他所有访问权限。

forbid(
    principal is AgentCore::OAuthUser,
    action == AgentCore::Action::"lakehouse-mcp-target___get_claims_summary",
    resource == AgentCore::Gateway::"<gateway_arn>"
) when {
    principal.hasTag("cognito:groups") &&
    principal.getTag("cognito:groups") like "*policyholders*"
};

这两条策略结合使用，允许代理调用任何工具，唯独禁止保单持有人访问理赔汇总信息。

注意：最佳实践是初始将策略引擎的策略执行模式设为 LOG_ONLY。所有策略决策均写入 CloudWatch，但不会阻断任何请求。这使您能够在切换至 ENFORCE 模式前验证每条策略规则的行为是否符合预期。

下图展示了仅策略模式下的工具调用流程：

当湖仓代理发送传入请求时，AgentCore 网关首先使用内置授权机制验证 JWT 令牌。随后，策略引擎根据附加的 Cedar 策略组合评估该请求。在本例中，Cedar 策略采用“禁止-允许”模式：首先禁止 OAuth 用户访问 get_claims_summary 工具，然后仅当主体具有匹配 policyholders 的 Cognito 组标签时才允许访问。这种确定性的策略评估确保只有属于授权组的用户才能调用特定工具。根据策略评估结果，网关要么允许调用湖仓 MCP 服务器并将原始响应返回给代理，要么在请求到达工具前拒绝该请求。

设计 1 的策略评估结果

用户 | 工具 | 预期结果 | 决策归属 --- | --- | --- | --- policyholder001 | query_claims | 允许 | 策略：允许匹配 policyholder001 | get_claim_details | 允许 | 策略：允许匹配 policyholder001 | get_claims_summary | 拒绝 | 策略：禁止覆盖 adjuster001 | get_claims_summary | 允许 | 策略：无禁止匹配

基于策略的强制执行优势

Cedar 策略为保护 AI 代理提供了三大关键优势：

• 确定性：无论 LLM 行为如何，相同的输入始终产生相同的决策。
• 可审计性：一旦为网关启用 CloudWatch 日志投递，每次允许或拒绝决策都会记录完整上下文，提供完整的审计追踪。
• 低延迟：Cedar 评估对请求处理引入的开销极小。

用于动态控制的拦截器

拦截器是自定义 Lambda 函数，AgentCore 网关在请求生命周期的两个阶段调用它们。REQUEST 拦截器在请求到达下游工具前运行，RESPONSE 拦截器在响应返回给代理前运行。网关将每个拦截器传递一个包含原始请求头和正文的 JSON 事件（位于 mcp 键下）。拦截器转换请求内容并以相同结构返回。拦截器支持所有网关目标类型，包括 Lambda 函数、OpenAPI 端点和 MCP 服务器。有关完整负载契约和详细操作指南，请参阅 此文章。

当代理代表用户调用工具时，一个关键的安全决策是如何在调用链中传播身份。冒充方法是将原始用户 JWT 不加修改地传递给每个下游服务。这种方法更简单，但也允许下游服务获得超出其所需权限的权限。若服务被攻破，攻击者可将过度授权的令牌复用于其他地方（即 混淆代理问题）。另一种替代方案是“代为操作”，其中每个下游目标接收一个独立的、最小权限的令牌，该令牌专门针对该服务进行范围限定。用户的身份上下文仍会流经系统以便审计。设计 2 实现了这一模式。REQUEST 拦截器通过 sts:AssumeRole 将用户的 Cognito JWT 交换为短期、租户范围的 IAM 凭证，这些范围受限的凭证最终送达 MCP 服务器。

设计 2：仅拦截器 —— 代为操作的令牌交换与上下文传播

以下三项操作发生在 REQUEST 拦截器中，而 Cedar 无法完成：

• JWT 到 IAM 令牌交换（代为操作）：从 JWT 中读取用户的 Cognito 组，查找 DynamoDB 中对应的租户 IAM 角色，并调用 sts:AssumeRole 获取短期范围凭证。
• 上下文注入：将用户身份和临时 IAM 凭证写入 MCP 请求体中的 params.arguments.context，以便 MCP 服务器可据此构建范围受限的 Athena 客户端。
• 工具授权：在转发请求前检查 DynamoDB 中的 allowed_tools，对未授权调用返回结构化 MCP 错误。

REQUEST 拦截器处理函数（简化版）：

def lambda_handler(event, context):
    # 从拦截器事件中解析 MCP 网关请求
    mcp_data = event.get('mcp', {})
    gateway_request = mcp_data.get('gatewayRequest', {})
    body = gateway_request.get('body', {})
    headers = gateway_request.get('headers', {})

    token = extract_bearer_token(headers)
    claims = validate_and_decode_jwt(token)  # 步骤 1：验证 Cognito JWT

    # 步骤 2：根据 DynamoDB allowed_tools 检查工具授权
    is_authorized, error_msg, tool_name = validate_tool_access(claims, body)
    if not is_authorized:
        return build_mcp_error_response(error_msg, status_code=403)

    # 步骤 3：代为操作 —— 用 JWT 组声明交换租户 IAM 凭证
    claim_name, claim_value = get_claim_for_exchange(claims)
    tenant_credentials = exchange_jwt_to_iam(claim_name, claim_value)  # sts:AssumeRole

    # 步骤 4：将用户身份和范围凭证注入 MCP 请求体
    if 'params' in body and 'arguments' in body['params']:
        body['params']['arguments']['context'] = {
            'user_id': user_principal,
            'tenant_credentials': {
                'access_key_id': tenant_credentials['AccessKeyId'],
                'secret_access_key': tenant_credentials['SecretAccessKey'],
                'session_token': tenant_credentials['SessionToken'],
            }
        }

    # 以所需拦截器输出格式返回转换后的请求
    return {
        'interceptorOutputVersion': '1.0',
        'mcp': {
            'transformedGatewayRequest': {
                'headers': transformed_headers,
                'body': body,
            }
        }
    }

Python

MCP 服务器接收到注入上下文的转换后请求。每个工具函数接受一个 context 参数，并使用它来构建一个作用域限定的 Athena 客户端。Lake Formation 随后在查询时根据租户角色的权限自动应用行级和列级过滤器，无需 SQL WHERE 子句：

# server.py --- query_claims 工具
def query_claims(claim_status=None, context=None):
    user_id, tenant_creds = get_user_id_with_fallback(context)

    # Athena 客户端使用租户的作用域限定 IAM 凭证（而非用户的 JWT）
    # Lake Formation 自动应用行级和列级过滤器
    athena_client = boto3.client(
        'athena',
        aws_access_key_id=tenant_creds['access_key_id'],
        aws_secret_access_key=tenant_creds['secret_access_key'],
        aws_session_token=tenant_creds['session_token']
    )
    ...

Python

仅使用拦截器模式的调用流程

下图展示了仅使用拦截器模式的调用流程：

当 lakehouse 代理发送传入请求时，AgentCore 网关验证 JWT 令牌，并将原始请求作为带有 mcp 键的 JSON 事件路由至网关请求拦截器 Lambda。该拦截器通过将 Cognito JWT 交换为租户作用域凭证并验证工具授权来转换请求。随后，网关使用注入了上下文和租户凭证的转换后请求调用 lakehouse MCP 服务器。当 MCP 服务器返回原始响应时，网关响应拦截器会在返回代理前对其进行处理。该拦截器根据用户权限动态过滤工具列表并脱敏敏感信息，确保每位用户只能看到其被授权访问的工具和数据。

使用响应拦截器进行动态工具过滤

响应拦截器还允许您控制代理在工具响应后所看到的内容。最常见的用途是过滤工具列表和语义搜索响应，以仅向每位用户展示其被允许调用的工具。您还可以集成如 Amazon Bedrock Guardrails 等服务，用于个人身份信息 (PII) 脱敏等场景。这通过隐藏未授权工具并防止 PII 等敏感信息泄露来提升安全性；同时，通过为 LLM 提供更小、范围正确的工具列表，减少错误的工具选择决策，从而提高可靠性。

何时使用策略对比 Lambda 拦截器

策略与拦截器不可互换，它们在安全架构中承担不同职责。下表总结了关键决策标准。

考量因素 | 使用策略 | 使用 Lambda 拦截器 ---|---|--- 规则性质 | 基于已知属性的确定性逻辑条件 | 需要外部数据或运行时计算 外部查找（DynamoDB、STS、API） | 不支持 | 完全访问 负载转换 | 不支持 | 对头部和正文具有完全读写权限 响应修改 | 不支持 | RESPONSE 拦截器 延迟影响 | 可忽略（<1 毫秒，基于 Cedar 评估） | Lambda 冷启动 + 执行时间 可审计性 | 每次决策自动记录 CloudWatch 日志 | Lambda 日志（需手动埋点） 紧急阻断 | 通过 API 添加 forbid 规则，立即生效 | 需重新部署 Lambda 规则变更速度 | 高：API 调用，无需重新部署 | 低：代码更改 + 重新部署 评估顺序 | 在 REQUEST 拦截器之后 | 在 Cedar 策略之前 令牌交换 / 凭证分发 | 不支持 | 完全 STS 和密钥访问 语义搜索过滤 | 不支持 | RESPONSE 拦截器

建议使用策略的情况：

• 您需要一个无法被代理或 LLM 绕过的硬性、可审计边界。
• 授权规则仅依赖身份声明、操作名称、资源 ARN 或请求中已存在的上下文。
• 您需要紧急关闭开关。forbid 规则可通过控制平面 API 立即生效。

建议使用拦截器的情况：

• 规则需要在运行时获取的数据（如 DynamoDB、密钥、外部授权服务）。
• 您需要在请求到达工具前转换或丰富请求负载。
• 您需要在响应返回代理前过滤或净化工具响应。
• 授权决策是有状态的 —— 例如令牌交换或按用户限流。
• 您需要在方法级别（如 tools/call 对比 tools/list）而非工具级别强制执行授权。

设计目标是可组合性。对于所有本质上动态的部分，请使用拦截器；对于所有能表达为增强上下文中逻辑规则的部分，请使用 Cedar。由于 REQUEST 拦截器在 Cedar 之前运行，这两种机制形成自然流水线，而非争夺相同职责。

结合策略与 Lambda 拦截器

当策略与拦截器协同工作时，每一层负责其最擅长的部分。下图展示了结合策略与 Lambda 拦截器的分层安全架构下的调用流程：

在此模式中，当湖仓代理发送传入请求时，AgentCore 网关验证 JWT 令牌，并将原始请求路由至网关请求拦截器 Lambda。该拦截器通过动态注入 geography、user_id 和租户凭证来丰富请求内容。随后，策略引擎基于此增强上下文执行确定性的 Cedar 策略评估，提供一致的访问决策。若允许，网关使用注入了租户凭证的转换后请求调用湖仓 MCP 服务器。当 MCP 服务器返回原始响应时，网关响应拦截器根据用户权限动态过滤工具列表并脱敏敏感信息，再将转换后的响应返回给代理。

评估顺序为：先执行 REQUEST 拦截器，再执行 Cedar 策略。通过这种组合，您可以利用拦截器从任意数据源获取数据并注入请求参数，再使用 Cedar 策略对已增强的请求进行评估。我们将在下一个设计模式中再次看到这一点。

设计 3：策略 + 拦截器 — 基于地理位置的访问控制

此模式解决了一个合规性需求示例：我们希望创建一个边界，使来自欧盟司法管辖区的用户无法访问单个理赔记录，仅能访问聚合摘要。这是一个数据驻留规则，它结合了动态属性（存储在 DynamoDB 中的用户 geography）和确定性策略规则（欧盟用户不得调用 query_claims 或 get_claim_details）。

Cedar 无法从 DynamoDB 获取 geography。Lambda 拦截器无法表达带有自动审计日志的声明式 forbid 语义。策略与 Lambda 拦截器的组合通过使用 Lambda 拦截器获取 geography 并丰富请求来处理两者。策略随后使用此增强请求，根据用户 geography 评估单个理赔记录，再将请求传递给目标。

#### 步骤 1：拦截器获取地理位置并注入工具参数

# interceptor-request/lambda_function.py

# 生产环境：从 DynamoDB 表 'lakehouse_user_geography' 获取地理位置
# 本演示为简化起见，使用 Lambda 内部映射
USER_GEOGRAPHY: Dict[str, str] = {
    'policyholder001@example.com': 'US',
    'policyholder002@example.com': 'EU',
    'adjuster001@example.com': 'US',
    'admin@example.com': 'US',
}

# 在现有上下文注入后，将地理位置注入到参数的顶层。
# Cedar 将其评估为 context.input.geography。
# 若置于 context 内部（params.arguments.context.geography），
# Cedar 需要使用 context.input.context.geography —— 更难清晰表达。
geography = USER_GEOGRAPHY.get(user_principal, 'UNKNOWN')
if 'params' in transformed_body and 'arguments' in transformed_body['params']:
    transformed_body['params']['arguments']['geography'] = geography

logger.info(f'为用户={user_principal} 注入地理位置={geography}')

Python

关键细节：Cedar 将工具参数引用为 context.input.<field>。Cedar 可以访问任何层级的字段，但将 geography 放置在 params.arguments 的顶层可使策略更简洁。这样可以直接引用为 context.input.geography，而非嵌套时更冗长的 context.input.context.geography。

#### 步骤 2：Cedar 策略评估注入的地理位置

// 欧盟用户不得访问单个理赔记录（GDPR 数据驻留要求）。
// 宽松的 permit_all 规则仍允许欧盟用户调用 get_claims_summary。
forbid(
    principal,
    action in [
        AgentCore::Action::"lakehouse-mcp-target___query_claims",
        AgentCore::Action::"lakehouse-mcp-target___get_claim_details"
    ],
    resource == AgentCore::Gateway::"<gateway_arn>"
) when {
    context.input has geography &&
    context.input.geography == "EU"
};

// 受限地理区域被禁止所有工具访问。
forbid(
    principal,
    action in [
        AgentCore::Action::"lakehouse-mcp-target___query_claims",
        AgentCore::Action::"lakehouse-mcp-target___get_claim_details",
        AgentCore::Action::"lakehouse-mcp-target___get_claims_summary",
        AgentCore::Action::"lakehouse-mcp-target___query_login_audit",
        AgentCore::Action::"lakehouse-mcp-target___text_to_sql"
    ],
    resource == AgentCore::Gateway::"<gateway_arn>"
) when {
    context.input has geography &&
    context.input.geography == "RESTRICTED"
};

所有三个 forbid 策略由同一 Cedar 策略引擎共同评估。若任一 forbid 规则匹配，无论是否存在匹配的 permit 规则，请求均被拒绝。

#### 组合设计的责任矩阵

控制项 | 由谁处理 | 为何使用此层 --- | --- | --- 用户认证（JWT） | Gateway JWT Authorizer | 内置功能，无需自定义代码 工具授权（组 → 工具） | Cedar 策略（forbid） | 声明式、可审计，无需重新部署 Lambda 代为操作的令牌交换 | Lambda 拦截器 | 需要调用 sts:AssumeRole —— Cedar 无法直接调用 API 上下文注入（user_id、凭证） | Lambda 拦截器 | 需要 DynamoDB 查询和请求体修改 地理位置查询与注入 | Lambda 拦截器 | 需要 DynamoDB 查询和请求体修改 基于地理位置的访问控制 | Cedar 策略（forbid） | 对注入属性的声明式规则，附带审计日志 工具列表过滤（UX） | RESPONSE 拦截器 | 需要修改响应体内容 行/列数据安全 | Lake Formation | 在 Gateway 层之下后端强制执行

设计 3 的策略评估结果

用户 | 地理位置 | 工具 | 预期结果 | 决策方 --- | --- | --- | --- | --- policyholder001 | US | query_claims | 允许 | 无匹配的 forbid 规则 policyholder002 | EU | query_claims | 拒绝 | Cedar：EU 地区禁止访问个人索赔 policyholder002 | EU | get_claims_summary | 拒绝 | Cedar：设计 1 中的 policyholder 禁止规则 adjuster001 | US | get_claims_summary | 允许 | 无匹配的 forbid 规则 adjuster002 | EU | get_claim_details | 拒绝 | Cedar：EU 地区禁止访问个人索赔 任意用户 | RESTRICTED | 任意工具 | 拒绝 | Cedar：RESTRICTED 地理位置禁止规则

端到端实现指南

如需亲自尝试本方案，请先克隆 Amazon Bedrock AgentCore 示例仓库，并进入 lakehouse-agent 目录：

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

Bash

然后按照该目录下的 README 文件中的设置和部署说明，配置您的 AWS 环境，并使用 CLI 脚本运行部署。

步骤 1：预部署（生成 cdk.json、分离拦截器、更新 Lambda）

为准备 CDK 部署，请运行 pre-deploy.sh 一次性完成以下步骤：

• 自动从 SSM Parameter Store 生成 cdk.json。
• 临时从 Gateway 分离拦截器。
• 更新并重新部署支持设计 3 的 Request Interceptor Lambda 函数。

cd 02-use-cases/lakehouse-agent/cdk
bash scripts/pre-deploy.sh

Bash

步骤 2：CDK 部署

使用 CDK 创建策略引擎、创建四个 Cedar 策略，并将策略引擎和拦截器附加到 AgentCore Gateway。

# 安装 npm 依赖
npm ci
# 引导 AWS 账户（每个账户和区域仅需一次）
# npx cdk boostrap
npx cdk deploy --require-approval never --profile <YOUR_PROFILE>

Bash

步骤 3：通过测试请求验证

使用 policyholder002（geography=EU）的凭据调用代理，确认 query_claims 因 EU geography 禁止规则返回 403。接着验证 get_claims_summary 同样返回 403，被设计 1 的 policyholder 保护机制捕获。再使用 policyholder001（geography=US）进行测试，确认 query_claims 成功执行并仅返回该用户自己的索赔（由 AWS Lake Formation 强制执行）。

可观测性：贯穿整个管道的端到端可追溯性

AgentCore Gateway 与 AgentCore Observability 和 Amazon CloudWatch 集成，提供跨所有强制执行层的可追溯性。每一层都会留下独立且可查询的追踪记录。Gateway JWT 授权器会记录每个请求的令牌验证结果。REQUEST 拦截器 Lambda 函数会记录 JWT 声明提取、DynamoDB 查询结果、令牌交换结果以及 geography 注入情况。策略引擎会记录完整的授权上下文及每次评估的 ALLOW 或 DENY 决策。RESPONSE 拦截器 Lambda 函数会记录哪些工具从 tools/list 和语义搜索响应中被过滤，从而保留每个用户的工具可见性记录。

下一步

所有三种设计的示例代码均可在 GitHub 仓库 中找到。建议从设计模式 1 中演示的策略规则开始，随着安全与合规需求的增长，逐步构建设计 2 和设计 3。

清理

我们建议您清理不再计划继续使用的资源，以避免意外费用。请参考 相关说明 在探索完解决方案后进行清理。

总结

本文中，我们展示了三种设计模式，用于结合策略、Lambda 拦截器或两者组合来构建安全代理。当授权规则是确定性的、且可通过身份和上下文表达时，请使用策略；当规则需要外部数据、请求体转换或令牌交换时，请使用 Lambda 拦截器；当您需要在运行时获取动态上下文并对其进行声明式规则强制执行时，请结合两者使用。您可以利用这些模式，在构建智能代理解决方案时保障其行为安全。

• * *

关于作者