Eon 如何基于 Amazon Bedrock AgentCore 搭建多云事件调查 MCP 网关

本文是与 Eon 的 Roei Zavida 合作的客座文章。

构建 AI 产品的独立软件供应商（ISV）需要将智能体和人类连接到跨云的数十个运维工具，而这些工具各自拥有不同的身份验证模型、网络边界和访问策略。当这些工具同时横跨 AWS、GCP 和 Azure 时，集成面会成倍扩大。

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

关于 Eon

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

面临的挑战

Eon 的内部工程团队需要跨多个云和数十个运维系统调查生产事故。一个崩溃的 Kubernetes pod 需要在同一个会话中检查容器日志、Grafana 指标、部署相关的 GitHub pull request（PR）以及云服务商的健康状态。

Eon 需要满足几个关键需求：

• 凭证整合——每新增一个工具，就多一个需要配置、保护和轮换的集成，随着工具集的增长，保持一致性变得越来越难。
• 消除本地 MCP 进程——每个开发者都在本地运行多个 MCP 服务器，难以标准化和保持最新。
• 身份分离——工程师使用基于角色的权限访问各个系统，但没有一个统一的地方来决定每个人或智能体可以调用哪些工具。
• 无需网络开销的跨账户访问——跨多个 AWS 账户托管 MCP 服务器需要为每个账户设置虚拟私有云（VPC）对等连接或 AWS PrivateLink，运营成本和设置时间成倍增加。
• 开发者入职——新工程师在调查第一个事故之前，大约要花 2 天时间配置凭证和本地 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 Runtime 上的目标系统。

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

该架构分为五层：

客户端

使用 Claude Code、Cursor 或 OpenAI Codex 的开发者连接到单一的 MCP URL。一个在 Amazon Bedrock 上运行 Claude 的自主 SRE 智能体以不同的身份连接到同一个网关。

身份层

企业单点登录（SSO）通过与 Amazon Cognito 联合，由其生成 JSON Web Token（JWT）并交给网关。Amazon API Gateway 位于前端，作为面向人类用户的 OAuth 入口，代理 MCP 会话。智能体使用 Cognito client_credentials 授权直接向网关进行身份验证。

单一网关，最小权限访问

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

Amazon Bedrock AgentCore 中的策略

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

目标系统

数十个目标 MCP 服务器在这一网关上暴露数百个工具，由分布在多个 AWS 账户中的 AgentCore Runtime 提供服务。每个 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 进行检查，并限定在最小权限工具集内，自主智能体在安全、有界的范围内运行。它只能调用其身份被明确允许调用的特定工具。

“以前，我们的内部智能体无法访问开发者使用的那些调查工具。现在，它使用同一个网关，拥有自己的身份和更精简的工具集。”

—— 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. 工具调用。开发者提问：“向我展示支付服务在过去一小时的错误率激增情况。”IDE 的智能体选择 Grafana 查询工具并发送 `tools/call` 请求。
4. 策略评估。网关使用 Cedar 评估该请求。开发者的组成员身份授予其访问 Grafana 工具的权限。请求通过。
5. 运行时执行。网关将请求转发给托管 Grafana MCP 服务器的运行时（运行在独立的 AWS 账户中）。运行时使用存储在 AgentCore Identity 保险库中的服务凭证对 Grafana 进行身份验证，执行查询，并返回结果。
6. 跨工具关联。智能体接着检查 Kubernetes 部署状态和相关的 GitHub PR，每个请求被路由到不同的运行时。开发者无需切换工具或重新认证，即可看到关联的结果。

大规模部署中的经验教训

向 100 多名开发者和约 10,000 个会话的部署过程中暴露出一些生产环境挑战：

管理 Cedar 策略大小

网关预索引的每个工具架构（schema）都会增加 Cedar 策略的大小。由于数十个目标暴露了大量工具清单，Eon 的策略逐渐逼近大小配额上限。解决办法：为工具数量多的目标使用 DYNAMIC 列出模式。在 DYNAMIC 模式下，网关在请求时将 tools/list 调用转发给 MCP 服务器，而不是预先索引架构，从而不向策略添加任何字节。

其代价是 DYNAMIC 目标无法使用语义工具搜索。Eon 采用混合配置：对需要每用户 OAuth 的目标使用 DEFAULT 模式（工具数量较少，需要预索引架构以支持同意流程），对大型目录目标使用 DYNAMIC 模式。

为标准 MCP 客户端进行 OAuth 会话绑定

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

过滤工具表面

一些 MCP 服务器暴露数百个工具。单个开发者只需要其中适用于其服务的一个子集。Eon 构建了一个运行时包装器，在运行时层过滤工具清单，减少 tools/list 响应中的噪音，并防止意外调用无关操作。这种方式还使这些目标保持在 DEFAULT 模式，保留语义搜索以及 DYNAMIC 模式所牺牲的嵌入式功能。

成果

这种单网关架构已在 Eon 内部工程团队的生产环境中运行数月。最显著的成效是开发者入职。配置完整工具集的访问时间从大约两天（配置凭证和本地 MCP 服务器）缩短到约两分钟。新工程师只需连接一个网关 URL，通过公司 SSO 进行身份验证，即可立即看到其角色所允许使用的工具。

内部智能体节省了大部分时间，因为它通过网关获得了更多上下文，提高了排查准确性。工程师节省了以前花在 AI 工具配置上的时间，因为他们只需连接到网关 URL 即可。

Eon 正在探索如何用相同的模式在其自身产品中支持 AI 能力。

“AgentCore 为我们提供了一个经过身份验证的 MCP 网关，取代了逐个工具的令牌和本地 MCP 进程。开发人员和我们的内部智能体现在可以通过单一 URL 访问 Kubernetes、Grafana、GitHub 以及我们的云账户。”

— Roei Zavida，Eon 高级 DevOps 工程师

结论

本文介绍了 Eon 如何用单一的 Amazon Bedrock AgentCore MCP 网关取代逐个工具的凭证和本地 MCP 进程。其成果包括基于 Cedar 的身份隔离、无需 VPC 对等连接的跨账户连接，以及为三个云上的 100 多名开发人员和自主智能体提供统一的工具访问。单一网关架构、Cedar 最小权限执行以及 DEFAULT 与 DYNAMIC 混合策略模式，都是希望将智能体和开发人员连接到多云工具的 ISV 可以复用的模式。

要了解更多关于基于 Amazon Bedrock AgentCore 构建的信息，请查阅以下资源：

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

关于作者