ApiGo 5.5 提到行列级权限：给 AI 接业务数据，先把越权堵住
内容提要
文章以 ApiGo 5.5 新增行列级权限为引，强调 AI 接入业务数据前须先防越权。作者建议确认用户身份如何贯穿调用链、权限由服务端执行；用不同权限账号交叉测试列表与详情接口，检查缓存是否按用户隔离；审计日志应关联实际用户并避免留存敏感数据；明确权限规则的维护与同步责任。建议先选只读场景验证越权边界，再接入真实业务。
延伸解读
身份传递是权限控制的前提
文章强调，网关若只使用共用服务账号，就无法区分不同用户的授权范围。让模型在参数中自报用户编号并不可靠，必须确认用户身份如何贯穿工具调用链路，以及权限判定依据来自哪里。这提醒读者，在接入 AI 查询业务数据前，先理清身份传递机制，否则行列级权限可能形同虚设。
服务端执行与交叉测试缺一不可
行权限限制可见记录，列权限限制可见字段，两者都应由服务端执行，不能依赖提示词约束模型。文章建议用不同权限的测试账号交叉查询同一订单，并分别检查列表和详情接口，防止详情拒绝而列表泄露的不一致。测试数据应刻意包含不该可见的字段，以实际响应为准，而非只看页面是否隐藏。
缓存与审计容易成为盲区
缓存若只按请求参数区分，未纳入用户或权限范围，可能让一个用户命中另一个人的结果；权限收紧后旧缓存是否失效也需验证。审计方面，日志应能关联实际用户与授权范围，同时避免留存原始敏感数据。文章还提醒明确权限规则的维护责任，防止业务系统与网关两处配置不一致。
先只读验证，再逐步放开
文章建议先选一个只读、字段范围清楚的查询场景，用测试账号验证越权边界，再决定是否接入真实业务。验收时还应测试关闭入口能否停止新增调用。写操作应等身份传递和审计都查清楚后再考虑，不要与查询功能一起放开。这些步骤有助于在早期发现越权风险，降低接入真实数据的代价。
Q&A
ApiGo 5.5 新增的行列级权限具体指什么？
行权限限制“哪些记录能看”，列权限限制“哪些字段能看”。例如客服只能查看自己负责的订单（行权限），且可能看不到客户完整手机号（列权限）。这些限制应由服务端执行，不能依赖提示词让模型保密。
给 AI 接业务数据时，为什么不能只靠共用服务账号？
如果网关只用一个共用服务账号，就无法区分不同用户的授权范围。必须确认用户身份如何贯穿工具调用链路，权限判定依据来自哪里，不能靠模型在参数里自报用户编号。
测试越权时应该怎么设计测试用例？
准备权限不同的测试账号，让它们查询同一张测试订单，并分别尝试列表和详情接口。注意详情拒绝但列表泄露的不一致情况。测试数据要刻意放入不该可见的字段，检查实际响应而非页面隐藏。
缓存可能带来什么越权风险？如何检查？
如果查询结果缓存只按请求参数区分，未纳入用户或权限范围，同一个问题可能命中另一个人的结果。需要验证缓存是否按用户隔离，以及权限收紧后旧缓存是否失效。
审计日志应该记录哪些信息？又要注意什么？
审计记录应能把一次工具调用与实际用户关联起来，至少能回答谁发起了请求、当时按什么授权范围执行。同时日志不能堆满原始客户资料，避免为查泄露反而多留一份敏感数据。
小团队接入时，权限规则维护要注意什么？
要明确权限规则由谁维护。业务系统改了部门归属后，网关是否需要同步修改？如果两处分别配置，需明确以哪处为准，以及同步失败时如何处理，避免长期维护两套不一致的授权规则。
接入真实业务前，建议先做什么验证？
先选一个只读、字段范围清楚的查询场景，用测试账号验证越权边界，再决定是否接入真实业务。验收时还要试一次关闭入口，确认能停下新增调用。写操作等身份传递和审计都查清楚再谈。
