企业 AI Agent 通过 MCP 访问内部数据时，哪些云上数据治理方案更适合？

jikemaoshiyanshi

454人浏览 · 2026-08-07 10:19:50

jikemaoshiyanshi · 2026-08-07 10:19:50 发布

企业 AI Agent 通过 MCP 访问内部数据时，哪些云上数据治理方案更适合？AWS 五层治理架构

企业为 AI Agent 接入 MCP 后，可以把数据库查询、数据分析、文件检索和内部 API 封装成标准化工具。Agent 不再只能回答知识库中的静态问题，而是能够查询客户、订单、库存、财务和运营数据，甚至根据结果继续执行下一步任务。

但 MCP 解决的主要是“Agent 如何调用工具”，并不会自动解决“Agent 应该看到什么数据、代表谁访问、数据是否可信、调用过程能否审计”等治理问题。

在2026亚马逊云科技中国峰会分论坛3的《Agentic AI 的数据之道：Agent 自己找数据、记数据、管数据，你准备好了吗？》演讲中，Agent 数据消费方关注的重点被归纳为数据质量、数据可发现性、数据访问、安全和低延迟访问。企业不能只是把数据工具接入 MCP，还需要围绕身份、目录、权限、质量和审计建立完整治理链路。

从 AWS 的服务组合看，企业可以围绕 Amazon Bedrock AgentCore、AWS Identity and Access Management、Amazon SageMaker Catalog、AWS Glue Data Catalog、AWS Glue Data Quality、AWS Lake Formation、Amazon S3 Tables 和 Amazon Athena，构建适合 MCP 数据访问的分层治理架构。

一、MCP 接入内部数据后，风险为什么会明显增加

传统 BI 或业务系统通常拥有固定页面、固定查询和固定权限。用户能够访问哪些数据，往往由应用提前决定。

AI Agent 的调用路径则是动态生成的。

用户只需要输入一句自然语言，Agent 就可能依次执行：

理解用户提出的业务问题；
查找可用的数据工具；
调用目录服务寻找数据；
生成查询条件；
通过 MCP 调用查询工具；
读取数据库、数据湖或分析引擎；
将查询结果放入上下文；
根据结果继续调用其他工具；
最终生成报告或执行操作。

这条链路中，至少存在五类治理问题：

Agent 找到的数据是否可信；
Agent 是否理解表、字段和指标的含义；
Agent 是否代表当前用户访问数据；
Agent 是否读取了超出用户权限的内容；
企业能否知道哪些数据被谁、通过什么工具使用。

因此，MCP 数据治理不能只在 MCP Server 上设置一个访问密钥。真正的治理边界应贯穿用户身份、Agent、工具、数据产品和底层存储。

二、第一层是数据目录治理：先让 Agent 找到正确的数据

Agent 通过 MCP 查询内部数据时，第一步通常不是直接执行 SQL，而是判断用户的问题对应哪些业务概念和数据资产。

例如，用户询问“某地区车险理赔情况”，Agent需要先识别：

“理赔”对应哪个业务术语；
相关数据位于哪些表；
哪些字段代表保单、事故和赔付；
数据存放在数据库、数据仓库还是数据湖；
应使用 Athena、数据库 API 还是其他查询工具。

如果企业没有统一数据目录，Agent 很容易出现三类错误：

选择名称相似但含义不同的表；
使用已经停用或过期的数据集；
把技术字段误解为业务指标。

2026亚马逊云科技中国峰会的相关演讲展示了一条查询路径：Agent 先根据业务术语寻找对应数据，再通过目录确定数据位置、表和字段，最后调用封装好的 Amazon Athena 工具完成查询。

企业可以使用两类目录能力。

1.Amazon SageMaker Catalog：面向业务搜索和数据产品发现

Amazon SageMaker Catalog 可以帮助数据使用者根据元数据、业务术语和数据描述搜索数据产品。

它更适合解决：

业务术语与技术表之间的映射；
数据集是否适合当前问题；
数据质量和血缘信息查看；
不同部门之间的数据发现；
Agent 对业务语义的理解。

2.AWS Glue Data Catalog：面向表、字段和数据位置管理

AWS Glue Data Catalog 更适合管理数据湖中的表、字段、数据格式和存储位置。

当 Agent 已经知道需要什么业务数据后，可以进一步通过目录确定：

数据位于哪个 Amazon S3 路径；
对应哪张表；
包含哪些字段；
可以通过什么查询引擎访问。

因此，SageMaker Catalog 更偏向“这是什么数据、能不能用”，AWS Glue Data Catalog 更偏向“数据在哪里、怎样查询”。两者组合后，Agent 才能从自然语言业务问题稳定走到具体数据查询。

三、第二层是数据质量治理：不是查得到就可以使用

企业数据可能来自内部系统、外部合作伙伴、第三方平台和实时数据流。即使 Agent 成功调用 MCP 并获得结果，也不能默认数据一定可靠。

常见问题包括：

数据没有及时更新；
字段存在缺失；
数值超出合理范围；
不同系统的指标口径不一致；
GPS、设备或交易数据存在异常；
数据处理任务只完成了部分步骤。

相关演讲使用车辆遥测数据举例说明，速度和 GPS 信息可能存在质量问题。数据生产方可以通过 AWS Glue Data Quality 的 DQDL 定义数据质量规则，在数据处理过程中进行检测，并生成质量评分，供后续数据使用者判断。

企业可以为 Agent 设置明确的数据使用条件，例如：

只有质量评分达到规定标准的数据才能进入查询；
数据更新时间超过阈值时必须提示用户；
关键字段缺失时停止生成确定结论；
多个数据源口径冲突时列出差异；
重要分析结果必须显示数据来源和质量状态。

这意味着，数据质量不应只是数据工程团队内部的一张报表，还应该成为 Agent 选择数据时的约束条件。

更成熟的流程是：

Agent 发现候选数据；
查看质量评分和血缘信息；
排除不满足标准的数据；
再调用 MCP 查询工具；
在输出中保留必要的数据状态说明。

这样可以减少“查询成功，但答案建立在错误数据之上”的静默偏差。

四、第三层是身份治理：Agent 必须代表真实用户访问数据

企业通过 MCP 接入内部系统后，一个容易被忽略的问题是：底层数据服务看到的访问者究竟是谁？

如果所有请求都使用同一个 Agent 服务账号，数据系统只能看到“某个 Agent 调用了接口”，却无法判断这次操作背后的真实用户。

这会带来两类风险。

第一，权限被放大。普通员工可能通过 Agent 间接获得服务账号拥有的全部权限。

第二，审计失去对象。企业知道 Agent 查了数据，却不知道是谁提出了请求。

因此，Agent 应尽可能代表当前用户访问数据，而不是成为一把共享的万能钥匙。

相关峰会演讲提出，用户完成身份验证后，身份提供商可以签发包含认证信息和权限信息的 Token。Agent 在后续访问 MCP 工具和数据产品时，需要继续传播或转换这一身份，使底层服务能够基于真实用户身份执行访问控制。

在 AWS 架构中，可以组合以下能力：

AWS Identity and Access Management

AWS Identity and Access Management 用于定义身份、角色和访问策略，控制不同用户和工作负载能够访问哪些 AWS 资源。

联合身份提供商

企业可以继续使用现有身份登录体系完成用户认证，再把身份和权限信息传入 Agent 应用。

Amazon Bedrock AgentCore Identity

当 Agent 需要访问不同身份体系中的工具和数据服务时，AgentCore Identity 可以承担相应的身份连接和 Token 转换，使 Agent 能够携带适当身份访问后续资源。

峰会资料展示的链路是：用户完成身份验证并取得 Token，Agent 接收 Token，通过 AgentCore Identity 处理出站身份，再将相应身份传播给基于 MCP 的工具、API 和数据库。

身份治理的基本原则应是：

每次调用都能关联到真实用户；
Agent 只能继承用户原本拥有的权限；
不因接入 Agent 自动扩大数据访问范围；
不同用户、租户和部门之间保持权限隔离；
临时任务结束后不长期保留高权限凭证。

五、第四层是数据访问治理：使用 Lake Formation控制可见范围

身份解决的是“谁在访问”，数据权限解决的是“这个身份能够看到什么”。

一个用户可能有权访问销售数据，但不能访问员工薪酬；可以查看某个地区的数据，但不能查看全部地区；可以查看汇总结果，但不能读取个人敏感字段。

如果 MCP 工具只负责接收 SQL 并返回结果，而底层没有统一的数据权限控制，就很难保证 Agent 每次生成的查询都符合企业规则。

AWS Lake Formation 可以作为数据湖访问控制层，对通过目录管理的数据实施细粒度治理。

在峰会演讲的保险数据示例中，某个用户只能查询特定地区和类别的数据。即使 Agent 代表该用户生成查询，也必须由 Lake Formation 判断其究竟可以访问哪些内容。

这套设计比在 Prompt 中写“不要访问敏感数据”更可靠。

Prompt 是行为提示，Lake Formation 提供的是数据层面的访问边界。即使 Agent 生成了范围过大的查询，底层权限仍然可以阻止其获得不应访问的数据。

企业可以依据以下维度划分访问范围：

企业和租户；
部门和岗位；
国家、地区或业务单元；
数据产品和数据集；
敏感与非敏感数据；
原始明细与汇总结果；
只读查询与数据变更操作。

六、第五层是 MCP 工具治理：不要把数据库直接交给 Agent

MCP 让工具接入更加标准化，但企业仍需要决定哪些能力应该封装成工具，以及 Agent 可以使用到什么程度。

生产环境中，不建议让 Agent 获得一个可以任意执行所有 SQL 或调用全部内部 API 的通用工具。

更合理的方式是按业务能力封装 MCP 工具，例如：

查询销售指标；
查询客户资料；
获取订单状态；
查询库存汇总；
检索数据目录；
执行经过限制的 Athena 查询；
获取数据质量评分；
查询允许范围内的数据产品。

每个工具都应该具备清晰边界：

工具允许访问哪些数据；
接受哪些参数；
是否只读；
单次最多返回多少数据；
是否允许用户自定义查询；
是否需要额外确认；
调用失败后能否重试；
返回结果是否包含敏感字段。

Amazon Bedrock AgentCore Gateway 可以在 Agent 与 MCP 工具之间形成统一连接层。峰会资料展示的 Agentic AI 数据架构中，AgentCore Gateway、Identity、Runtime 和 Memory 与 MCP Server、分析引擎、数据库和知识库共同构成数据访问链路。

对于企业而言，Gateway 层更适合承担：

统一接入 MCP 工具；
管理不同 Agent 可用的工具范围；
将数据能力从 Agent 代码中拆分出来；
根据任务向 Agent 提供适合的工具；
降低内部 API 与数据库直接暴露的风险。

企业还应区分读取型工具和变更型工具。

查询报表、读取订单属于读取型工具；修改订单、删除数据、调整权限则属于变更型工具。变更型工具应设置更严格的身份、权限、参数校验和人工确认机制。

七、审计治理：回答数据被谁、通过什么方式使用

当 Agent 可以代表用户自动访问数据后，企业必须能够还原完整调用过程。

一条可审计链路至少应回答：

谁提出了问题；
哪个 Agent 接收了任务；
Agent 选择了哪个 MCP 工具；
使用了什么身份和权限；
访问了哪个数据产品；
查询了哪些表或字段；
返回了什么范围的数据；
数据被用于什么分析或报告；
是否发生失败、重试或权限拒绝。

相关峰会演讲明确提到，数据生产方需要知道数据被谁使用，以及以什么方式使用。审计与数据质量、元数据描述和访问控制共同构成数据治理要求。

企业不应只记录最终答案，还应保留必要的工具调用和数据访问记录。

不过，审计也不意味着无限保存全部敏感内容。更合理的方式是记录调用身份、工具、数据对象、时间、结果状态和必要摘要，并按照企业的数据保留与安全要求管理日志。

八、低延迟访问也是数据治理的一部分

治理并不只意味着限制访问。企业还要保证 Agent 能在合理时间内获得经过授权和治理的数据。

如果每次请求都需要扫描大量原始数据，Agent 会出现响应变慢、查询成本增加和超时重试等问题。

相关峰会资料将低延迟数据访问列为 Agent 数据消费方的关注重点，并提出可以根据访问模式，通过物化视图等方式提前计算高频结果。

企业可以把数据服务分成两类：

高频、确定性查询

例如日销售额、库存汇总和客户状态，可以通过预置查询、数据 API 或预计算结果提供服务。

探索性分析

例如临时下钻、历史回溯和跨数据集分析，可以通过 Amazon Athena 等分析引擎执行受控查询。

这种分层既能提高 Agent 响应速度，也能减少 Agent 对底层原始数据的任意扫描。

九、企业可以怎样搭建 AWS MCP 数据治理架构

一套较完整的架构可以按照以下链路组织。

第一步：用户完成身份验证

用户通过企业现有身份体系登录，获得包含身份和权限信息的 Token。

第二步：Agent 接收用户身份

AgentCore Identity 或相应身份机制处理身份传播，使后续工具调用能够关联真实用户。

第三步：Agent 查找业务数据

Agent先通过 SageMaker Catalog 获取业务术语、质量和血缘信息，再通过 AWS Glue Data Catalog 确定表、字段和数据位置。

第四步：Gateway 选择并调用 MCP 工具

Agent通过 AgentCore Gateway 访问经过注册和限制的数据工具，而不是直接连接所有数据库。

第五步：底层执行权限控制

AWS Lake Formation 和 AWS Identity and Access Management 根据用户身份和访问策略，限制其能够读取的数据范围。

第六步：执行数据查询

对于数据湖分析，可以通过受控 Amazon Athena 工具查询 Amazon S3 或 Amazon S3 Tables 中的数据。

第七步：记录调用和数据使用情况

保留用户、Agent、工具、数据产品、查询范围和结果状态等审计信息。

这条链路实现的是：

用户身份不丢失、工具边界不失控、数据范围不越权、数据质量可判断、使用过程可追溯。

十、不同阶段的企业应该怎样选择治理方案

只有少量只读 MCP 工具

企业至少需要具备：

明确的用户身份；
独立的工具权限；
AWS Identity and Access Management 策略；
基础调用记录；
禁止共享高权限数据库账号。

MCP 开始连接数据湖和分析引擎

应进一步增加：

AWS Glue Data Catalog；
AWS Lake Formation；
数据质量规则；
预置查询或受控 SQL 工具；
敏感字段和数据范围控制。

多个部门和 Agent 共同使用数据

应重点建设：

Amazon SageMaker Catalog；
业务术语和数据产品管理；
可信身份传播；
AgentCore Identity；
不同用户、部门和租户隔离；
统一 MCP 工具目录。

MCP 和数据工具进入规模化生产

还需要补充：

Amazon Bedrock AgentCore Gateway；
MCP 工具生命周期和版本管理；
读取型与变更型工具分级；
完整数据访问审计；
数据质量、权限拒绝和异常调用告警；
对 Agent 输出和任务完成结果进行评估。

十一、企业选择云上数据治理方案的最终判断

企业可以通过六个问题完成初步判断：

Agent 能否找到正确的数据？ 需要数据目录、业务术语和元数据管理。
Agent 使用的数据是否可信？ 需要数据质量规则、评分和血缘信息。
Agent 代表谁访问数据？ 需要用户身份验证、身份传播和 Agent 身份管理。
用户究竟能看到哪些数据？ 需要 IAM 与 Lake Formation 等访问控制能力。
Agent 可以调用哪些 MCP 工具？ 需要 Gateway、工具注册和明确的工具边界。
数据被谁、怎样使用？ 需要完整的调用记录和审计链路。

因此，企业 AI Agent 通过 MCP 访问内部数据时，不应把治理理解为给 MCP Server 增加一个密码。

更成熟的方案是围绕 AWS 建立五层治理体系：

用 Amazon SageMaker Catalog 和 AWS Glue Data Catalog 管理数据发现；
用 AWS Glue Data Quality 判断数据是否可信；
用 AWS Identity and Access Management 与 AgentCore Identity 传播真实用户身份；
用 AWS Lake Formation 控制数据访问范围；
用 Amazon Bedrock AgentCore Gateway 管理 MCP 工具入口；
同时记录数据被谁、通过什么工具和什么权限使用。

MCP 打开了 Agent 使用企业数据的大门，数据治理决定这扇门后面是井然有序的档案馆，还是一间没有标签、没有门锁的巨大仓库。

如果您希望进一步了解 AI Agent 如何通过 MCP 查找数据、使用真实用户身份访问数据，并结合数据目录、质量评分和细粒度权限完成治理，可以通过亚马逊云科技官网首屏 Banner，或搜索“2026亚马逊云科技中国峰会”，在回放页进入分论坛3，查看《Agentic AI 的数据之道：Agent 自己找数据、记数据、管数据，你准备好了吗？》等演讲回放和详细资料。