Eon 如何利用 Amazon Bedrock AgentCore MCP Gateway 构建多云调查系统

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.

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.

Filtering tool surfaces

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

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:

• Amazon Bedrock AgentCore Gateway documentation.
• Amazon Bedrock AgentCore Runtime documentation.
• Getting Started with Amazon Bedrock AgentCore Workshop.

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.