Eon 如何在 Amazon Bedrock AgentCore 上使用 MCP Gateway 构建多云调查能力

本文是与 Eon 的 Roei Zavida 共同撰写的客座文章。

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

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

关于 Eon

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

面临的挑战

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

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

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

随着工程人员规模的增长以及 AI 工具和 MCP 的快速扩张，维护凭证和本地 MCP 服务器的成本越来越高。这促使 Eon 转向集中化解决方案。

考虑过的方案

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

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

每个 harness 都有自己的代理配置，包含所有目标。即用一个聚合所有工具的单一反向代理，并配以自定义身份验证层。这解决了凭证整合问题，但只支持远程 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 会话。Agent 使用 Cognito client_credentials 授权直接向网关进行认证。

一个网关，最小权限访问

单个 AgentCore MCP 网关作为全公司的统一入口。Cedar 策略以 ENFORCE 模式控制哪些主体可以调用哪些工具。读取操作仅对选定的组开放，而非所有已认证用户。写入操作仅限于低影响的协作动作，例如在 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 令牌（Agent）。Cedar 策略决定每个主体可以执行什么操作。经批准组中的成员获得读取权限。写入操作需要明确的 Cedar 许可，且仅授予特定的 Agent 身份。

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 的安全与合规控制：只读、通过审批流程即时授予，并进行审计。新团队成员的组以同样的方式按角色限定范围，而不是按其恰好拥有的服务。由于每个 Agent 操作都会以 ENFORCE 模式对照 Cedar 进行检查，并限定在最小权限工具集内，自主 Agent 在安全、有界的范围内运行。它只能调用其身份被明确允许调用的特定工具。

“以前，我们的内部 Agent 无法访问开发者使用的同一套调查工具。之后，它使用同一个网关，拥有自己的身份和更紧凑的工具集。”

—— Roei Zavida，Eon 高级 DevOps 工程师

跨账户连接

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

由此消除的内容：

• 跨多个 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 使用 session-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 文档.
• Getting Started with Amazon Bedrock AgentCore Workshop.

关于作者