Eon 如何借助 Amazon Bedrock AgentCore MCP Gateway 构建多云调查工具

这篇客座文章由 Eon 的 Roei Zavida 共同撰写。

构建 AI 驱动产品的独立软件供应商（ISV）需要将智能体和人员连接到跨云环境中的数十种运营工具，而这些工具各自采用不同的身份验证模型、网络边界和访问策略。当这些工具同时分布在 AWS、GCP 和 Azure 上时，集成工作量会成倍增加。

本文介绍 Eon 如何使用 Amazon Bedrock AgentCore——一个可借助任何框架或模型大规模构建、连接和优化智能体的平台。Eon 利用它将各工具单独配置的凭证和本地 Model Context Protocol（MCP）进程替换为一个经过身份验证的统一网关。由此，开发人员和自主智能体可以统一访问三个云环境中的调查工具。新工程师现在大约只需两分钟即可访问所有调查工具，而此前配置凭证和本地 MCP 服务器需要两天。

关于 Eon

Eon 为 AI 时代提供自主数据基础平台。该平台可发现并分类 AWS、Azure 和 GCP 上的云资源，并提供持续去重备份；根据 Eon 的内部测量，最多可降低 50 percent 的存储成本。平台还可以检测勒索软件和恶意智能体造成的损害，并为 AI 智能体提供实时、有据可依的上下文。所有这些功能均通过单个只读 AWS Identity and Access Management（IAM）角色运行，并以 Apache Parquet 和 Apache Iceberg 格式存储数据。Eon 由前 AWS 工程师创立，其软件即服务（SaaS）基础设施运行在 AWS 上。

挑战

Eon 的内部工程团队需要跨多个云和数十个运营系统调查生产事故。发生 Kubernetes Pod 崩溃时，需要在同一会话中检查容器日志、Grafana 指标、部署对应的 GitHub 拉取请求（PR）以及云服务提供商的运行状况。

Eon 需要解决以下几个关键需求：

• 整合凭证 — 每增加一个新工具，就需要配置、保护和轮换另一套集成；随着工具集不断扩大，保持一致性也变得越来越困难。
• 消除本地 MCP 进程 — 每位开发人员都在本地运行多个 MCP 服务器，因此很难实现标准化并保持最新。
• 身份隔离 — 工程师通过基于角色的权限访问各个系统，但没有统一的地方来决定每个人或智能体可以调用哪些工具。
• 无需额外网络开销的跨账户访问 — 在多个 AWS 账户中托管 MCP 服务器，需要为每个账户配置虚拟私有云（VPC）对等连接或 AWS PrivateLink，导致运营成本和设置时间成倍增加。
• 开发人员入职 — 新工程师在调查第一个事故之前，通常要花约 2 days 配置凭证和本地 MCP 服务器。
• 智能体访问 — Eon 的自主站点可靠性工程（SRE）智能体（在 Amazon Bedrock 上运行 Claude）需要与人员访问相同的工具，但权限设置有所不同。

工程团队人数不断增加，同时 AI 工具和 MCP 的数量也快速增长，使得维护凭证和本地 MCP 服务器的成本越来越高。这促使 Eon 转向集中式解决方案。

评估过的方案

在基于 AgentCore 构建之前，Eon 评估了其他方案：

方案 1：带自定义身份验证的集中式代理

每个工具框架都有自己的代理配置，包含所有目标。通过一个自定义身份验证层，由单一反向代理聚合所有工具。这解决了凭证整合问题，但仅支持远程 MCP，而且需要从头构建和维护工具协议转换、会话管理及授权逻辑。实现和维护负担很重。

选项 2：Amazon Bedrock AgentCore Gateway

Amazon Bedrock AgentCore Gateway 是 Amazon Bedrock AgentCore 的一项功能，是托管式网关，内置身份联合、基于 Cedar 的授权策略，以及可将本地 MCP 服务器转换为远程 HTTP 端点的 Runtime 托管功能。它无需自定义基础设施即可满足所有要求。

Eon 选择了选项 2，因为它将身份隔离、跨账户连接和策略执行作为托管功能提供，而非需要自行构建和维护的代码。这是当时仅有的两个选项。

解决方案概览

Eon 部署了完整的 Amazon Bedrock AgentCore 堆栈：AgentCore Gateway、Amazon Bedrock AgentCore 中的 Policy、AgentCore Runtime 和 AgentCore Identity，它们都是 Amazon Bedrock AgentCore 的功能。下图展示了客户端请求如何经过身份验证层并流向单一网关。网关将经过授权的工具调用路由到托管在多个 AWS 账户中的 AgentCore Runtimes。

图 1：Eon 基于 Amazon Bedrock AgentCore 的集中式网关架构

该架构包含五个层级：

客户端

使用 Claude Code、Cursor 或 OpenAI Codex 的开发者连接到单一 MCP URL。运行 Claude on Amazon Bedrock 的自主 SRE 代理使用不同的身份连接到同一网关。

身份平面

企业单点登录 (SSO) 通过 Amazon Cognito 联合，后者生成 JSON Web Token (JWT) 并将其交给网关。Amazon API Gateway 位于前端，作为 OAuth 入口点，并代理 MCP 会话。代理通过 Cognito client_credentials 授权直接向网关进行身份验证。

单一网关，最小权限访问

单一 AgentCore MCP Gateway 作为公司的统一入口。处于 ENFORCE 模式的 Cedar 策略控制哪些主体可以调用哪些工具。读取操作仅向选定群组开放，而非所有通过身份验证的用户。写入操作仅限于低影响的协作操作，例如为 PR 或工单发表评论；生产工具则为只读。

Amazon Bedrock AgentCore 中的 Policy

Cedar 策略将每个主体映射到其获准使用的工具。写入操作仅限于低影响的协作操作，例如为 PR 或工单发表评论；生产工具则为只读。网关会在转发到目标之前，根据 Cedar 检查每个 tools/call 请求。

目标

数十个目标 MCP 服务器通过一个网关提供数百种工具，这些服务器由分布在多个 AWS 账户中的 AgentCore Runtimes 托管。每个 Runtime 都会将基于本地 stdio 的 MCP 服务器转换为可通过网关访问的 Streamable HTTP 端点。

开发者打开集成开发环境 (IDE)，配置一个 MCP URL，通过企业 SSO 完成身份验证，网关便会将数百种工具聚合到单个 tools/list 响应中。无需本地设置，也无需为每种工具配置令牌。

身份与访问隔离

核心安全决策是在网关层通过 Cedar 策略执行读写权限边界。

单一网关，由策略强制实施隔离：

网关接受 JWT 令牌（供通过企业 SSO 和 Cognito 进行身份验证的人员使用）以及 client_credentials 令牌（供智能体使用）。Cedar 策略决定每个主体可以执行哪些操作。获批组中的人员拥有读取权限。写入操作需要明确的 Cedar 授权，且仅授予特定的智能体身份。

Cedar 进一步细化了对每种工具的访问控制：

// Agent "sre-bot" can add comments on GitHub PRs
permit(
    principal == Agent::"sre-bot",
    action == Action::"tools/call",
    resource == Tool::"github_add_pr_comment"
);

// No human principal can invoke mutation tools
forbid(
    principal in Group::"humans",
    action == Action::"tools/call",
    resource in ResourceGroup::"write-tools"
);

Cedar 策略通过带有审查意见的 GitHub PR 以代码形式管理，使团队能够对每项权限变更进行版本控制和审计。

在网关中，Cedar 策略按 SSO 组限定工具访问权限，而组与工作职责相对应。默认情况下，工程师可以访问开发和测试环境。生产环境的访问遵循 Eon 的安全与合规控制：仅限读取，通过审批流程按需即时授予，并进行审计。新团队成员的组也以同样的方式按职责限定，而非取决于其恰好负责哪个服务。由于每项智能体操作都在 ENFORCE 模式下经过 Cedar 检查，并被限制在遵循最小权限原则的工具集内，自主智能体的运行范围安全且明确。它只能调用其身份获准使用的特定工具。

“以前，我们的内部智能体无法使用开发人员所用的同一套调查工具。现在，它通过自己的身份使用同一个 Gateway，并且可用工具集更精简。”

— Roei Zavida，Eon 高级 DevOps 工程师

跨账户连接

Eon 在多个 AWS 账户中运行 Runtimes，按环境或服务边界组织。AgentCore Gateway 通过 IAM 跨账户角色承担来访问每个 Runtime。账户 B 中的 Runtime 通过标准 IAM 信任策略信任账户 A 中的 AgentCore Gateway 执行角色。

因此省去了：

• 在多个 AWS 账户之间配置 VPC 对等连接和管理路由表。
• 每个账户的 PrivateLink 端点费用。
• 账户间的安全组协调。
• 每个新账户数天的设置时间（由一条可在几分钟内完成部署的 IAM 信任策略取代）。

目标附加模式：

根据每种工具的身份验证和托管模式，Eon 采用两种主要的附加模式。下表概述了每种模式的适用场景，并给出示例。

大多数目标使用 Runtime + IAM。Eon 仅在需要精简工具目录，或注入网关无法以其他方式提供的凭证时，才会封装远程 MCP。

调查会话流程

以下流程跟踪开发人员调查生产事故的过程：

1. 身份验证。开发人员打开 Claude Code（或 Cursor/Codex），并连接到网关 MCP URL。IDE 通过企业 SSO 发起 OAuth 流程。Cognito 会签发 JWT，其中包含开发人员的身份和组成员身份。
2. 工具发现。网关汇总数十个已连接目标的 `tools/list`，并向 IDE 返回包含数百种工具的统一清单。开发人员可以在一个列表中看到所有可用的调查工具。
3. 工具调用。开发人员提出请求：“显示过去一小时内 payments 服务的错误率飙升情况。”IDE 中的智能体选择 Grafana 查询工具，并发送 `tools/call` 请求。
4. 策略评估。网关根据 Cedar 评估请求。开发者的群组成员身份授予其访问 Grafana 工具的权限。请求通过。
5. 运行时执行。网关将请求转发到托管 Grafana MCP 服务器的 Runtime（该服务器运行在独立的 AWS 账户中）。Runtime 使用存储在 AgentCore Identity 保管库中的服务凭证向 Grafana 进行身份验证，执行查询并返回结果。
6. 跨工具关联。代理随后检查 Kubernetes 部署状态和相关的 GitHub PR，这两项操作分别路由到不同的 Runtime。开发者无需切换工具或重新进行身份验证，即可查看关联结果。

规模化经验

部署到 100 多名开发者并处理约 10,000 个会话后，暴露出一些生产环境中的挑战：

管理 Cedar 策略大小

网关预先索引的每个工具架构都会增加 Cedar 策略的大小。当数十个目标公开大量工具清单时，Eon 的策略大小逐渐接近配额上限。解决方法：对工具数量较多的目标采用 DYNAMIC 列表模式。在 DYNAMIC 模式下，网关会在请求时将 tools/list 调用转发到 MCP 服务器，而不是预先索引架构，因此不会增加策略大小。

这样做的代价是，DYNAMIC 目标无法使用语义工具搜索。Eon 采用混合配置：对需要按用户进行 OAuth 身份验证的目标（工具数量较少，且授权流程需要预先索引架构）使用 DEFAULT 模式；对大型目录目标使用 DYNAMIC 模式。

标准 MCP 客户端的 OAuth 会话绑定

Claude Code、Cursor 和 Codex 需要 OAuth state 参数来防范跨站请求伪造（CSRF）。AgentCore 使用基于会话 URI 的绑定。Eon 构建了一个 Amazon API Gateway 中间层，在两种协议之间进行转换，使标准 MCP 客户端无需修改即可完成 OAuth 流程。

筛选工具范围

有些 MCP 服务器公开数百种工具。各个开发者只需要用于其服务的部分工具。Eon 构建了一个 Runtime 包装器，在 Runtime 层筛选工具清单，从而减少 tools/list 响应中的冗余信息，并避免意外调用无关操作。这种方法也使这些目标能够继续使用 DEFAULT 模式，保留 DYNAMIC 模式所舍弃的语义搜索和内嵌功能。

成果

单网关架构已在 Eon 内部工程团队的生产环境中运行数月。最显著的成效体现在开发者入职配置上。配置凭证和本地 MCP 服务器、以获取整套工具访问权限所需的时间，从大约两天缩短至约两分钟。新工程师连接一个网关 URL，通过企业 SSO 完成身份验证后，即可立即看到其角色获准使用的工具。

内部代理节省了大部分时间，因为它通过网关获取更多上下文，从而提高了调查准确性。工程师也省去了以往配置 AI 工具的时间，因为他们只需连接到网关 URL。

Eon 正在探索如何将相同模式用于支持其自有产品中的 AI 功能。

“AgentCore 为我们提供了一个经过身份验证的 MCP Gateway，不再需要为每种工具分别配置令牌和本地 MCP 进程。开发者和我们的内部代理现在只需通过一个 URL，就能访问 Kubernetes、Grafana、GitHub 和我们的云账户。”

— Roei Zavida，Eon 高级 DevOps 工程师

结语

本文介绍了 Eon 如何通过单个 Amazon Bedrock AgentCore MCP Gateway，取代为每种工具分别配置的凭证和本地 MCP 进程。由此实现了基于 Cedar 的身份隔离、无需 VPC 对等连接的跨账户连接，以及为三个云环境中的 100 多名开发者和自主代理提供统一的工具访问。单网关架构、Cedar 最小权限执行，以及结合 DEFAULT 和 DYNAMIC 的混合策略模式，都是可复用的模式，可供 ISV 用于连接多个云环境中的代理、开发者与工具。

如需进一步了解如何基于 Amazon Bedrock AgentCore 进行构建，请参阅以下资源：

• Amazon Bedrock AgentCore Gateway 文档。
• Amazon Bedrock AgentCore Runtime 文档。
• Amazon Bedrock AgentCore 入门研讨会。

作者简介

Dor Shaboy

Dor 是 AWS 的解决方案架构师，在云架构和安全工程领域拥有十多年的经验。他与 ISV 密切合作，帮助他们扩展业务并采用 AWS 服务。在过去一年里，他一直与 Eon 合作，打造基于 Amazon Bedrock AgentCore 的 AI 调查平台。工作之余，Dor 喜欢徒步和打网球。

Eashan Kaushik

Eashan 是 Amazon Web Services 的 AI/ML 专家解决方案架构师。他致力于打造前沿的生成式 AI 解决方案，并始终以客户为中心。担任现职之前，他在 NYU Tandon 工程学院获得了计算机科学硕士学位。工作之余，他喜欢运动、举重和跑马拉松。

Roei Zavida

Roei 是 Eon 的高级 DevOps 工程师，负责运行 Eon 云基础设施和内部开发者工具的团队工作，其中包括供工程师调查生产环境问题时使用的 AgentCore MCP Gateway。