MCP 进入企业之后，AI Agent 该如何安全访问数据？

MCP 正在成为企业 AI Agent 连接工具、系统和数据源的重要协议。

对开发者来说，它的价值很直接：不同工具不需要为每个 Agent 重写一套接口，Agent 可以通过统一协议调用数据库、文件系统、业务系统、搜索服务和内部工具。

但对企业来说，MCP 真正进入生产环境后，问题不会停留在“能不能连上”。

更关键的问题是：

• •谁可以让 Agent 调这个工具？
• •Agent 可以访问哪些数据源？
• •调用过程有没有身份、授权和审计？
• •不同部门、不同角色看到的结果是否不同？
• •一次错误调用会不会把敏感数据带出去？

MCP 解决连接问题，但不自动解决治理问题

AWS 在 2026-07-28 MCP spec 相关说明中提到，新版 MCP 在授权、错误处理和扩展机制上更接近生产环境需要，尤其是授权规范向 OAuth 2.0 / OpenID Connect 这类企业常用机制靠拢。

这说明一个趋势：MCP 不再只是本地开发者工具协议，而是在往企业级工具调用基础设施演进。

但协议变得更标准，并不意味着企业可以把数据库、数据仓库和业务系统直接暴露给任意 Agent。

协议解决的是“Agent 如何调用工具”。企业还必须解决“Agent 在什么边界内调用工具”。

如果没有这一层边界，MCP 反而会把过去隐藏在后台系统里的风险放大出来。

企业数据访问需要三层边界

第一层是身份边界。

Agent 不能只有一个统一的系统账号。不同用户触发同一个 Agent，背后的数据权限应该不同。销售只能看自己的客户，区域经理只能看自己区域，总部可以看全局，财务可以看利润和成本。

第二层是语义边界。

Agent 不应该只拿到一堆表名和字段名。它要知道哪个表是订单主表，哪个字段是支付金额，哪些状态算有效订单，哪些指标只能用于经营分析，哪些字段不应该参与普通问答。

第三层是执行边界。

Agent 调用数据工具时，要有查询范围、超时控制、敏感字段控制、行级权限、字段级权限和审计记录。否则，一个看似正常的问题也可能变成大范围扫库、慢查询或越权查询。

AskTable 的位置：做 Agent 和企业数据之间的可信数据层

AskTable 不是把 MCP 当成“多接一个协议”。

更准确地说，AskTable 要解决的是 Agent 访问企业数据时的中间层问题。

BuildTable 负责把企业内部表格、数据库、数据仓库和业务系统数据采集、存储、建模成 AI 更容易理解的数据基础。

AskTable 负责在这个数据基础之上建立业务语义、指标口径、权限规则和问数能力，让业务人员和企业内部 Agent 都能在可控范围内获得答案。

当企业内部有自己的 Agent、工作流平台或业务系统时，AskTable 可以作为结构化数据分析工具被调用，而不是让每个 Agent 分别连接原始数据库。

这样做的价值不只是技术集成更方便，更重要的是治理边界统一。

同一个问题，由不同身份触发，应该走同一套语义和权限规则；同一个指标，在不同入口里，也应该按同一个口径解释。

企业落地 MCP，先问 5 个问题

如果企业准备让 Agent 通过 MCP 访问数据，建议先问 5 个问题：

• •Agent 调用数据工具时，身份来自哪里？
• •数据源权限是按系统账号控制，还是按真实用户和角色控制？
• •指标口径、字段含义和业务规则在哪里维护？
• •查询过程有没有超时、脱敏、行级和字段级控制？
• •调用记录能不能被审计和复盘？

如果这些问题还没有答案，就不要急着把数据库暴露给 Agent。

MCP 让 Agent 更容易连接工具，但企业真正需要的，是一层既懂业务数据、又能执行权限和审计的数据访问治理层。

这正是 AskTable / BuildTable 可以承接的位置。

参考来源

• •AWS：How AgentCore Gateway supports the MCP 2026-07-28 spec
• •Amazon Bedrock AgentCore：MCP servers targets