给 AI Agent 上锁：在 Amazon Bedrock AgentCore 中组合策略与 Lambda 拦截器

当 AI Agent 手里握着数据库查询、API 调用等工具时，不加限制的执行权限无异于把删库跑路的钥匙交给了大模型。Amazon Bedrock AgentCore 网关提供了两道防线来收紧 Agent 的动作边界：Policy（策略）负责确定性访问控制，Lambda interceptors（Lambda 拦截器）负责动态校验。本文以一个 Lakehouse 数据查询 Agent 为例，拆解这两道防线怎么各司其职，又如何组合打出基于地理位置的精细化权限管控。

确定性防线：用 Policy 锁死工具与资源边界

Policy 是静态的、确定性的规则。它最适合处理那些不随请求上下文变化的硬性约束：某个 Agent 能调用哪些工具、能访问哪些数据源、禁止执行什么操作。

在 Lakehouse 数据 Agent 的场景里，最底线的安全需求是：Agent 可以查询数据，但绝对不能删表。通过 AgentCore 网关的 Policy 配置，这种约束在网关层就被硬性阻断，根本轮不到后端数据库去拒绝。

下面是一份典型的 Policy 定义，限制 Agent 只能调用 QueryData 动作，且资源范围限定在 analytics 库：

{
  "Version": "2024-06-01",
  "Statement": [
    {
      "Sid": "AllowQueryAnalytics",
      "Effect": "Allow",
      "Action": ["lakehouse:QueryData"],
      "Resource": ["arn:aws:lakehouse:us-east-1:123456789012:database/analytics"]
    },
    {
      "Sid": "DenyAllMutatingActions",
      "Effect": "Deny",
      "Action": ["lakehouse:DropTable", "lakehouse:DeleteRecords", "lakehouse:InsertRecords"],
      "Resource": ["*"]
    }
  ]
}

将这份 Policy 附加到 AgentCore 网关后，无论大模型幻觉出什么指令，网关都会像防火墙一样直接拦截违规调用。确定性规则执行速度快、逻辑透明，是权限管控的第一道铁门。

动态拦截：Lambda 拦截器处理上下文与实时校验

Policy 解决不了所有问题。当访问控制依赖请求的实时上下文——比如当前用户的身份、请求发出的地理位置、时间窗口、甚至查询语句里是否包含敏感字段——静态规则就力不从心了。Lambda 拦截器正是填补这一空白的动态防线。

拦截器会在 Agent 调用工具的前后触发，你可以注入一段 Lambda 逻辑来实时审查请求内容。在 Lakehouse Agent 的场景中，一个典型的动态需求是：防止 Agent 在查询中泄露特定分区的敏感客户数据（如 PII 字段），或者根据请求来源的 IP 判断是否允许访问。

下面是一个 Python Lambda 拦截器示例，它在工具调用前检查请求体，如果 SQL 查询涉及受限表，且请求 IP 不在白名单内，直接拒绝执行：

import json

def lambda_handler(event, context):
    # event 结构根据 Bedrock AgentCore 网关实际传入格式调整
    # 假设 event 包含 tool_request (含 SQL) 和 client_context (含 IP)

    tool_request = event.get('tool_request', {})
    client_context = event.get('client_context', {})
    query_sql = tool_request.get('parameters', {}).get('sql', '')
    source_ip = client_context.get('source_ip', '')

    ALLOWED_IP_RANGES = ['10.0.1.0/24', '203.0.113.0/24']  # 内部办公网段
    RESTRICTED_TABLES = ['customer_pii', 'financial_raw']

    # 检查 SQL 是否命中受限表
    contains_restricted = any(tbl in query_sql.lower() for tbl in RESTRICTED_TABLES)

    # 简单的 IP 白名单校验（生产环境建议用 CIDR 匹配库）
    is_ip_allowed = any(source_ip.startswith(allowed.split('/')[0][:9]) for allowed in ALLOWED_IP_RANGES)

    if contains_restricted and not is_ip_allowed:
        return {
            'action': 'DENY',
            'reason': f'Query contains restricted table and source IP {source_ip} is not in allowed range.',
            'modified_request': None
        }

    # 校验通过，放行原始请求，或注入额外参数（如强制加 WHERE 条件）
    return {
        'action': 'ALLOW',
        'reason': 'Dynamic validation passed.',
        'modified_request': tool_request  # 也可在此改写 SQL 强制加行级过滤
    }

将这段 Lambda 绑定到 AgentCore 网关的拦截器链后，每次 Agent 发起查询，网关都会先唤醒 Lambda 做实时体检。通过 DENY 动作阻断，或通过 modified_request 改写请求，实现了 Policy 无法覆盖的动态逻辑。

组合出击：基于地理位置的混合访问控制

单独使用 Policy 或 Lambda 都有盲区。Policy 无法判断请求从哪来，Lambda 无法像 Policy 那样零延迟地硬性切断整类操作。在原文的 Lakehouse Agent 场景中，两者组合实现了一套基于地理位置的访问控制：

1. Policy 先行：通过确定性规则，划定不同用户组的基础权限。比如，欧洲用户组的基础 Policy 允许访问 eu_analytics 库，亚太用户组允许访问 ap_analytics 库。这步在网关层瞬间完成，不产生额外延迟。
2. Lambda 拦截跟进：当请求通过了 Policy 的身份和资源范围校验后，Lambda 拦截器提取请求中的地理上下文（如基于用户 Token 解析出的国家代码，或请求 IP 的归属地），动态判断该次具体调用是否合规。比如，一个出差到美国的欧洲员工，虽然 Policy 层面有欧洲库的权限，但 Lambda 发现当前请求地理上下文不在欧洲，便动态拒绝。

这种组合把静态的粗粒度边界和动态的细粒度校验缝合在一起。配置这种组合管控，需要先定义基础 Policy，再通过 AWS CLI 将 Lambda 拦截器挂载到网关：

# 1. 将 Policy 附加到 AgentCore 网关
aws bedrock-agentcore attach-policy \
  --gateway-id my-lakehouse-gateway \
  --policy-document file://policy_allow_eu_analytics.json

# 2. 创建 Lambda 拦截器
aws lambda create-function \
  --function-name geo-check-interceptor \
  --runtime python3.12 \
  --handler lambda_handler.lambda_handler \
  --zip-file fileb://interceptor.zip \
  --role arn:aws:iam::123456789012:role/lambda-exec-role

# 3. 将拦截器绑定到网关的 Pre-Invoke 钩子
aws bedrock-agentcore attach-interceptor \
  --gateway-id my-lakehouse-gateway \
  --interceptor-type PRE_INVOKE \
  --lambda-arn arn:aws:lambda:us-east-1:123456789012:function:geo-check-interceptor

请求到达网关后的执行流变为：请求解析 → Policy 确定性校验 → Lambda 拦截器动态地理校验 → 工具执行。任何一环失败，调用即刻终止。

落地建议与权衡

给 Agent 上锁不是越紧越好，过度拦截会让 Agent 变得寸步难行。在落地 AgentCore 网关的安全管控时，建议遵循以下原则：

• 粗粒度用 Policy，细粒度用 Lambda。能用静态规则一刀切掉的权限（如禁止删库），绝不放到 Lambda 里增加冷启动延迟和执行成本。
• 拦截器保持轻量。Lambda 拦截器位于每次工具调用的关键路径上，逻辑必须精简。复杂的地理围栏校验或外部 API 调用会显著拖慢 Agent 响应，建议把需要的上下文（如用户角色、IP）在网关层提前注入 event，避免 Lambda 内部再做二次查询。
• 改写优于拒绝。对于不合规但意图合理的查询，Lambda 拦截器与其直接 DENY，不如通过 modified_request 注入强制过滤条件（如自动追加 WHERE region = 'EU'），让 Agent 依然能完成任务，只是边界被自动收窄。
• 分层测试。Policy 规则可以用单元测试直接验证 JSON 逻辑；Lambda 拦截器需要构造模拟 event 测试动态分支；组合场景务必做端到端集成测试，确保 Policy 的 Allow 不会被 Lambda 误杀，Policy 的 Deny 也不会被 Lambda 绕过。

AI Agent 的能力边界决定了它的安全边界。Bedrock AgentCore 把确定性策略和动态拦截器组合在同一网关内，让开发者既能拉起硬性铁网，又能根据上下文灵活收放。在把 Agent 推向生产环境之前，这两道防线值得作为标准配置接入。