Eon 如何基于 Amazon Bedrock AgentCore 的 MCP 网关构建多云故障排查体系

本文为客座博客，由 Eon 的 Roei Zavida 共同撰写。

构建 AI 原生产品的独立软件供应商（ISV）需要将 Agent 和人类工程师连接到跨多个公有云的数十种运维工具，而这些工具各自拥有不同的身份认证模型、网络边界和访问策略。当这些工具同时横跨 AWS、GCP 和 Azure 时，系统的集成复杂度将呈指数级上升。

本文介绍了 Eon 如何利用 Amazon Bedrock AgentCore——一个支持以任意框架或模型大规模构建、连接并优化 Agent 的平台。Eon 利用它将分散的单工具凭证及本地模型上下文协议（Model Context Protocol，MCP）进程替换为单一的认证网关。最终，开发人员与自主运行的 Agent 获得了跨三大云平台的统一故障排查工具访问权限。新工程师现在仅需约 2 分钟即可配置好所有排查工具，而此前配置凭证和本地 MCP 服务器需要耗时 2 天。

关于 Eon

Eon 为 AI 时代提供自主数据基础设施（Autonomous Data Foundation）。该平台可自动发现并对横跨 AWS、Azure 和 GCP 的云资源进行分类。平台提供持续的数据去重备份，据 Eon 内部测试统计可降低高达 50% 的存储成本。此外，它还能检测勒索软件与恶意 Agent（rogue-agent）造成的破坏，并为 AI Agent 提供实时可靠的接地上合规上下文（grounded context）。所有这些功能均基于单一的只读 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 服务器，不仅难以实现标准化，也很难保证版本同步。
• 身份隔离 —— 工程师通过基于角色的权限访问各系统，但此前缺乏一个统一的地方来判定每个人或 Agent 有权调用哪些工具。
• 消除网络额外开销的跨账号访问 —— 在多个 AWS 账号间托管 MCP 服务器通常需要为每个账号配置 VPC 对等连接（VPC peering）或 AWS PrivateLink，成倍推高了运维成本和初始设置时间。
• 开发者入职效率 —— 新入职工程师在能够开始排查首个故障之前，平均需要耗费大约 2 天时间来配置各种凭证和本地 MCP 服务器。
• Agent 访问支持 —— Eon 基于 Amazon Bedrock 运行 Claude 的自主 SRE Agent 需要具备与人类工程师相同的工具访问能力，但必须采用不同的权限策略。

工程团队人数的增长与不断扩大的 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、Policy in Amazon Bedrock AgentCore、AgentCore Runtime 以及 AgentCore Identity（均为 Amazon Bedrock AgentCore 的组成功能）。下图展示了客户端请求如何流经身份认证层到达单一网关。随后，网关将通过鉴权的工具调用路由到托管在多个 AWS 账号下的 AgentCore Runtime 目标端。

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

该架构分为五个层级：

客户端（Clients）

使用 Claude Code、Cursor 或 OpenAI Codex 的开发人员均统一连接到一个 MCP URL。而基于 Amazon Bedrock 运行 Claude 的自主 SRE Agent 则以另一种独立身份连接至同一个网关。

身份层（Identity plane）

企业单点登录（SSO）通过 Amazon Cognito 进行联合身份认证，由 Cognito 签发 JSON Web Token（JWT）并传递给网关。Amazon API Gateway 部署在最前端，作为人类工程师的 OAuth 入口，负责代理 MCP 会话。Agent 则使用 Cognito 的 client_credentials 授权模式直接向网关进行身份验证。

单一网关，最小权限访问（One gateway, least-privilege access）

单一的 AgentCore MCP Gateway 充当全公司统一的入口门面。处于 ENFORCE（强制）模式的 Cedar 策略负责控制哪些主体可以调用哪些工具。读取操作仅向特定群组开放，而非向所有已认证用户完全开放。写入操作被严格限制在低风险协作行为（如在 PR 或工单中添加评论），所有生产环境工具均保持只读状态。

Amazon Bedrock AgentCore 策略引擎（Policy in Amazon Bedrock AgentCore）

Cedar 策略将每个主体映射到其被允许调用的工具列表。写操作严格限定为低风险的协作动作（如在 PR 或工单发表评论），生产工具全为只读。网关在将每个 tools/call 请求转发至目标端之前，都会先行通过 Cedar 规则评估。

目标端（Targets）

数十个目标 MCP 服务器在单一网关上公开了数百个工具，由分布在多个 AWS 账号中的 AgentCore Runtime 提供服务支持。每个 Runtime 都能将本地基于 stdio 的 MCP 服务器转换为可通过网关调用的流式 HTTP 端点。

开发者只需打开其集成开发环境（IDE），配置一个统一的 MCP URL，通过企业 SSO 完成认证，网关就会在单次 tools/list 响应中汇总呈现数百个工具。完全无需本地配置，也无需管理单独工具的 Token。

身份与访问权限隔离

核心的安全决策是在网关层通过 Cedar 策略强制实施读写边界隔离。

单网关，策略强制隔离：

网关同时接收 JWT Token（人类工程师通过企业 SSO 和 Cognito 登录）以及 client_credentials Token（供 Agent 使用）。Cedar 策略明确规定了每个主体能够执行的操作。获得审批群组中的人类用户拥有读取权限；而写入操作必须具备显式的 Cedar 授权（permit），且仅授予特定的 Agent 身份标识。

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 以代码形式（Policy as Code）协同管理，配有严格的代码审查评论，确保每次权限变更均具备版本控制和完整的审计记录。

在网关内部，Cedar 策略按照 SSO 用户组限定工具访问范围，用户组又与岗位角色严格绑定。工程师默认拥有开发和测试环境的访问权限。而生产环境访问则遵循 Eon 的安全与合规控制体系：全部为只读模式、通过审批流程实施即时（Just-in-Time）授权，并进行全方位审计。新团队成员所在群组的权限也是按角色划分，而非取决于他们当下负责维护哪项具体服务。由于 Agent 的每次操作都会在 ENFORCE 模式下由 Cedar 严格校验，并限定在最小权限工具集内，因此自主 Agent 能够在安全受控的边界内运行，仅能调用被显式许可调用的工具。

“过去，我们的内部 Agent 无法访问开发者排障时使用的同套工具。现在，它可以通过专属身份和更加严密的工具集，无缝接入同一个 Gateway。”

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

跨账号网络连接

Eon 在多个 AWS 账号中部署了 Runtime，并按环境或服务边界进行隔离编排。AgentCore Gateway 通过 IAM 跨账号角色假设（AssumeRole）来调用各个 Runtime。账号 B 中的 Runtime 通过标准的 IAM 信任策略信任账号 A 中 AgentCore Gateway 的执行角色。

这一设计彻底消除了以下负担：

• 跨多个 AWS 账号配置 VPC 对等互联（VPC peering）及路由表管理的麻烦；
• 每个账号的 PrivateLink 端点费用；
• 跨账号安全组（Security Group）的协同配置；
• 每增加一个新账号所需耗费的数天配置周期（如今只需一条 IAM 信任策略，数分钟内即可完成部署）。

目标接入模式：

根据每个工具的认证方式和托管形态，Eon 主要采用两类接入模式。下表总结了适用场景与典型范例：

接入模式	适用场景	范例
Runtime + IAM	工具需要通过 IAM 凭据进行跨云调用	Grafana 查询、Kubernetes API 调用
Runtime 封装远程 MCP	工具暴露的接口面需要过滤，或需要凭证格式转换	Linear

绝大多数目标端均采用「Runtime + IAM」模式。Eon 仅在需要缩减工具目录规模或网关无法直接提供特定格式凭据时，才会对远程 MCP 进行封装包装。

排障会话执行流程

以下流程完整再现了一名开发者排查生产故障的过程：

1. 身份认证：开发者打开 Claude Code（或 Cursor / Codex），连接到网关的 MCP URL。IDE 通过企业 SSO 发起 OAuth 流程，Cognito 签发携带开发者身份和群组成员信息的 JWT。
2. 工具发现：网关汇总数十个已连接目标的 tools/list，并向 IDE 返回包含数百个工具的统一清单（manifest）。开发者可以在一个列表中查看所有可用的故障排查工具。
3. 工具调用：开发者提问：“请帮我查看过去一小时内支付服务的错误率突增情况。”IDE 内置的 Agent 选中 Grafana 查询工具并发送 tools/call 请求。
4. 策略评估：网关对照 Cedar 策略对请求进行鉴权评估。开发者的群组成员身份具备该 Grafana 工具的调用权限，请求获批放行。
5. Runtime 执行：网关将请求转发至托管 Grafana MCP 服务器的 Runtime（该 Runtime 运行在独立的 AWS 账号中）。Runtime 使用存储在 AgentCore Identity 保险库中的服务凭证对 Grafana 进行鉴权，执行查询并返回结果。
6. 跨工具关联分析：随后 Agent 继续检查 Kubernetes 部署状态及相关的 GitHub PR，这两者分别被路由至不同的 Runtime。开发者无需切换工具或重新认证，即可直接获取多方关联后的排查结果。

规模化落地的经验教训

在面向 100 多名开发者、支撑约 10,000 次会话的规模化落地过程中，团队遭遇了以下生产环境挑战：

控制 Cedar 策略大小

网关预先索引（pre-index）的每个工具 schema 都会占用 Cedar 策略的大小配额。随着数十个目标端暴露出极其庞大的工具清单，Eon 的策略尺寸逐渐逼近配额上限。解决策略是：对工具数量庞大的目标端启用 DYNAMIC（动态）列表模式。在 DYNAMIC 模式下，网关会在接收到请求时实时将 tools/list 调用转发给 MCP 服务器，而不是预先索引全部 schema，这样对策略空间完全零占用。

其代价在于，DYNAMIC 目标端无法支持基于语义的工具搜索。因此 Eon 采用了混合配置策略：对需要按用户进行 OAuth 认证的目标采用 DEFAULT 模式（这部分工具数量较少，且同意授权流程需要预索引的 schema 支持）；对工具目录极为庞大的目标端则采用 DYNAMIC 模式。

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

Claude Code、Cursor 和 Codex 均依赖 OAuth 中的 state 参数来防御跨站请求伪造（CSRF）。而 AgentCore 采用的是会话 URI 绑定机制。为此，Eon 构建了一个 Amazon API Gateway 转换层（shim），专门负责在这两种协议之间进行转换，使得标准 MCP 客户端无需任何二次修改即可顺利完成完整的 OAuth 鉴权流程。

此外，部分 MCP 服务器会公开多达数百个工具，而单个开发者在维护具体服务时只需要其中的一个子集。Eon 专门开发了一个 Runtime 包装器，在 Runtime 层对工具清单进行过滤，不仅有效减少了 tools/list 响应中的冗余干扰，还能防止误调用无关操作。这种方法同时允许相关目标端继续保持在 DEFAULT 模式下运行，保留了 DYNAMIC 模式所舍弃的语义搜索与内嵌特性。

成效

指标	采用 AgentCore 前	采用 AgentCore 后
每位开发者所需的凭证组数	每个系统/MCP 服务器一套（GitHub、Grafana、各云账号等）	0（只需一次 SSO 登录）
每台机器本地运行的 MCP 进程数	10	0
开发者入职配置耗时	2 天	2 分钟
跨账号网络配置	每个账号均需配置 VPC 对等连接	0（纯 IAM 机制）
工具鉴权机制	针对每个工具单独配置	一套 Cedar 策略同时管控人与 Agent
接入平台的开发者数量	—	100+
可访问工具数（Tools accessible）	—	数百种

This is a guest post co-written with Roei Zavida from Eon.

Independent software vendors (ISVs) building AI-powered products need to connect agents and humans to dozens of operational tools across clouds, each with different authentication models, network boundaries, and access policies. When those tools span AWS, GCP, and Azure simultaneously, the integration surface multiplies.

This post describes how Eon used Amazon Bedrock AgentCore, a platform to build, connect, and optimize agents at scale, with any framework or model. Eon used it to replace per-tool credentials and local Model Context Protocol (MCP) processes with a single authenticated gateway. The result gives developers and autonomous agents unified access to investigation tooling across three clouds. New engineers now reach all their investigation tools in about two minutes instead of the two days it previously took to configure credentials and local MCP servers.

About Eon

Eon provides the Autonomous Data Foundation for the AI era. The platform discovers and classifies cloud resources across AWS, Azure, and GCP. It provides continuous deduplicated backup that reduces storage costs by up to 50 percent in Eon’s internal measurements. It also detects ransomware and rogue-agent damage and delivers live grounded context for AI agents. All of this runs from a single read-only AWS Identity and Access Management (IAM) role, storing data in Apache Parquet and Apache Iceberg formats. Founded by former AWS engineers, Eon runs its software as a service (SaaS) infrastructure on AWS.

The challenge

Eon’s internal engineering team investigates production incidents across multiple clouds and dozens of operational systems. A crashed Kubernetes pod requires checking container logs, Grafana metrics, the deployment’s GitHub pull request (PR), and cloud-provider health status within the same session.

Eon needed to address several key requirements:

• Credential consolidation — Each new tool added another integration to configure, secure, and rotate, which got harder to keep consistent as the toolset grew.
• Eliminate local MCP processes — Each developer ran several MCP servers locally, which was hard to standardize and keep current.
• Identity separation — Engineers accessed each system with role-based permissions, but there was no single place to decide which tools each person or agent could call.
• Cross-account access without networking overhead — Hosting MCP servers across multiple AWS accounts required virtual private cloud (VPC) peering or AWS PrivateLink per account, multiplying operational cost and setup time.
• Developer onboarding — New engineers spent roughly 2 days configuring credentials and local MCP servers before investigating their first incident.
• Agent access — Eon’s autonomous site reliability engineering (SRE) agent (running Claude on Amazon Bedrock) needed the same tool access as humans, but with different permissions.

Growing engineering headcount combined with a fast-expanding set of AI tools and MCPs made maintaining credentials and local MCP servers increasingly costly. This pushed Eon toward a centralized solution.

Approaches considered

Before building on AgentCore, Eon evaluated alternatives:

Option 1: Centralized proxy with custom auth

Every harness had its own proxy configuration with all the targets. A single reverse proxy aggregating all tools, with a custom authentication layer. This handled credential consolidation but only supported remote MCP and required building and maintaining tool protocol translation, session management, and authorization logic from scratch. The implementation and maintenance burden was significant.

Option 2: Amazon Bedrock AgentCore Gateway

Amazon Bedrock AgentCore Gateway, a capability of Amazon Bedrock AgentCore, is a managed gateway with built-in identity federation, Cedar-based authorization policies, and Runtime hosting that converts local MCP servers to remote HTTP endpoints. This addressed all requirements without custom infrastructure.

Eon chose Option 2 because it provided identity separation, cross-account connectivity, and policy enforcement as managed capabilities rather than code they would need to build and maintain. These were the only two options on the table.

Solution overview

Eon deployed the full Amazon Bedrock AgentCore stack: AgentCore Gateway, Policy in Amazon Bedrock AgentCore, AgentCore Runtime, and AgentCore Identity, all capabilities of Amazon Bedrock AgentCore. The following diagram shows how client requests flow through the authentication layer to a single gateway. The gateway routes authorized tool calls to targets hosted on AgentCore Runtimes across multiple AWS accounts.

Figure 1: Eon’s centralized gateway architecture on Amazon Bedrock AgentCore

The architecture has five layers:

Clients

Developers using Claude Code, Cursor, or OpenAI Codex connect to a single MCP URL. An autonomous SRE agent running Claude on Amazon Bedrock connects to the same gateway with a different identity.

Identity plane

Corporate single sign-on (SSO) federates through Amazon Cognito, which mints the JSON Web Token (JWT) and hands it to the gateway. Amazon API Gateway sits in front as the OAuth entry point for humans, proxying the MCP session. Agents authenticate with Cognito client_credentials grants directly against the gateway.

One gateway, least-privilege access

A single AgentCore MCP Gateway serves as the company-wide front door. Cedar policies in ENFORCE mode control which principals can invoke which tools. Read operations are available to selected groups, not every authenticated user. Write operations are limited to low-impact collaboration actions, such as commenting on a PR or ticket, and production tools are read-only.

Policy in Amazon Bedrock AgentCore

Cedar policies map each principal to permitted tools. Write operations are limited to low-impact collaboration actions, such as commenting on a PR or ticket, and production tools are read-only. The gateway evaluates every tools/call request against Cedar before forwarding to the target.

Targets

Dozens of target MCP servers exposing hundreds of tools on the one gateway, served by AgentCore Runtimes distributed across multiple AWS accounts. Each Runtime converts local stdio-based MCP servers into Streamable HTTP endpoints accessible through the gateway.

A developer opens their integrated development environment (IDE), configures one MCP URL, authenticates through corporate SSO, and the gateway aggregates hundreds of tools into a single tools/list response. No local setup and no per-tool tokens.

Identity and access separation

The core security decision was enforcing read and write boundaries through Cedar policy at the gateway level.

Single gateway, policy-enforced separation:

The gateway accepts both JWT tokens (humans through corporate SSO and Cognito) and client_credentials tokens (agents). Cedar policies determine what each principal can do. Humans in approved groups get read access. Write operations require explicit Cedar permits granted only to specific agent identities.

Cedar reinforces per-tool granularity:

// 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 policies are managed as code through GitHub PRs with review comments, giving the team version control and audit trail on every permission change.

Within the gateway, Cedar policies scope tool access by SSO group, and groups map to job role. Engineers have access to development and testing environments by default. Production access follows Eon’s security and compliance controls: it is read-only, granted just-in-time through an approval process, and audited. A new team member’s group is scoped the same way, by role rather than by which service they happen to own. Because every agent action is checked against Cedar in ENFORCE mode and scoped to a least-privilege tool set, the autonomous agent operates within safe, bounded limits. It can only invoke the specific tools its identity is explicitly permitted to call.

“Before, our internal agent couldn’t reach the same investigation tools developers used. After, it uses the same Gateway with its own identity and a tighter tool set.”

— Roei Zavida, Senior DevOps Engineer, Eon

Cross-account connectivity

Eon runs Runtimes across multiple AWS accounts, organized by environment or service boundary. AgentCore Gateway reaches each Runtime through IAM cross-account role assumption. The Runtime in Account B trusts the AgentCore Gateway execution role in Account A through a standard IAM trust policy.

What this eliminated:

• VPC peering configuration and route table management across multiple AWS accounts.
• PrivateLink endpoint costs per account.
• Security group coordination between accounts.
• Days of setup per new account (replaced by one IAM trust policy, deployable in minutes).

Target attachment patterns:

Depending on each tool’s authentication and hosting model, Eon uses two primary attachment patterns. The following table summarizes when to use each pattern and gives an example.

Pattern	When to use	Example
Runtime + IAM	Tool needs a cloud hop through IAM credentials	Grafana queries, Kubernetes API calls
Runtime wrapping remote MCP	Tool surface needs filtering or credential translation	Linear

Most targets use Runtime + IAM. Eon only wraps a remote MCP to shrink its catalog or slot in a credential the gateway cannot otherwise supply.

Investigation session flow

The following flow traces a developer investigating a production incident:

1. Authentication. The developer opens Claude Code (or Cursor/Codex) and connects to the gateway MCP URL. The IDE initiates OAuth through corporate SSO. Cognito issues a JWT carrying the developer’s identity and group memberships.
2. Tool discovery. The gateway aggregates tools/list from dozens of connected targets and returns a unified manifest of hundreds of tools to the IDE. The developer sees all available investigation tools in one list.
3. Tool invocation. The developer asks: “Show me the error rate spike for the payments service in the last hour.” The IDE’s agent selects the Grafana query tool and sends a tools/call request.
4. Policy evaluation. The gateway evaluates the request against Cedar. The developer’s group membership grants access to the Grafana tool. The request passes.
5. Runtime execution. The gateway forwards the request to the Runtime hosting the Grafana MCP server (running in a separate AWS account). The Runtime authenticates to Grafana using a service credential stored in the AgentCore Identity vault, executes the query, and returns results.
6. Cross-tool correlation. The agent follows up by checking the Kubernetes deployment status and the related GitHub PR, each routed to different Runtimes. The developer sees correlated results without switching tools or re-authenticating.

Lessons learned at scale

Deploying to 100+ developers and approximately 10,000 sessions surfaced production challenges:

Managing Cedar policy size

Every tool schema that the gateway pre-indexes contributes to Cedar policy size. With dozens of targets exposing extensive tool manifests, Eon’s policy grew toward the size quota. The fix: DYNAMIC listing mode for high-tool-count targets. In DYNAMIC mode, the gateway forwards tools/list calls to the MCP server at request time instead of pre-indexing schemas, adding zero bytes to the policy.

The trade-off is that semantic tool search is unavailable for DYNAMIC targets. Eon runs a hybrid configuration: DEFAULT mode for targets requiring per-user OAuth (smaller tool counts, need pre-indexed schemas for the consent flow) and DYNAMIC mode for large-catalog targets.

OAuth session binding for standard MCP clients

Claude Code, Cursor, and Codex expect the OAuth state parameter for cross-site request forgery (CSRF) protection. AgentCore uses session-URI binding. Eon built an Amazon API Gateway shim that translates between the two protocols so standard MCP clients can complete the OAuth flow without modification.

Some MCP servers expose hundreds of tools. Individual developers need only a subset for their service. Eon built a Runtime wrapper that filters the tool manifest at the Runtime layer, reducing noise in tools/list responses and preventing accidental invocation of irrelevant operations. This approach also keeps those targets on DEFAULT mode, preserving semantic search and embedded features that DYNAMIC mode sacrifices.

Results

Metric	Before AgentCore	After AgentCore
Credential sets per developer	One per system/MCP server (GitHub, Grafana, cloud accounts, etc.)	0 (one SSO login)
Local MCP processes per machine	10	0
Developer onboarding time	2 days	2 minutes
Cross-account networking configs	VPC peering per account	0 (IAM-only)
Tool authorization	Configured per tool	One Cedar policy for humans and agents
Developers on the platform	—	100+
Tools accessible from one URL	—	Hundreds (across dozens of targets)
Sessions processed	—	~10,000

The single-gateway architecture has run in production for Eon’s internal engineering team for several months. The clearest outcome is developer onboarding. Setting up access to the full tool set dropped from roughly two days of configuring credentials and local MCP servers to about two minutes. A new engineer connects one gateway URL, authenticates through corporate SSO, and immediately sees the tools their role allows.

The internal agent accounts for most of the time saved, because it gains access to more context through the gateway, improving investigation accuracy. Engineers save the time previously spent on AI tool setup, because they only need to connect to the gateway URL.

Eon is exploring how the same patterns can support AI capabilities in its own product.

“AgentCore gave us one authenticated MCP Gateway instead of per-tool tokens and local MCP processes. Developers and our internal agent now reach Kubernetes, Grafana, GitHub, and our cloud accounts from a single URL.”

— Roei Zavida, Senior DevOps Engineer, Eon

Conclusion

This post described how Eon replaced per-tool credentials and local MCP processes with a single Amazon Bedrock AgentCore MCP Gateway. The result is Cedar-based identity separation, cross-account connectivity without VPC peering, and unified tool access for more than 100 developers and autonomous agents across three clouds. The single-gateway architecture, Cedar least-privilege enforcement, and hybrid DEFAULT and DYNAMIC policy mode are reusable patterns for ISVs connecting agents and developers to tools across multiple clouds.

To learn more about building on Amazon Bedrock AgentCore, review these resources:

---

About the authors

Dor Shaboy

Dor is a Solutions Architect at AWS with over a decade of experience in cloud architecture and security engineering. Dor works closely with ISVs, helping them scale and adopt AWS services. For the past year, he has been partnering with Eon on their AI-powered investigation platform built on Amazon Bedrock AgentCore. Outside of work, Dor enjoys hiking and tennis.

Eashan Kaushik

Eashan is a Specialist Solutions Architect AI/ML at Amazon Web Services. He is driven by creating cutting-edge generative AI solutions while prioritizing a customer-centric approach to his work. Before this role, he obtained an MS in Computer Science from NYU Tandon School of Engineering. Outside of work, he enjoys sports, lifting, and running marathons.

Roei Zavida

Roei is a Senior DevOps Engineer at Eon, where he works on the team that runs Eon’s cloud infrastructure and internal developer tooling, including the AgentCore MCP Gateway engineers use to investigate production.