借助 AI Agent 和 MCP 服务器生成自主业务洞察

一个周一早晨的问题

Sarah Chen 管理着 12 条装配线和 2,000 台机器。在上午 10 点的生产评审会之前，她需要得到一个答案：本周哪些产线需要关注？

问题很简单，过程却很痛苦。

她先打开 IoT 仪表板。4 号产线的电机温度比基线高出 12°C——这种情况已持续三天。是校准漂移，还是轴承故障？仪表板显示的是信号，而不是原因。于是，她转到 ERP 系统查看维护历史。42 号机器八个月前更换过轴承。保修期是 12 个月，但运行小时数日志——深埋在另一个历史数据库中——显示它自 1 月以来一直以额定产能的 130% 运行。

这些上下文信息在 IoT 仪表板中根本不存在。

她调出 30 天 OEE 趋势。4 号产线的可用率从 94% 降至 87%。9 号产线的吞吐量也下降了 6%。二者有关联吗？它们共用一套冷却回路，但这种关系没有在任何系统中建模。她又查看缺陷率。4 号产线的废品率在上周二上升了 2.3%。9 号产线暂时没有异常——但可能只是还没显现。冷却液的推测是错的，还是 9 号产线只是存在滞后？

她给三位主管发了邮件。到上午 11:15，她终于得到了一个有把握的答案。

楼下两层，产线主管 Raj Patel 正在为 7 号产线做同样的分析——但他无法访问分析仪表板。他只能使用一份已经过期三天的 PDF 导出文件。维修技术员 Priya Nair 只想知道，她上周标记的 42 号机器振动问题是否已经恶化。数据确实存在，但她没有查看数据的凭据。她去问 Raj，Raj 再去问 Sarah 的分析师。四小时后，一份 CSV 文件才送达。到那时，Priya 已经开始处理下一张工单。

三个人，三个不同的访问级别，五个彼此断开的系统，以及相同的底层数据。为了得到本应几秒钟就能获得的答案，他们花费数小时进行人工拼接、上下文切换和等待。数据虽然存在，却无法用同一种语言说话。

问题：数据丰富，洞察匮乏

普通企业每天运行五到八个运营和分析系统。每个系统都有各自的登录方式、查询界面和访问模型。当管理者需要跨系统视图——也就是实际驱动决策的那类视图——人就成了集成层。传统 BI 仪表板展示昨天发生了什么。单一 AI 助手可以回答孤立的问题。但两者都无法自主协调整个技术栈，在恰当的时机提供具有上下文、可执行的智能洞察。复杂的 ETL 管道、碎片化的数据存储与访问模式，以及多个 AI 助手和 Agent 的管理，都会为最终用户带来额外挑战。定制化多 Agent 框架理论上可以覆盖完整技术栈，但从零开始构建一个框架需要数月工程工作：自定义连接器、会话隔离、记忆基础设施、安全代码、扩缩容逻辑和编排逻辑——而这一切都发生在回答第一个业务问题之前。

企业不应该仅仅为了询问自身数据的问题，就需要一个工程团队。真正的成本也不是工程时间——而是在正确答案正躺在某个无人有时间查看的系统里时，人们仍然基于陈旧、不完整的信息做出决策。

解决方案：配置，而非代码

Amazon Bedrock AgentCore 颠覆了这一模式。与其从头构建一个自主智能系统，不如对其进行配置。Amazon Bedrock AgentCore 负责处理编排、安全、记忆和扩缩容；你只需提供数据源和业务规则。结果是，Sarah、Raj 和 Priya 都可以用自然语言提问，并从整个技术栈中获得经过综合和个性化处理的答案——无需知道答案中的每一部分分别来自哪个系统。

该模式分为三步：

• 使用预构建 MCP server 连接器连接现有系统——无需编写自定义集成代码。
• 使用自然语言策略规则定义不同人员可以查看哪些内容，Amazon Bedrock AgentCore 会将其转换为执行逻辑。
• 使用自然语言提问，让 Amazon Bedrock AgentCore 编排其余流程。

架构概览

该架构分为五层，每一层都建立在下一层之上。这种分层结构是有意设计的：它将面向用户的智能能力、编排、工具执行和数据访问相互分离，使每一层都可以独立扩缩容和替换。

用户位于顶层，Amazon Bedrock AgentCore 是架构重心，预构建 MCP server 连接器位于中间，数据基础设施构成底座。每次用户交互都会先经过 Amazon Bedrock AgentCore——依次通过身份验证、策略、记忆和 Agent——再访问数据源。

图 1 —— 使用 Amazon Bedrock AgentCore 的自主 BI 架构

该架构采用分层设计：用户通过 Amazon Bedrock 以自然语言发起查询，用于意图分类和响应综合；随后请求进入 Amazon Bedrock AgentCore，由 Agent 在隔离运行时、网关、身份与策略执行、持久化记忆以及受治理的工具注册表之间编排执行。在选择并路由至数据连接器之前，Agent 会查询由 SageMaker Data Catalog 驱动的语义层。该层会暴露正确的数据源，使 Agent 无需硬编码逻辑即可了解企业中有哪些数据以及数据位于何处。获得这些元数据后，Agent 会将查询路由至适当的预构建 MCP server 连接器——设备、IoT 遥测、供应链、分析或自定义低代码连接器；这些连接器再从底层基础设施中提取数据，包括 SageMaker Lakehouse、Redshift、S3 Tables、OpenSearch 或 Aurora。将元数据发现与数据检索分离，意味着新数据源可以通过在 Data Catalog 中注册来接入，而不是编写自定义集成代码，从而仅凭配置就能保持系统的可扩展性。完整的可运行实现已在 GitHub 提供。

工作原理

架构中的每一层都对应一组不同的能力。以下将结合 Sarah、Raj 和 Priya 的实际体验，逐一介绍各个组件。

数据基础设施

数据基础由 Amazon SageMaker Lakehouse 构建。这是一种与 Apache Iceberg 完全兼容的开放湖仓架构，能够统一 Amazon S3 数据湖中的数据（包括 S3 Tables）、Amazon Redshift 数据仓库中的数据，以及通过零 ETL 集成连接的运营数据存储。Agent 通过预构建和自定义 MCP server 的组合访问这些统一数据：

预构建 MCP server（可直接配置）： Amazon Redshift MCP server——用于供应链库存和 OEE 分析的数据仓库查询；AWS S3 Tables MCP server——S3 中采用 Iceberg 格式的历史数据；Amazon Aurora PostgreSQL MCP server——用于设备注册表和维护历史的运营数据。

自定义 MCP server（适用于没有预构建选项的服务）： 自定义 MCP server（适用于没有预构建选项的服务）- IoT Telemetry MCP server——查询 Amazon Timestream 中的实时传感器时序数据（振动、温度、压力），采用 FastMCP 框架构建。Quality Analytics MCP server——查询 Amazon OpenSearch Serverless，以进行缺陷模式匹配，并对质量检验文档执行语义搜索。Semantic Layer MCP server——查询 SageMaker Data Catalog 元数据，帮助 Agent 在调用数据源前发现相关数据源。

为 Timestream 等服务构建自定义 MCP server，只需要定义工具接口并委托给 AWS SDK：

from mcp.server import FastMCP
mcp = FastMCP("IoT Telemetry Server", port=8002)

@mcp.tool(description="Get sensor readings for a specific machine")
def get_sensor_readings(machine_id: int, metric: str = "temperature", days: int = 7) -> str:
    # Validate input, query Timestream via boto3, return JSON
    ...

完成注册后，自定义 MCP server 的行为与预构建服务器完全相同——Agent 通过相同的 MCP 协议发现其工具，并以同样的方式调用它们。这意味着企业可以从适用于常见服务的预构建连接器开始，再逐步为专用系统或遗留系统添加自定义服务器，而无需更改 Agent 或编排逻辑。

MCP server：连接数据的预构建连接器

模型上下文协议（Model Context Protocol，MCP）是一项开放标准，定义了 AI Agent 如何发现和调用工具。在该架构中，业务的每个领域——设备状态、IoT 遥测、供应链、质量管理——都由专用 MCP server 表示。每台服务器都会公开一组带类型的工具：get_equipment_status、detect_anomaly、check_parts_inventory。Agent 调用这些工具的方式，就像开发者调用 API 一样。对企业而言，其实用之处在于你无需从头构建这些服务器。Amazon Bedrock AgentCore 为常见系统提供预构建 MCP 连接器，包括 Amazon Redshift、Amazon Aurora、Amazon OpenSearch，以及通过 OAuth 接入的第三方系统。对于专有或自定义系统，Amazon Bedrock AgentCore Runtime 上的低代码 MCP server 模板可将工作量从开发降至配置。

连接选项覆盖企业系统的完整范围：

• 通过 Amazon SageMaker Catalog 访问语义存储，用于正确数据源的识别、选择和查询。
• 关系数据库：Amazon Aurora、RDS，用于接入运营数据。
• Amazon MSK 等流式服务，用于将实时 IoT 传感器数据流和事件流接入 SageMaker Lakehouse。
• 向量存储：Amazon OpenSearch Service，用于支持语义搜索、通过 Amazon MSK 进行实时向量嵌入，以及对 Amazon S3 中非结构化数据执行混合关键词-向量查询。
• 具备零 ETL 功能的数据仓库和湖仓，可将各种数据存储中的数据复制到 SageMaker Lakehouse 内的 Amazon S3 Tables/Amazon Redshift，从而存储跨多年的历史记录。
• 第三方 SaaS：通过 Amazon Bedrock AgentCore Gateway OAuth 集成访问 REST 或 GraphQL API，例如 Salesforce、SAP、ServiceNow。
• MCP server 可以运行在无状态模式下（默认，每次调用相互独立），也可以运行在有状态模式下，以支持需要在会话内保留中间结果的多步骤操作。

MCP server：优势与权衡

优势 松耦合——每台 MCP server 都独立部署。更新 CRM 连接器不会影响 IoT 连接器。领域封装意味着每台服务器都拥有自己的模式和身份验证上下文。面向 AWS 原生服务的预构建连接器意味着，大多数企业可以在数小时内连接其核心数据源。开放的 MCP 标准可避免供应商锁定——兼容 MCP 的服务器可与 Amazon Bedrock AgentCore 协同工作。

权衡 没有预构建连接器的自定义系统或遗留系统需要进行低代码模板配置，这会增加一次性的设置步骤。有状态 MCP server 会引入会话亲和性要求，因此需要为水平扩展部署进行谨慎规划。每增加一台 MCP server，就会多出一个需要监控和版本管理的端点。可考虑使用网关连接带有或不带预构建连接器的 MCP server。

Amazon Bedrock AgentCore Gateway：统一入口与智能路由

Gateway 是所有 Agent 到工具调用流经的单一入口。当注册新的 MCP server 时，Gateway 会执行协议握手，并索引其可用工具——包括工具名称、输入模式和说明。Agent 无需知道 MCP server 的地址，它只需通过 Gateway 按名称调用工具，Gateway 会将请求路由至相应服务器。Gateway 实施了三级缓存策略，旨在降低重复查询的延迟。组织范围缓存保存所有用户共享的参考数据——设备目录记录、产品列表、阈值——并每日刷新。用户范围缓存保存特定用户的近期查询结果，并遵循其访问上下文。策略引擎决定哪些响应可以跨用户共享，哪些必须保持隔离。对于 Precision Manufacturing 而言，这意味着工厂经理关于整体设备群状态的查询可部分由缓存提供服务，而 Priya 关于 42 号机器的查询则限定在她自己的范围内。

Amazon Bedrock AgentCore Runtime：为每位用户提供隔离执行环境

Amazon Bedrock AgentCore Runtime 将 Agent 部署到 Firecracker microVM 环境中，以提供隔离和安全性——这也是 AWS Lambda 和 AWS Fargate 所采用的技术——无需管理服务器，并支持自动扩缩容。当 Sarah 提交查询时，Runtime 会启动一个专用 microVM。Raj 的会话在另一个 microVM 中运行，Priya 的会话则在第三个 microVM 中运行。没有共享文件系统、没有共享内存、没有共享网络。会话结束后，microVM 会被销毁。多租户是运行时属性，而不是软件约定。

在我们的实现中：deploy/agentcore/deploy_all.py 配置完整堆栈——Cognito 身份、带 Lambda 工具目标的 Gateway、Cedar 策略，以及请求/响应拦截器。Amazon Bedrock AgentCore Gateway 随后会自动处理会话隔离、身份传播和策略执行，无需对 Agent 代码本身作出更改。

Amazon Bedrock AgentCore Identity：可传播的身份验证

Amazon Bedrock AgentCore Id

A Monday morning problem

Sarah Chen manages 12 assembly lines and 2,000 machines. Before her 10 AM production review, she needs one answer: Which lines need attention this week?

Simple question. Painful journey.

She starts in the IoT dashboard. Line 4’s motor temperature is running 12°C above baseline — has been for three days. Calibration drift or bearing failure? The dashboard shows signals, not causes. So she pivots to the ERP system for maintenance history. Machine 42 had a bearing replaced eight months ago. Warranty says 12 months, but the operating hours log — buried in a separate historian database — shows it’s been running at 130% rated capacity since January.

That context exists nowhere in the IoT dashboard.

She pulls 30-day OEE trends. Line 4’s availability dropped from 94% to 87%. Line 9’s throughput also dipped 6%. Related? They share a coolant loop, but that relationship isn’t modeled in any system. She checks defect rates. Line 4’s scrap jumped 2.3% last Tuesday. Line 9 shows nothing — yet. Is the coolant theory wrong, or is Line 9 just lagging?

She emails three supervisors. By 11:15 AM, she finally has a confident answer.

Two floors down, Line Supervisor Raj Patel is doing the same exercise for Line 7 — except he can’t access the analytics dashboard. He’s working from a PDF export that’s three days stale. Maintenance Technician Priya Nair just wants to know if the vibration she flagged on Machine 42 last week has gotten worse. The data exists. She doesn’t have credentials to see it. She asks Raj. Raj asks Sarah’s analyst. A CSV arrives four hours later. By then, Priya has moved on to her next work order.

Three people. Three different access levels. Five disconnected systems. The same underlying data. Hours of manual stitching, context-switching, and waiting—for answers that should take seconds. The data existed but it just couldn’t speak in one voice.

The problem: Data-rich, insight-poor

The average enterprise runs five to eight operational and analytical systems daily. Each has its own login, its own query interface, and its own access model. When a manager needs a cross-system view — the kind that actually drives decisions — a human being becomes the integration layer. Traditional BI dashboards show what happened yesterday. Single AI assistants can answer isolated questions. But neither can autonomously coordinate across your entire technology stack to deliver contextual, actionable intelligence exactly when needed. Managing complex ETL pipelines, fragmented data stores and access patterns, and multiple AI assistants and agents lead to additional challenges for end users. Custom multi-agent frameworks can theoretically span the full stack, but building one from scratch requires months of engineering: custom connectors, session isolation, memory infrastructure, security code, scaling logic, and orchestration logic — all before the first business question gets answered.

Businesses should not need an engineering team just to ask questions about their own data. And the real cost is not engineering time — it is the decisions made on stale, partial information while the right answer was sitting in a system nobody had time to check.

The solution: Configuration, not code

Amazon Bedrock AgentCore flips the model. Instead of building an autonomous intelligence system from the ground up, you configure one. Amazon Bedrock AgentCore handles orchestration, security, memory, and scaling. You bring your data sources and your business rules. The result is a system where Sarah, Raj, and Priya can each ask natural language questions and get synthesized and personalized answers from across the entire technology stack — without knowing which system provided which piece of the answer.

The model is three steps:

• Connect your existing systems using pre-built MCP server connectors — no custom integration code.
• Define who can see what using plain-English policy rules that Amazon Bedrock AgentCore translates into enforcement logic.
• Ask questions in natural language and let Amazon Bedrock AgentCore orchestrate the rest.

Architecture overview

The architecture is organized into five layers, each building on the one below. The layered structure is intentional: it separates user-facing intelligence from orchestration, from tool execution, from data access — keeping each layer independently scalable and replaceable.

Users at the top, Amazon Bedrock AgentCore as the center of gravity, pre-built MCP server connectors in the middle, and the data infrastructure at the foundation. Every user interaction flows through Amazon Bedrock AgentCore — through authentication, policy, memory, and the Agent — before reaching data sources.

Figure 1 — Autonomous BI architecture using Amazon Bedrock AgentCore

The architecture follows a layered design, where a user queries in natural language through Amazon Bedrock for intent classification and response synthesis, then into Amazon Bedrock AgentCore, where the agent orchestrates execution across isolated run-times, a gateway, identity and policy enforcement, persistent memory, and a governed tool registry. Before selecting and routing to data connectors, the agent looks up the Semantic Layer powered by SageMaker Data Catalog, which exposes the right data sources — enabling the agent to understand what data exists across the enterprise and where it resides without hard-coded logic. Equipped with this metadata, the agent routes the query to the appropriate pre-built MCP server connector (equipment, IoT telemetry, supply chain, analytics, or custom low-code), which in turn pulls data from the underlying infrastructure — SageMaker Lakehouse, Redshift, S3 Tables, OpenSearch or Aurora. This separation of metadata discovery from data retrieval means new sources can be on-boarded by registering them in the Data Catalog rather than writing custom integration code, keeping the system extensible through configuration alone. The complete working implementation is available on GitHub.

How it works

Each layer of the architecture corresponds to a distinct set of capabilities. Below is a guided tour through each component, grounded in what Sarah, Raj, and Priya actually experience.

Data infrastructure

The data foundation is built on Amazon SageMaker Lakehouse — an open lakehouse architecture fully compatible with Apache Iceberg that unifies data across Amazon S3 data lakes (including S3 Tables), Amazon Redshift data warehouses, and operational data stores connected through zero-ETL integrations. The agent accesses this unified data through a combination of pre-built and custom MCP servers:

Pre-built MCP servers (ready to configure): Amazon Redshift MCP server — warehouse queries for supply chain inventory and OEE analytics AWS S3 Tables MCP server — Iceberg-format historical data in S3 Amazon Aurora PostgreSQL MCP server — operational data for equipment registry and maintenance history

Custom MCP servers (for services without a pre-built option): Custom MCP servers (for services without a pre-built option)- IoT Telemetry MCP server — queries Amazon Timestream for real-time sensor time-series (vibration, temperature, pressure). Built with FastMCP framework. Quality Analytics MCP server — queries Amazon OpenSearch Serverless for defect pattern matching and semantic search across quality inspection documents. Semantic Layer MCP server — queries SageMaker Data Catalog metadata to help the agent discover which data sources are relevant before calling them.

Building a custom MCP server for a service like Timestream requires only defining the tool interface and delegating to the AWS SDK:

from mcp.server import FastMCP
mcp = FastMCP("IoT Telemetry Server", port=8002)

@mcp.tool(description="Get sensor readings for a specific machine")
def get_sensor_readings(machine_id: int, metric: str = "temperature", days: int = 7) -> str:
    # Validate input, query Timestream via boto3, return JSON
    ...

Once registered, a custom MCP server behaves identically to a pre-built one — the agent discovers its tools through the same MCP protocol and calls them the same way. This means enterprises can start with pre-built connectors for common services and add custom servers incrementally for specialized or legacy systems, without changing the agent or the orchestration logic.

MCP servers: Pre-built connectors to your data

The Model Context Protocol (MCP) is an open standard that defines how AI agents discover and invoke tools. In this architecture, each domain of your business — equipment status, IoT telemetry, supply chain, quality management — is represented by a dedicated MCP server. Each server exposes a set of typed tools: get_equipment_status, detect_anomaly, check_parts_inventory. The agent calls these tools, the way a developer calls an API. What makes this practical for enterprises is that you do not build these servers from scratch. Amazon Bedrock AgentCore provides pre-built MCP connectors for common systems: Amazon Redshift, Amazon Aurora, Amazon OpenSearch, and third-party systems through OAuth. For proprietary or custom systems, low-code MCP server templates on Amazon Bedrock AgentCore Runtime reduce the effort to configuration rather than development.

Connectivity options span the full spectrum of enterprise systems:

• Semantic store through Amazon SageMaker Catalog for right data source identification, selection and querying.
• Relational databases: Amazon Aurora, RDS. Which bring in the operational data.
• Streaming services like Amazon MSK for real-time IoT sensor feeds and event streams to SageMaker Lakehouse.
• Vector stores: Amazon OpenSearch Service for supporting semantic search, real-time vector embedding with Amazon MSK, and hybrid keyword-vector queries on unstructured data in Amazon S3.
• Data Warehouses and Lakehouses with Zero ETL features to replicate data from various data stores to Amazon S3 Tables/Amazon Redshift in SageMaker Lakehouse. Thus storing multi-year historical records.
• Third-party SaaS: REST or GraphQL APIs via the Amazon Bedrock AgentCore Gateway OAuth integration (for example, Salesforce, SAP, ServiceNow).
• MCP servers can run in stateless mode (default, each call is independent) or stateful mode for multi-step operations that need to maintain intermediate results within a session.

MCP servers: Advantages and trade-offs

Advantages Loose coupling — each MCP server is deployed independently. Updating the CRM connector does not touch the IoT connector. Domain encapsulation means each server owns its schema and authentication context. Pre-built connectors for AWS-native services mean most enterprises can connect their core data sources within hours. The open MCP standard avoids vendor lock-in — MCP-compatible servers work with Amazon Bedrock AgentCore.

Trade-offs Custom or legacy systems without a pre-built connector require a low-code template configuration, which adds a one-time setup step. Stateful MCP servers introduce session affinity requirements that need careful planning for horizontally scaled deployments. Each additional MCP server is one more endpoint to monitor and version. Consider using gateway to connect to MCP servers with or without pre-built connectors.

Amazon Bedrock AgentCore Gateway: Unified entry point and intelligent routing

The Gateway is the single entry point through which every agent-to-tool call flows. When a new MCP server is registered, the Gateway performs a protocol handshake and indexes its available tools — their names, input schemas, and descriptions. The agent does not need to know the address of a MCP server. It calls tools by name through the Gateway, which routes the request to the appropriate server. The Gateway implements a three-tier caching strategy designed to reduce latency for repeat queries. Organization-scoped cache holds reference data that all users share — equipment catalog records, product lists, threshold values — and refreshes daily. User-scoped cache holds recent query results that are personal to a specific user and respects their access context. The Policy engine determines which responses can be shared across users and which must remain isolated. For Precision Manufacturing, this means that a Plant Manager’s query about overall fleet status can be partially served from cache, while Priya’s query about Machine 42 is scoped to her.

Amazon Bedrock AgentCore Runtime: Isolated execution for every user

Amazon Bedrock AgentCore Runtime deploys agents to Firecracker microVM environments delivering isolation and security — the same technology that powers AWS Lambda and AWS Fargate — with no servers to manage and automatic scaling. When Sarah submits her query, Runtime spins up a dedicated microVM. Raj’s session runs in a separate microVM. Priya’s in a third. No shared filesystem, no shared memory, no shared networking. When the session ends, the microVM is destroyed. Multi-tenancy is a runtime attribute, not a software convention.

In our implementation : deploy/agentcore/deploy_all.py provisions the full stack — Cognito identity, Gateway with Lambda tool targets, Cedar policies, and request/response interceptors. Amazon Bedrock AgentCore Gateway then handles session isolation, identity propagation, and policy enforcement automatically, with no changes to the agent code itself.

Amazon Bedrock AgentCore Identity: Authentication that propagates

Amazon Bedrock AgentCore Identity provides robust identity and access management so that agents can access resources or tools either on behalf of users or themselves, with pre-authorized user consent, minimizing the need for custom access controls and identity infrastructure development. Identity integrates with your existing providers (Okta, IAM, Cognito, OAuth 2.0 systems) and propagates user context through the entire call chain using the Mcp-Session-Id header. Two flows are supported: agent-level access (service-to-service) and user-delegated access (agent acts on behalf of a specific user with their scoped token). In practice for Precision Manufacturing: – Sarah’s token (from Cognito) grants access to all three plants, all 12 lines. – Raj’s token scopes to Plant 2, Line 7 only. – Priya’s token scopes to Machine 41-45. These restrictions come from the IdP. Amazon Bedrock AgentCore propagates them through the call chain and enforces them automatically. If Raj’s scope changes in Cognito, the system reflects it immediately without code changes.

In our implementation : src/identity/models.py defines three user identities with explicit scopes. In production, these come from Cognito claims that AgentCore propagates automatically.

Amazon Bedrock AgentCore Policy: Authorization in plain English

Policy in Amazon Bedrock AgentCore integrates with Gateway to intercept every tool call in real time, verifying agents stay within defined boundaries. Teams create policies using natural language that automatically convert to Cedar — the AWS open-source policy language — with automated reasoning that validates policies for completeness before deployment. Policy enforcement happens at the Gateway level, intercepting every tool call before execution. Rules operate across multiple dimensions: user role, geographic scope, data classification, time of day, and specific tool parameters. A policy might read: “Line supervisors can call get_equipment_status only for lines within their assigned plant.” When Raj asks about Line 4, the Gateway evaluates his identity against this rule and returns a deny decision before the MCP server is ever called. Every decision is logged to AWS CloudTrail.

In our implementation: Cedar policies deployed to the Amazon Bedrock AgentCore Gateway enforce fine-grained access at the infrastructure level — before Lambda tool targets execute. When Raj queries Line 4, the Gateway’s Policy Engine evaluates his JWT claims against the Cedar rules and returns a deny. The MCP server is not contacted. For local development without a deployed Gateway, src/identity/gateway_hook.py simulates this enforcement using Strands Agents’ BeforeToolCallEvent hook.

Sequence diagrams: Access control flow

The following diagrams illustrate the end-to-end access control flow implemented by Amazon Bedrock AgentCore Gateway. They show how user identity (through JWT claims from Cognito) flows through the REQUEST Interceptor, gets evaluated by the Cedar Policy Engine, and determines whether an MCP tool is invoked or the request is denied — all before data leaves the system.

Diagram 1: End-to-end access control sequence

This UML-style sequence diagram shows the complete lifecycle of a request, from user authentication through Cognito, to the agent’s LLM reasoning, through the Amazon Bedrock AgentCore Gateway’s enrichment and authorization layers, and finally to tool execution or denial.

Key observations:

• Authentication: Cognito issues a JWT with custom claims (role, line_scope, plant_scope, equipment_scope) that encode the user’s data boundaries.
• Enrichment: The REQUEST Interceptor decodes the JWT and injects user_context into the tool call arguments — the agent/LLM does not see or control this step.
• Authorization: Cedar evaluates the enriched request against policies. A permit_all baseline allows access, while forbid_* rules check whether the requested parameter falls within the user’s scope.
• Execution vs Denial: If Cedar allows, the Gateway forwards to the Lambda tool target. If Cedar denies, the MCP server is not invoked — avoiding data exposure.
• Synthesis: The agent receives either tool results or a deny message, and composes a natural-language response. On denial, it explains the boundary and suggests alternatives within scope.

Figure 2 — Amazon Bedrock AgentCore Gateway fine-grained access control sequence diagram

Three personas — same interface, different access

This comparison diagram demonstrates how the same agent interface produces different outcomes for different users. Each row represents a persona with a horizontal left-to-right flow through the system components. Personas:

• Sarah Chen (Plant Manager) — Full access. Queries are not denied because her role has the ‘has_full_access’ attribute, bypassing all forbid rules.
• Raj Patel (Line Supervisor) — Scoped to Line 7, Plant 2. Attempts to access Line 4 data are denied at the Cedar layer. The Lambda tool is not invoked.
• Priya Nair (Maintenance Technician) — Scoped to Machines 41-45. Attempts to access Machine 72 are denied. The agent suggests checking Machine 42 instead.

Amazon Bedrock AgentCore components highlighted: The purple-shaded region in the diagram encloses the two Amazon Bedrock AgentCore-managed components: the Gateway (with its REQUEST Interceptor) and the Cedar Policy Engine. These operate server-side, external to the agent process, making sure that neither the LLM nor application code can bypass authorization.

Figure 3 — Same agent, same interface, different data access (Amazon Bedrock AgentCore Gateway enforces Cedar policies at the parameter level)

Key security properties illustrated

• Deterministic Authorization: Cedar evaluation is pure logic — same input produces the same output. The LLM cannot influence the policy decision regardless of prompt injection.
• Fail-Secure: If the interceptor crashes, context is not injected. Cedar has nothing to permit, so the result is DENY (deny-by-default).
• MCP Server Isolation: Denied requests do not reach the MCP server. The tool Lambda is not invoked. Data processing does not occur. Compute is not wasted.
• Graceful Degradation: The agent receives the deny message as a tool result and intelligently responds: explains what it CAN access, suggests alternatives, and does NOT retry the denied call.

Amazon Bedrock AgentCore Memory: Context that persists

Amazon Bedrock AgentCore Memory enables agents to learn and adapt from experiences, building knowledge over time, with support for episodic memory that creates more human-like interactions. Memory operates at two levels: Short-term memory captures turn-by-turn context within a single session. When Priya asks “Show me vibration trends on Machine 42,” then follows with “Compare that to last week,” the second question is understood in context without repeating the machine ID. Long-term memory persists selected insights across sessions. Amazon Bedrock AgentCore automatically extracts and stores preferences, recurring query patterns, and session summaries organized into namespaces:

• User-scoped: Priya’s preferred units, her assigned equipment list.
• Team-scoped: The maintenance team’s standard anomaly thresholds.
• Organization-scoped: Equipment catalog, site codes, product definitions. Retrieval passes through Policy — even if an insight exists in long-term memory, it will not surface to a user who lacks access to the underlying data.

In our implementation: src/memory/manager.py provides two memory tiers — SessionMemory for turn-by-turn context within a conversation, and MemoryManager for long-term insights organized into user-scoped and team-scoped namespaces. Priya’s long-term memory retains last week’s Machine 42 vibration baseline (3.8 mm/s), so when she asks “has it gotten worse?”, the agent compares against that stored reading without repeating context. In production, Amazon Bedrock AgentCore Memory persists these insights across sessions and enforces policy on retrieval — a user only sees memories derived from data they’re authorized to access.

Amazon Bedrock Agent Registry enables organizations to discover, share, and reuse agents, tools, and agent skills across the organization through a governed catalog with publish-and-approve workflows. New MCP servers enter the Registry in draft state. Administrators review and approve them. Once approved, the agent automatically discovers the new tools on the next invocation — no redeployment needed. The Registry also enables versioning: an updated connector can be staged alongside the current version, tested, and promoted without disrupting live sessions. This governance model means the system grows incrementally. New data sources, new tools, and new connectors are added through a structured publish-and-approve workflow rather than code changes to the orchestration layer.

In our implementation: The Semantic Layer MCP server (src/servers/semantic_layer_server.py) maintains a registry of data sources — each entry declares its available tools, glossary terms, data origin, and refresh frequency. The agent calls discover_data_sources first, which keyword-matches against the catalog and returns ranked recommendations. Onboarding a new data source means adding one entry to the DATA_SOURCES registry — no agent logic changes, no redeployment of other servers.

Three users, one system, three different views

The real test of any multi-tenant system is not whether it works for one user — it is whether it works correctly for many users simultaneously, with each seeing exactly what they should and nothing more. Here is how the same Amazon Bedrock AgentCore deployment serves Sarah, Raj, and Priya differently.

Sarah asks: “Which assembly lines need attention this week?”

Amazon Bedrock AgentCore Runtime creates a microVM for Sarah’s session. The Gateway authenticates her through Okta — role: Plant Manager, scope: all associated assembly lines. The agent classifies the intent as multi-source and operational. It calls the Equipment MCP Server (get_equipment_status, all plants) and the IoT Telemetry MCP Server (detect_anomaly, all lines) in parallel. Policy evaluates each call: Sarah’s role permits all of them. Memory recalls that Sarah prefers severity-ranked output. The synthesized response — a ranked list of assembly lines with supporting evidence from both equipment and sensor data — arrives in seconds.

Raj asks: “What’s the current status of Line 7?”

Raj’s session runs in a separate microVM. His Okta token scopes him to Plant 2, Line 7 only. The agent routes the same tool calls to the Equipment and IoT MCP servers — but Policy intercepts the calls and enforces the scope restriction. Line 7 data returns. Lines 1 through 6 and 8 through 12 do not. The Gateway’s user-scoped cache serves part of this response from Raj’s recent query history, reducing latency. Raj sees a precise, line-specific status report — not because the system filtered a global result, but because the data was not retrieved for lines outside his scope.

Priya asks: “Has the vibration on Machine 42 gotten worse since last week?”

Priya is scoped to her assigned equipment. The agent calls the IoT Telemetry MCP Server with machine_id=42 and metric=vibration. Policy confirms Machine 42 is in Priya’s assignment list. Amazon Bedrock AgentCore Memory surfaces a summary from her session last week when she asked about the same machine, enabling a week-over-week comparison without Priya having to specify the timeframe. The response includes the trend, the delta, and a maintenance recommendation — all in plain language. Throughout all three interactions: three isolated microVMs, three distinct policy evaluations, three personalized memory contexts. Users can’t see each other’s data. No configuration was needed to achieve this separation — it is the default behavior of the system.

What makes this architecture different

Several aspects of this approach are worth calling out explicitly, because they represent meaningful departures from how enterprise AI systems have traditionally been built.

Configuration is the interface for the business. A business analyst can define a new access policy in plain English. A data engineer can register a new MCP connector through the Registry UI. Neither requires changes to the orchestration layer or a deployment cycle. The system grows through configuration, not code.

The MCP open standard helps prevent lock-in. Because MCP servers follow an open protocol, MCP-compatible tools or services can be registered with Amazon Bedrock AgentCore — including open-source connectors, third-party integrations, and future AWS-native services. The orchestration layer does not care where a tool comes from, only that it follows the protocol.

The Registry compounds growth. Adding a new MCP server connector does not require changes to the agent, updates to routing logic, or redeployment of existing components. Each new connector increases the system’s intelligence automatically. Engineering effort invested in new connectors benefits everyone who uses the system.

The system gets smarter over time. Amazon Bedrock AgentCore Memory accumulates user preferences, recurring patterns, and session summaries. Combined with Gateway caching that recognizes repeated query shapes, response times improve as the system learns what each user typically needs and where to find it.

Security is a design principle, not an afterthought. In most custom multi-agent implementations, data isolation is enforced at the application layer through query filters and role checks scattered across the code base. In Amazon Bedrock AgentCore, isolation is enforced at the infrastructure layer — by the microVM boundary and by the Policy engine intercepting every tool call. A misconfigured agent can’t accidentally return data it should not.

Looking ahead: Extensibility

The architecture described here is a foundation with several natural extension points.

• The Agent-to-Agent (A2A) protocol, an emerging open standard, will allow Amazon Bedrock AgentCore agents to collaborate with agents running on other infrastructure or in other organizations — enabling supply chain intelligence that spans multiple enterprises without exposing underlying data.
• Multi-modal interaction is a near-term addition. A voice interface on the factory floor — where Priya cannot type a query while operating equipment — connects to the same Amazon Bedrock AgentCore backend. The answer comes back as spoken language through the same MCP toolchain.
• Proactive agents extend the model beyond query-response. Rather than waiting for Sarah to ask which lines need attention, an Amazon Bedrock AgentCore agent monitors incoming IoT data continuously and surfaces an alert when a threshold is crossed — before the 10 AM meeting.
• As the Registry accumulates routing history, the agent can learn which tools and data sources each user typically needs and pre-fetch relevant context — reducing time-to-insight further as the system matures.

Summary

It is now 9:58 AM on that same Monday. Sarah types a question into the chat interface on her laptop: “Which assembly lines need attention this week?” By 10:00 AM, she has a ranked list with root-cause context drawn from equipment records, live sensor data, and maintenance history. The production review starts on time. Line 9 is addressed before the shift supervisor even sits down. Raj gets his Line 7 status in the same session, without visibility into Sarah’s view. Priya gets her Machine 42 trend comparison, with the memory of last week’s baseline already loaded. Amazon Bedrock AgentCore — through the combination of MCP server connectors, Runtime isolation, Gateway routing, Identity propagation, Policy enforcement, Memory persistence, and Registry governance — makes this possible as a configured system rather than a custom-built one. The business describes what it wants. The system handles how it works. The future of enterprise intelligence is conversational, autonomous, secure, and available today on AWS. For teams ready to move from data-rich to insight-ready, this is where it starts.

Code samples

The full implementation with Amazon Bedrock Agent Core Cedar policies, Gateway interceptors, MCP tool servers, and Strands agent code is available in the sample-autonomous-business-insights repository. You can explore the architecture, run it locally, or adapt it for your own fine-grained access control needs.

---

About the authors

Sudhanshu Hate

Sudhanshu is a Principal AI/ML Architect at AWS, where he helps customers adopt and scale Agentic AI and Generative AI on Amazon Bedrock. His work spans the full depth — from defining AI strategy with CXOs to designing multi-agent systems, fine-tuning foundation models, building RAG pipelines, and establishing GenAIOps practices. Over the last two years, he has helped several customers from Agentic AI experimentation to production workloads. With over a decade exclusively in AI/ML, Sudhanshu brings a practitioner’s lens to customer advisory — he architects it, builds it, and stays until it ships. He holds 2 US patents, has published 20+ papers on AI, and delivered 200+ technical talks on AI.

Anirudh Chawla

Anirudh is an Analytics Solution Architect at AWS. He helps organization empowers businesses to harness their data effectively through AWS’s analytics solution. His interest lies in building highly available distributed systems.

Annie Mattoo

Annie is a Sr. Analytics Specialist at AWS, bringing over 15+ years of expertise in helping customers with their DATA & AI journeys. She has successfully led customer teams to seamlessly adopt AWS Data & AI services and has worked with Fortune 500 customers across the globe in her previous roles.