方案初稿 · 基于 gateway-inner 实际盘点
让 AI 整理权限，不要让 AI 当门卫
AI 把不规范 API、历史调用和应用意图整理成可审核的权限建议；人批准高风险关系；Kong 只执行已经发布的确定性策略。
目标：把“逐条配置”变成“审核少数例外”
CONTROL PLANENOT REQUEST PATH
INPUTKong 配置
APILog
API 文档 / 代码
APILog
API 文档 / 代码
AI SORTER归系统
判动作
标风险
判动作
标风险
HUMAN只审批例外
与高风险
与高风险
COMPILED POLICY → KONG请求路径不调用大模型 · 本地缓存 · 确定性 allow / deny
起点不是一张空白表
现有配置和 90 天日志已经足够生成第一版建议，但日志只能证明“用过”，不能证明“应该永久允许”。
第一批资源归类对象
不逐条绑定客户端
待映射权限包
Credential × Service
Credential × Route
第一版建议：先用 628 条 Credential × Service 关系生成“系统级授权候选”，不要立即把 666 条 Route 关系固化成永久细权限。
不等所有 API 标准化
权限分三层推进。越往下越精细，也越依赖服务语义；不规范服务停在第一层也能获得系统边界。
系统级访问
复用 Kong 已有 Service 归属。把多个 Service 归到 CRM、POM、FAP 等资源组，客户端只绑定 crm-access 这类权限包。
resource=crm动作级细分
GET / HEAD 默认 read。POST 结合路径、文档、响应结构和代码推断；语义不清时保持系统级权限并进入待确认队列。
action=read | write | admin业务与数据级
“只能看本部门客户”等规则无法只靠网关判断，由服务自身或专门授权服务执行。AI 可以生成建议，不能代替业务规则。
subject + object + context新 Route 挂到已归类的 CRM Service
继承 resource=crm，无需重新配置所有客户端。
→
已有 crm-access 的客户端自动覆盖
只有 read/write/admin 等特殊语义需要额外判断。
完整控制面：六步闭环
AI 位于策略生成流程，不位于实时请求链路。所有自动结论保留证据、置信度和变更记录。
采集事实
Kong Service / Route、OAuth2 Credential、聚合 APILog、可选 OpenAPI 与代码。
资源归类
合并同系统 Service，生成 resource code，并列出归类依据。
动作与风险
推断 read / write / admin，低置信度进入待确认。
审核授权
应用负责人确认权限包；系统负责人确认高风险 API。
编译策略
生成 consumer + resource + action 的签名策略快照。
Kong 执行
本地缓存命中后 allow / deny，并记录策略版本和原因。
真正需要管理的只有四类关系
权限包是管理抽象，不要求把每个 Route 都写进 token，也不要求客户端预先知道未来所有 API。
资源与动作目录
RESOURCE_MAPKong service_id → crm / pom / fap / unknown
OPERATIONroute_id + method → read / write / admin；只存例外也可以
权限包与客户端授权
PACKAGE_RULEcrm-access → resource=crm；crm-read → resource=crm + action=read
CLIENT_GRANTKong consumer / client_id → 权限包、环境、有效期、审批记录
scope=all 在迁移期怎么处理
旧 token 继续携带 all，避免立即改造客户端；但 all 只作为 legacy 标记，实际放行范围由 CLIENT_GRANT 决定。最终由 IdP 签发真实权限包或资源 scope，并处理最长 14 天的 refresh token 链。迁移期语义属于兼容措施，不应作为长期标准。
POST 怎么处理：让 AI 给证据，不让它猜着放行
下面是推断流程示意，不代表当前接口已经完成分类。点击三个场景查看建议如何变化。
86%建议 action=read
需要服务负责人确认一次
需要服务负责人确认一次
PATHsearch 是查询强信号
RESPONSE返回分页列表
HISTORY无后续写操作证据
建议：登记 POST + route 为 read 例外。确认后，未来相同 Route 自动匹配 crm-read；确认前仍使用 crm-access，不做误拦截。
AI 的权限边界
自动化要减少重复劳动，但不能把模型的不确定性变成生产授权风险。
可以自动完成
发现与建议：聚类 Service、生成资源目录、解释 POST 分类依据、推荐权限包、发现长期未用授权、生成策略差异。
必须人工确认
业务与风险：跨系统首次授权、资金/删除/管理接口、低置信度动作、没有历史证据的旧客户端、是否回收权限。
绝不交给大模型
实时放行：请求路径只执行版本化规则。模型不可临时扩大权限，也不能直接把“曾经调用过”变成永久授权。
建议从一个只读 POC 开始
先验证 AI 是否能降低梳理成本，不修改 Kong、不阻断流量，也不把原始 APILog 导出给模型。
生成资源目录
将 168 个 Service 自动聚类为业务资源组；无法判断的标为 unknown，保留证据和置信度。
生成授权候选
以 628 条历史 Credential × Service 关系生成权限包建议，102 个无调用 Credential 单独列队。
离线回放验证
选择 3 个系统、10 个活跃客户端，用日志回放比较 would-allow / would-deny 和误判原因。
接入影子判断
Kong 只记录策略判断，不拦截；稳定后先启用系统级边界，再逐步启用动作级权限。
POC OUTPUT A服务资源目录：系统归属、负责人、证据、置信度、unknown 清单。
POC OUTPUT B客户端授权建议：现有使用、建议权限包、风险、待确认和拟回收项。
POC OUTPUT CPOST 语义队列：read / write / admin 建议与需要人工确认的例外。
POC OUTPUT D影子结果：每次 would-deny 的策略版本、规则、证据和处理建议。
实施建议：无需购买 OPA 才能验证方案。现阶段可先做离线策略生成器；运行阶段再选择轻量自研 scope-policy Kong 插件与本地策略缓存。
这份初稿还缺什么
以下信息无法仅从日志可靠推断，需要在 POC 中补充或由负责人确认。
需要补齐
OWNERSHIPService 对应的业务系统和负责人
INTENT客户端“为什么需要访问”，而不只是“过去访问过”
暂不强求
OPENAPI旧 API 没有规范文档不阻塞第一层系统级收口
FINE SCOPE不要求一次性为 218 条 Route 定义完整细 scope