ApiGo 5.5 提到行列级权限：给 AI 接业务数据，先把越权堵住
看到 ApiGo 5.5 的发布消息，我先停在了“数据行列级权限”这几个字上。让 AI 查订单、读客户资料，演示通常很顺；可一旦接上真实业务，问题马上变成：它替谁查，能查到谁的数据？这比调用接口时少写几行代码更让我在意。
基于公开摘要可见，ApiGo 的定位是将 ERP、CRM 等存量系统的数据封装成 REST API 与 MCP 工具，供智能体在策略管控下访问。发布标题提到新增行列级权限，但摘要没有给出实现细节。下面谈的是接入这类工具时我会做的工程检查，不代表该版本已经具备这些能力。
接口通了，不等于权限通了
假设客服让智能体查询某张订单。网关收到的如果只是一个共用服务账号，就很难仅凭这个账号区分不同客服的授权范围。我会先确认用户身份怎样穿过工具调用链路，权限判定依据来自哪里。让模型在参数里自报一个用户编号，不能算可靠的身份传递。
行权限可以理解为限制“哪些记录能看”，列权限则限制“哪些字段能看”。比如客服可以看到自己负责的订单，但未必应该拿到客户完整的手机号。这里的限制应由服务端执行，不能寄希望于提示词要求模型保密。数据已经交出去，再约束回答方式就晚了。
我会拿两个人的账号交叉试
试用时，我会准备权限不同的测试账号，让它们查询同一张测试订单，再分别尝试列表和详情接口。详情拒绝访问，列表却把记录带出来，这种不一致也得挡住。测试数据最好刻意放入不该可见的字段，检查实际响应，而不是只看页面有没有隐藏。
缓存也要单独查。假如查询结果缓存只按请求参数区分，没有纳入用户或权限范围，同一个问题就可能命中另一个人的结果。权限收紧之后，旧缓存是否失效，同样需要验证。具体怎么设计得看系统，但不能因为入口换成了 MCP，就把原有的数据隔离要求省掉。
出问题时，要知道是哪次调用
我更关心审计记录能不能把一次工具调用与实际用户关联起来。某人发现客户信息被越权读取，排查时至少要能回答谁发起了请求、当时按什么授权范围执行。日志又不能直接堆满原始客户资料，否则为了查泄露，反而多留了一份敏感数据。
对小团队来说，接入成本还包括权限规则由谁维护。业务系统改了部门归属，网关那边是否需要再改一次？如果两处分别配置，就要明确以哪处为准，以及同步失败时如何处理。接工具很快，长期养着两套不一致的授权规则才麻烦。
我会先选一个只读、字段范围清楚的查询场景，用测试账号验证越权边界，再决定是否接入真实业务。验收时也要试一次关闭入口，确认能停下新增调用。至于写操作，等身份传递和审计都查清楚再谈，别和查询功能一起顺手放开。
本文由本站基于公开热点摘要整理和原创分析生成。以上检查项是工程建议，不是对 ApiGo 5.5 功能的实测结论。
原文来源：OSCHINA：ApiGo 5.5 发布，新增数据行列级权限。
