如何构建AI工具的细粒度授权体系?

我最近在公司内部搞安全审计时，意外踩到一个“AI工具授权”坑——Kibana 9.4.4 的 Agent Builder 竟然在调用机器学习功能前，根本没检查用户到底有没有对应权限。想想那种低权限小白突然能跑高级模型的画面，我直接笑出声：这特权提升的潜力，简直太好用了（当然是坏事）。于是，我把这件事当成了构建细粒度授权体系的案例，和大家聊聊怎么避免类似尴尬。

先从“谁能干什么”说起

细粒度授权的核心，就是把每个操作拆到最小粒度，然后把对应的权限明确标记。像 Kibana 里，agent:*、ml:*、space:* 这些通配符权限就太宽了，低权限用户只要有 agent:run，就可能触发 agent:create，从而走到特权路径。我的经验是：角色里只放必需的细项，比如只给 Agent Builder – Run，不顺手给 Create/Update，这样即使被利用，攻击面也被限制在最小范围。

认证域别忘了“唯一性”

ESA‑2026‑124 提到，Agent Builder 判断私有 Agent 所有权时，只比用户名不比 Realm，导致不同域的用户被误当同一个人。我们在审计时，先打开 Elasticsearch 的 realm 配置，确认有没有多个 Realm 共用同一用户名。若有，立刻在权限模型里加入 Realm 维度，让同名用户在不同域之间互不干涉。这样一来，跨域的“误认所有者”就不可能再出现。

Space（空间）里的隔离必须“空间专属”

在 ESA‑2026‑156 里，跨空间的机器学习作业数据泄露让人揪心。我的做法是：在 Kibana Spaces 中，给每个空间单独绑定角色，绝对不要让非管理员拥有全局 ml:* 或 agent:* 权限。比如给某个业务团队的空间只配 Space‑specific 的 ml:read，而把 ml:manage 限在管理员角色。这样即使有人误操作，也只能看到自己空间的数据，根本不可能跨空间读到别人的模型结果。

实时审计是“最后的保险”

细粒度授权不是一次性配置完就完事儿。开启 Kibana 的审计日志，记录所有 /api/agent_builder/ 之类的调用，定期对比异常行为。我们在升级到 9.4.5（甚至 9.5.1）后，跑了一遍审计报告，发现几条可疑的 POST 请求被拦截，幸好及时发现并回滚了错误的角色配置。

小结：从案例到体系

• 拆解权限：把 agent:*、ml:*、space:* 细化到具体动作。
• 加入域/空间维度：在所有权判断和空间授权里，都要把 Realm 和 Space 纳入模型。
• 最小权限原则：角色只授予业务必需的最小权限，避免“跑偏”。
• 审计监控：开启审计，定期回看日志，及时发现授权链路的异常。

把这些点落到实际的 AI 工具上，就能把“特权提升”这颗定时炸弹拦在门外。下次如果你们的产品要引入类似的 AI 自动化功能，记得先把授权链路拉细、拉严，免得以后像我一样，半夜被安全告警吓醒。祝大家玩得开心，也玩得安全！