实盘初次梳理 · AI 建议尚未审批
先收系统边界，别假装看懂所有 POST
现网数据可以把 168 个 Service 收敛为一批候选资源组，并为 242 个 Credential 生成权限包建议；但不规范 API 的动作语义仍然大量缺失。
只读快照
ACTUAL INVENTORYPROVISIONAL
168OAuth2
Service
Service
→
84候选资源组
AI 初次归类
AI 初次归类
→
242Credential
授权建议
授权建议
171 个 POST 仍然无法仅凭现有元数据可靠归类，不能自动进入 read/write。
这次真正盘出了什么
配置来自实时 Kong Admin API；使用关系来自 kong-log-* 中 label=kong_inner 的安全聚合。数字会随现网变化。
聚合日志
实际关系
实际关系
Credential
需确认用途
不可自动删除
三个实盘结论
这不是最终授权表，而是已经落到具体 Service、Route 和 Credential 的审核底稿。
前 20 个候选资源组覆盖 95.18% 流量
不需要从 168 个 Service 平均用力。先确认高流量资源组，就能覆盖绝大多数实际调用。
建议审核顺序：先确认前 20 个资源组 → 拆分共享基础能力 → 审核 22 个广泛访问客户端 → 最后处理 171 个 POST 语义例外。
完整实盘清单
所有结果都可以搜索和筛选。资源、动作和权限包是 AI 建议；Service、Route、Credential、调用次数是现网事实。
怎么读这份结果
自动化的价值是缩小人工范围，不是把不确定的业务语义伪装成确定答案。
关系是事实
629 条 Credential × Service 和流量次数来自实际 APILog 聚合，可以用于兼容性评估。
归类是建议
CRM、POM、FAP 等候选分组来自名称、Host、Path 和 Route 证据，必须由系统负责人确认。
用过不等于应当允许
Credential 权限包只是迁移候选。跨系统和无调用对象必须单独确认业务目的。
模型不参与放行
最终批准关系编译成确定性策略，由 Kong 本地判断。AI 不在实时请求链路中。
证据边界
本次只读分析没有改变 Kong、IdP 或 OpenShift 配置，也没有把原始日志写进报告。
报告包含
配置元数据：Service、Route、OAuth2 Plugin、Consumer、Credential 名称和 ID。
聚合行为：Service、Route、Method、状态码、次数、首次和末次时间。
报告明确不包含
request.body、Authorization、apikey、client_secret、refresh token 和原始 URI。AINS 登录已过期，本次没有用知识库推断服务归属；现网事实均来自实时 Kong 与 APILog。