MCP让AI代理接入你的API，但它并不决定代理该看到什么。
内容提要
MCP让AI代理调用企业API时可能接触敏感数据，传统权限控制不适用于灵活代理，过滤响应又导致工具重复维护。解决方案是采用GraphQL字段级契约，精确规定代理可见和可操作的字段，独立于上下游系统。GraphQL层可架设在现有REST、gRPC等服务之上，读写操作均受控，无需替换后端API。
延伸解读
MCP 解决连接，字段级契约解决权限
MCP 让 AI 代理能够发现和调用企业 API，但它本身不规定代理能看到什么数据。文章指出，传统权限控制针对固定用户，而代理在运行时灵活组合操作，需要更细粒度的控制。字段级契约独立于上下游系统，精确规定每个代理可访问的字段和可执行的操作，与 MCP 形成互补。
过滤响应为何导致工具重复维护
如果 MCP 工具直接透传上游所有数据，会暴露敏感信息；但若在工具内过滤响应，不同团队需要不同视图，就会产生大量重叠工具。文章举例说，财务、支持、库存团队各需不同订单字段，维护数十个相似工具成本高昂。字段级契约将规则绑定到字段本身，避免每个工具作者重复移除相同属性。
GraphQL 如何实现字段级控制
GraphQL 允许调用方指定所需字段，响应只包含这些字段。文章举例，查询订单状态只返回 status 和 shipBy，而 internalFraudScore 或 customerSSN 等敏感字段可被服务器直接屏蔽或设为不可达。写操作通过 mutation 暴露特定业务动作，如 requestInventoryTransfer，运行时授权后底层服务再检查可用性和审批。
无需替换现有后端 API
文章强调，GraphQL 层可以架设在现有 REST、gRPC、SOAP 等服务之上，不需要替换运行业务的 API。订单 API 仍可向集成层返回宽泛记录，而代理只收到被允许的字段。这种精确性在代理运行时组合操作时尤其有用，且 GraphQL 已有十多年生产经验，被 Shopify、Netflix 等公司大规模使用。
Q&A
MCP让AI代理接入API后，为什么传统的权限控制方式不再适用？
传统权限控制针对固定应用，后端检查用户权限后返回适当视图。但AI代理工作流灵活，需要动态调用API并可能接触敏感数据，传统方式无法精确控制代理可见的字段，导致要么暴露过多数据，要么需要维护大量重复工具。
什么是字段级契约？它如何解决AI代理访问API时的数据安全问题？
字段级契约是一种确定性的规范，精确规定每个代理可以查看和操作的字段，独立于上游API和下游代理。通过GraphQL实现，代理请求时只能获取指定字段，如internalFraudScore或customerSSN等敏感字段可被屏蔽或设为不可达，从而在字段级别强制执行权限。
GraphQL如何在不替换现有后端API的情况下，为AI代理提供受控的数据访问？
GraphQL层可以架设在现有的REST、gRPC、SOAP等服务之上。后端API继续返回完整记录，而GraphQL层根据字段级契约，只向代理返回其被允许看到的字段。读写操作都通过GraphQL的查询和变更（mutation）进行控制，无需替换后端服务。
在AI代理工作流中，如何控制写操作（如创建转移请求）的权限？
写操作通过GraphQL的变更（mutation）暴露特定的业务动作，例如requestInventoryTransfer。运行时会对该操作进行授权，底层服务在接受请求前会检查当前可用性和所需审批。这样既能允许代理执行必要操作，又能防止其随意更改库存、取消订单或发放退款。
为什么说MCP和字段级契约是不同层次，需要同时使用？
MCP定义了代理如何发现和调用工具，解决的是“可达性”问题；而字段级契约定义了这些工具被允许访问哪些数据，解决的是“可见性”问题。两者层次不同，MCP让代理能够调用API，字段级契约确保调用时数据访问受控，因此需要同时使用。
GraphQL在字段级权限控制方面有哪些实际应用案例？
GraphQL已为应用程序提供字段级契约超过十年，每天处理数十亿笔交易，被Shopify、Netflix、Airbnb、Expedia Group和Walmart等公司广泛使用。这些公司积累了丰富的生产经验，验证了该模型在代理场景下的可行性。
