使用 Bedrock AgentCore 网关拦截器实现细粒度访问控制

📢 转载信息

原文链接：https://aws.amazon.com/blogs/machine-learning/apply-fine-grained-access-control-with-bedrock-agentcore-gateway-interceptors/

原文作者：Dhawalkumar Patel, Bhuvan Annamreddi, Ganesh Thiyagarajan, Kevin Tsao, Avinash Kolluri, Mohammad Tahsin, and Ozan Deniz

随着企业快速采用AI代理来自动化工作流程和提高生产力，它们面临一个关键的扩展挑战：管理对组织中数千个工具的安全访问。现代AI部署不再涉及少数代理调用少量API，而是企业正在构建统一的AI平台，其中数百个代理、消费者AI应用程序和自动化工作流需要访问跨越不同团队、组织和业务部门的数千个模型上下文协议 (MCP) 工具。

这种规模的增加带来了基本的安全和治理问题：您如何确保每个调用主体——无论是AI代理、用户还是应用程序——只访问他们被授权使用的工具？您如何根据用户身份、代理上下文、请求访问的渠道以及不断发展的权限来动态过滤工具可用性？您如何在数据流经从代理到工具再到下游API的多跳工作流程时保护敏感数据？以及如何在不牺牲性能、不造成操作瓶颈或不强制团队为每个租户或用例部署单独的MCP服务器实例的情况下实现所有这些？

为解决这些挑战，我们正在推出一项新功能：Amazon Bedrock AgentCore Gateway 的网关拦截器。这项强大的新功能提供了细粒度的安全性、动态访问控制和灵活的Schema管理。

为工具访问提供细粒度访问控制

企业客户正在通过统一的AgentCore网关部署数千个MCP工具。这些客户使用这个单一的MCP网关来访问来自不同团队、组织、消费者AI应用程序和AI代理的工具，每个工具都为其分配给调用主体的访问权限。挑战在于根据调用主体的访问权限和上下文来保护MCP工具访问，并对AgentCore网关的ListTools、InvokeTool和Search调用做出响应。

工具过滤必须基于多个动态因素，包括代理身份、用户身份和执行上下文，其中权限可能根据用户上下文、用户访问代理的渠道、工作区访问级别以及其他上下文属性动态变化。这要求进行安全感知的过滤，其中权限更改会立即影响工具可用性，而不会缓存过时的权限状态。

下图提供了一个基于用户的工具过滤示例，并为网关如何在返回允许的工具之前评估身份和上下文设定了背景。

MCP和下游API之间的Schema转换和数据保护

客户在管理AI代理与下游API之间的契约时，同时需要维护安全性和灵活性，这带来了复杂的挑战。组织必须将MCP请求Schema动态映射到相应的下游API Schema，从而实现关键的数据保护功能，例如屏蔽或删除用户可能作为提示的一部分发送给代理的个人身份信息 (PII) 或敏感个人信息 (SPI)。当这些信息对于API调用不是必需的时，这可以防止敏感数据泄露到下游API。

此外，客户需要Schema转换功能来处理API合同变更，同时保持MCP Schema的完整性和与下游实现的解耦。这种解耦允许更平滑的API演进和版本控制，而不会破坏AI代理和工具契约，因此后端团队可以修改其API实现、更改字段名称、重构有效载荷或更新身份验证要求，而无需强制更改代理层或重新训练已学习特定工具Schema的AI模型。

多租户SaaS的租户隔离

提供代理即服务或工具即服务的组织面临复杂的多租户要求。客户必须为其所有用户部署MCP服务器，同时保持适当的租户隔离，这要求同时传递和验证租户ID和用户ID。多租户MCP服务器架构要求不同的客户和工作区保持完全隔离，工具访问严格基于租户边界控制。挑战在于确定是需要为每个租户部署单独的网关，还是单个网关可以安全地处理具有适当隔离保证的多租户场景。

动态工具过滤

客户需要能够适应不断变化的权限和用户上下文的实时、上下文感知的工具过滤。组织需要统一的MCP服务器，能够分两个阶段过滤工具：首先按代理权限和工作区上下文过滤，然后按语义搜索过滤——关键要求是由于权限随时可能更改，因此不应对动态过滤的工具列表进行缓存。

自定义Header传播和身份上下文管理

AI代理在行为上与传统微服务根本不同，因为它们是自主的和非确定性的。与通常依赖服务间信任和授权技术的传统微服务到微服务授权方法不同，AI代理需要代表最终用户执行工作流，并根据用户执行上下文访问下游工具、API和资源。然而，将原始授权令牌发送到下游服务会带来重大的安全漏洞，例如凭证被盗用、权限升级和“被混淆的副手”问题，即更具特权的**服务被欺骗以代表权限较低的攻击者执行操作**。

替代方案与事后授权方法

客户在身份上下文如何通过多跳工作流（代理到代理到工具到API）传播时面临一个基本的安全决策：是使用替代（impersonation）方法还是事后授权（act-on-behalf）方法。

使用替代方法时，原始用户的JWT令牌会未更改地通过调用链中的每个跳点传递。虽然实现起来更简单，但这种方法会带来重大的安全风险。由于以下风险，我们不推荐此方法：

• 下游服务接收到的令牌具有比必需权限更广泛的权限
• 如果任何组件受到攻击，权限升级的风险增加
• 令牌范围无法限制到特定的下游目标
• 容易受到“被混淆的副手”攻击，受损的服务可能会滥用过度授权的令牌

在事后授权方法中，工作流中的每个跳点都会收到一个单独的、针对该下游目标发行的范围受限令牌，并且JWT用于在整个过程中传播执行上下文。我们推荐此方法，因为它提供了以下好处：

• 最小权限原则 – 每个服务仅接收访问特定下游API所需的权限
• 减少影响范围 – 受损的令牌范围有限，不能在其他地方重用
• 更好的可审计性 – 清晰的保管链显示了哪个服务代表用户，使用了 AgentCore 可观测性
• 令牌范围限制 – 每个下游目标接收的令牌或凭证专门针对其API进行了范围界定
• 安全边界 – 在调用链中不同服务之间强制执行适当的隔离
• 防止被混淆的副手 – 范围受限的令牌和凭证可防止服务被欺骗执行未经授权的操作

事后授权模型要求网关从传入请求中提取执行上下文，为每个下游目标生成新的范围受限授权令牌，并在注入适当Header的同时维护用户的身份上下文以供审计和授权决策使用——所有这些操作都不会向下游服务暴露过度授权的凭证。这种安全方法确保AI代理可以代表用户执行工作流，同时在调用链的每个跳点维护严格的安全边界。

下图比较了替代方法与事后授权方法的流程。

在替代方法中（顶部），当用户 A 连接到代理时，代理将用户 A 的完整身份令牌及其全部范围（"order: read, promotions:write"）未作修改地传递给“订单工具”和“促销工具”，这意味着每个工具接收了超出其需要的权限。相比之下，事后授权方法（底部）显示代理为每个工具创建了单独的、范围受限的令牌——“订单工具”仅接收 "order: read" 范围，“促销工具”仅接收 "promotions:write" 范围，并且每个令牌都包含一个 "Act: Agent" 字段，这建立了清晰的责任链，表明代理正在代表用户 A 行事。这演示了委托如何通过将每个下游服务限制为其所需的特定权限来实施最小权限原则，从而降低安全风险并防止令牌被滥用。

AgentCore Gateway：AI代理的安全MCP集成

AgentCore Gateway 将您现有的API和AWS Lambda函数转换为代理兼容工具，连接到现有的MCP服务器，并提供与基本第三方业务工具和服务的无缝集成（例如 Jira、Asana 和 Zendesk）。这个统一的接入点支持跨企业系统的安全集成。借助 AgentCore Identity，代理可以使用 OAuth 标准进行适当的身份验证和授权，从而安全地访问和操作这些工具。

随着网关拦截器的推出，AgentCore Gateway 通过在两个关键点上使用自定义Lambda函数，帮助组织实施细粒度访问控制和凭证管理：

• 网关请求拦截器 – 请求拦截器Lambda函数在请求到达其目标工具之前处理传入请求，支持基于用户凭证、会话上下文和组织策略的细粒度访问控制、审计跟踪创建、Schema转换等。
• 网关响应拦截器 – 响应拦截器Lambda函数在响应返回调用代理之前处理传出响应，支持审计跟踪创建、工具过滤、Schema转换，以及对搜索和列表工具的细粒度访问控制。

下图说明了通过网关拦截器的请求-响应流程。

让我们检查自定义拦截器在请求-响应周期的每个阶段接收和必须返回的特定有效载荷结构。网关请求拦截器接收一个具有以下结构的事件：

{
  "interceptorInputVersion": "1.0",
  "mcp": {
    "gatewayRequest": {
        "headers": { "Authorization": "Bearer eyJhbG...", ... },
        "body": { "jsonrpc": "2.0", "method": "tools/list", ... }
    },
    "requestContext": { ... }
  }
}

您的网关请求拦截器Lambda函数必须返回一个具有transformedGatewayRequest字段的响应：

{
  "interceptorOutputVersion": "1.0",
  "mcp": {
    "transformedGatewayRequest": {  // <-- 此字段必须由您的代码添加
        "headers": { ... },
        "body": { ... }
    }
  }
}

目标服务响应后，将调用网关响应拦截器，其中包含原始请求和响应的事件：

{
  "interceptorInputVersion": "1.0",
  "mcp": {
    "gatewayRequest": { ... },
    "requestContext": { ... },
    "gatewayResponse": {  // <-- 此字段包含目标的响应
        "statusCode": 200,
        "headers": { ... },
        "body": {             "jsonrpc": "2.0",
            "result": { "tools": [ ... ] }
        }
    }
  }
}

您的网关响应拦截器Lambda函数必须返回一个具有transformedGatewayResponse字段的响应：

{
  "interceptorOutputVersion": "1.0",
  "mcp": {
    "transformedGatewayResponse": {  // <-- 此字段必须由您的代码添加
        "statusCode": 200,
        "headers": { ... },
        "body": { ... }
    }
  }
}

理解此请求-响应结构对于实现我们稍后在本文中探讨的自定义拦截器逻辑至关重要。网关拦截器为代理AI系统提供了安全和管理代理工作流的关键功能：

• Header管理 – 通过自定义Header传递身份验证令牌、关联ID和元数据
• 请求转换 – 在到达目标服务之前修改请求有效载荷、添加上下文或丰富数据
• 安全增强 – 实现自定义身份验证、授权和数据清理逻辑
• 细粒度访问控制 – 根据调用主体的访问权限和上下文安全地访问MCP工具，并对 AgentCore Gateway 的 ListTools、InvokeTool 和 Search 调用做出响应
• 多租户MCP工具的租户隔离 – 在多租户环境中，根据调用用户、代理和租户身份实现租户隔离和访问控制
• 可观测性 – 添加日志记录、指标和跟踪信息以监控代理工作流

网关拦截器适用于 AgentCore Gateway 的目标类型，包括 Lambda 函数、OpenAPI 端点和 MCP 服务器。

带有网关拦截器的用例

网关拦截器为代理AI系统带来了灵活的安全和访问控制模式。本文展示了三种方法：实现对调用工具的细粒度访问控制、基于用户权限的动态工具过滤，以及跨分布式系统的身份传播。

实现对调用工具的细粒度访问控制

AgentCore Gateway通过统一的MCP端点暴露多个后端工具。具有不同角色的用户需要不同的工具权限。您可以使用JWT范围结合网关拦截器来实现细粒度访问控制，以确保用户只能调用授权的工具，并且只能发现属于其角色或工作区的工具。细粒度访问控制使用 Amazon Cognito（或其他OAuth 2提供商）颁发的JWT范围值。您也可以使用YAML文件或具有映射权限的数据库来实现此功能。我们遵循一个简单的命名约定：用户接收对MCP目标的完全访问权限（例如，mcp-target-123）或工具级别的访问权限（例如，mcp-target-123:getOrder）。这些范围直接映射到传入OAuth令牌的范围声明中的工具权限，使授权模型可预测且易于审计。

下图说明了此工作流。

请求拦截器通过以下步骤在执行时强制执行权限：

1. 提取并解码JWT以检索范围声明。
2. 识别正在调用的工具（使用 tools/call）。
3. 如果用户缺乏完全的目标访问权限或工具特定权限（基于配置文件或访问策略数据存储），则阻止请求。
4. 对未经授权的调用返回结构化的MCP错误，防止后端工具处理程序执行。

核心授权功能被特意设计得非常精简：

def check_tool_authorization(scopes, tool, target):
    if target in scopes:
        return True
return f"{target}:{tool}" in scopes

此模式支持调用和发现路径的预测性执行（下一节将进一步讨论）。您可以将模型扩展到额外的声明（例如 tenantId 和 workspaceId）以支持多租户架构。

为实现操作安全，请保持拦截器确定性，避免复杂的条件分支逻辑，并且完全依赖于令牌声明而不是大型语言模型 (LLM) 指令。通过在网关边界强制执行授权——在 LLM 看到或执行任何工具之前——您可以跨角色、租户和域实现强大的隔离，而无需修改工具实现或 MCP 目标。

动态工具过滤

代理通过两种主要方法发现可用工具：允许自然语言查询的语义搜索功能（例如“查找与订单管理相关的工具”）和提供可用工具完整清单的标准 (tools/list) 操作。这种发现机制是代理功能的基础，但也带来了重大的安全考虑。如果没有适当的过滤控制，MCP 服务器将返回所有可用工具的完整列表，而不管请求代理或用户的授权级别如何。这种不受限制的工具发现可能会通过向未经授权的用户或代理暴露敏感功能而带来潜在的安全漏洞。

当目标响应语义搜索或 MCP tools/list 请求返回工具列表时，可以使用网关响应拦截器来实施细粒度访问控制。拦截器在响应到达请求代理之前处理该响应，因此用户只能发现他们被授权访问的工具。工作流包括以下步骤：

1. 目标验证传入的JWT令牌，并根据语义搜索返回完整的工具列表或过滤后的集合，而无需考虑细粒度访问控制。
2. 配置的响应拦截器被 AgentCore Gateway 调用。响应拦截器提取并解码有效载荷中的JWT，检索定义用户权限的范围声明。
3. 对于列表中的每个工具，拦截器根据JWT范围评估用户的授权。
4. 未授权访问的工具将从列表中删除。
5. 响应拦截器返回一个包含已授权工具的转换后响应。

下图说明了这两种工具的工作流。

以下是响应拦截器Lambda处理程序的代码片段，该处理程序执行JWT令牌提取、工具列表检索和基于权限的过滤，然后返回带有已授权工具的转换后响应：

def lambda_handler(event, context):
    # Extract gateway response and authorization header
    gateway_response = event['mcp']['gatewayResponse']
    auth_header = gateway_response['headers'].get('Authorization', '')
    token = auth_header.replace('Bearer ', '')     # Extract scopes from JWT token
    claims = decode_jwt_payload(token)
    scopes = claims.get('scope', '').split()
     
    # Get tools from gateway response (for list tools)
    tools = gateway_response['body']['result'].get('tools', [])
    # from structuredContent(in case of semantic search)
    if not tools:
        tools = gateway_response['body']['result'].get('structuredContent', {}).get('tools', [])
    
    # Filter tools based on scopes
    filtered_tools = filter_tools_by_scope(tools, scopes)
    
    # Return transformed response with filtered tools
    return {
        "interceptorOutputVersion": "1.0",
        "mcp": {
            "transformedGatewayResponse": {
                "statusCode": 200,
                "headers": {"Authorization": auth_header},
                "body": {
                    "result": {"tools": filtered_tools}
                }
            }
        }
    }
}

filter_tools_by_scope 函数实现对用户允许范围的每个工具的授权检查：

def filter_tools_by_scope(tools, allowed_scopes):
    """Filter tools based on user's allowed scopes"""
    filtered_tools = []
    for tool in tools:
        target, action = tool['name'].split('___')
        # Check if user has full target access or specific tool access
        if target in allowed_scopes or f"{target}:{action}" in allowed_scopes:
            filtered_tools.append(tool)
         
    return filtered_tools

完整的实现可以在GitHub 仓库中找到。

自定义Header传播

随着AI代理与多个下游服务交互，在服务边界维护用户身份对于安全、合规和审计跟踪至关重要。当代理通过AgentCore Gateway调用工具时，原始用户身份必须从代理流向网关，再从网关流向下游服务。如果没有适当的身份传播，下游服务就无法强制执行特定于用户的授权策略、维护准确的审计日志或实现租户隔离。在不同用户共享相同代理基础设施但需要严格数据分离的多租户环境中，这一挑战尤为突出。

网关请求拦截器通过遵循以下步骤，从传入请求Header和上下文中提取身份信息，将其转换为下游服务期望的格式，并丰富请求，然后再将其发送到目标服务：

1. 网关请求拦截器从传入请求中提取授权Header，并为其转换成适合下游服务的格式。
2. AgentCore Gateway协调请求流并管理拦截器执行。
3. 目标调用接收到使用适当格式的身份信息的丰富请求。

网关请求拦截器帮助组织获得用户操作的端到端可见性，跨服务边界强制执行一致的授权策略，并维护对数据主权要求的合规性。

工作流包括以下步骤：

1. MCP客户端调用 AgentCore Gateway。
2. AgentCore Gateway 对入站请求进行身份验证。
3. AgentCore Gateway 调用自定义拦截器。
4. 网关请求拦截器通过将授权令牌作为参数添加到下游Lambda目标来转换传入的请求有效载荷。（我们不建议将传入的JWT原封不动地发送给下游API，因为它由于权限升级和凭证被盗的风险而不安全。但是，在某些例外情况下，代理可能需要使用访问令牌调用MCP服务器以访问下游API。）或者，您可以移除来自请求的传入JWT，并添加一个新的JWT，其中包含一个范围受限的最小权限令牌，用于调用相关的下游API。
5. AgentCore Gateway 使用转换后的请求调用目标。目标接收拦截器Lambda函数传递的授权令牌。
6. AgentCore Gateway 返回来自目标的响应。

下图说明了此工作流。

以下是执行自定义Header传播的拦截器Lambda处理程序的代码片段：

import json
import uuid def lambda_handler(event, context):
    # Extract the gateway request from the correct structure
    mcp_data = event.get('mcp', {})
    gateway_request = mcp_data.get('gatewayRequest', {})
    headers = gateway_request.get('headers', {})
    body = gateway_request.get('body', {})
    extended_body = body
    
    # Pass through the Authorization header
    a... [内容被截断]

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

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