AIOps落地：AI 差点把生产库删了，我才想明白权限该怎么给

不要把AI当“超级管理员”，要把它当一个新员工

很多团队接入 AIOps 时，很容易走一个捷径：为了让 AI 什么都能查、什么都能执行，直接给一个高权限账号。比如 Kubernetes 给 Cluster Admin，Linux 给 root，数据库给 DBA 权限，云平台直接给管理员 AK/SK。

这样开发确实快。AI想查什么就查什么，想执行什么就执行什么。但问题也很明显。

假设用户输入一句：“帮我清理一下没用的服务。”AI理解错了“没用”的范围，真把生产环境几个服务删了怎么办？

更麻烦的是，AI面对的不只是“判断错误”，还有提示词注入、工具调用错误、上下文污染等问题。OWASP 在针对大模型和 AI Agent 的安全建议里反复强调一点：Agent只能拿完成任务所必需的最小权限，高风险操作应该增加人工确认。

所以做 AIOps，我更建议把 AI 当成一个刚入职的运维工程师。你不会第一天就把 root 密码、生产数据库权限、云平台管理员账号全部交给一个新人。AI也一样。

AI权限不能只分“有权限”和“没权限”

传统系统经常是 RBAC：你是什么角色，就拥有什么权限。但到了 AIOps，这还不够。因为 AI 一次任务往往横跨很多系统。

更实际的做法，是至少把权限拆成几个维度：

第一，数据权限。

AI能看哪些数据？普通监控指标可以看，业务日志可以看，但数据库里的身份证号、手机号、订单敏感信息是不是应该脱敏？

第二，工具权限。

AI可以调用 Prometheus 查询，可以调用日志平台，但是不是一定需要 Shell？能够查 Kubernetes，不代表必须能执行 kubectl delete。

第三，操作权限。

同一个工具也应该区分读和写。比如：

查看 Pod：允许。
查看日志：允许。
重启 Pod：有限允许。
删除 Deployment：需要审批。
修改网络策略、IAM权限：原则上不自动执行。

最好给AI划四条“自动驾驶等级”

AIOps权限设计，我觉得可以借鉴自动驾驶的思路。

L1：只看，不动

AI负责查监控、查日志、分析故障、生成建议。比如：

“订单服务错误率升高，初步判断 Redis 连接池耗尽，建议扩容连接池。”

这个阶段风险最低。

L2：生成方案，人来执行

AI不仅告诉你原因，还直接把操作命令准备好：

kubectl rollout restart deployment/order-service

但是不执行。运维工程师确认后手动执行。

L3：低风险操作自动执行

比如重启单个无状态 Pod、触发日志采集、扩容某个经过白名单验证的服务。这类操作影响有限，而且容易回滚，可以允许 AI 自动执行。

L4：高风险操作必须审批

例如删除数据库、修改防火墙、变更 IAM 权限、大规模重启、生产数据库 DDL。AI可以分析，可以生成执行计划，但最后那一下必须有人点确认。这也是目前 AI Agent 安全设计中很重要的一条原则：越不可逆、影响范围越大的动作，越不能完全交给模型自主决定。

千万不要让“大模型自己决定自己有没有权限”

这里还有一个特别容易被忽视的问题。不要在 Prompt 里写一句：

“你只能执行低风险操作，高风险操作必须经过管理员同意。”

然后就觉得权限控制完成了。这不是权限控制。这只是“告诉 AI 要守规矩”。

真正的权限控制必须放在模型之外。比如 AI 发起：

“删除 production 数据库。”

真正执行 API 请求的时候，权限网关发现：

操作对象：生产环境
操作类型：DELETE
风险等级：高
当前身份：AIOps Agent

于是直接拦截，要求人工审批。

权限最终应该由 IAM、API Gateway、工具层或者策略引擎判断，而不是让大模型自己判断。

给AI的权限最好还是“临时的”

还有一种常见做法值得注意：不要给 AI 一个永久有效的超级账号。更好的方式是：需要的时候申请，用完自动回收。

例如某次故障需要查询生产数据库。系统临时给 AIOps Agent 一个只读权限，有效期 15 分钟，只允许访问订单库。任务结束，权限自动失效。

这就是安全领域经常说的 Just-In-Time 和 Just-Enough-Access：在需要的时候，给刚刚够用的权限。而不是“这个账号以后可能有用，所以什么权限都先给它”。

最后一定要留下“录像”

以前出问题，我们会问：“谁改的？”以后可能变成：“哪个 AI 改的？为什么改？根据什么判断改的？”

所以 AIOps 每一次工具调用最好都留下完整审计记录：谁发起了任务、AI看了什么数据、调用了什么工具、执行了什么命令、谁审批了、结果是什么。关键操作最好还能回滚。

因为 AIOps 权限管理最终追求的不是“AI永远不犯错”。这个目标不现实。真正应该做到的是：AI犯错以后，影响范围足够小；出现异常以后，我们知道它干了什么，而且能够快速撤回。

写在最后

AIOps发展到后面，真正拉开差距的可能不是“谁家的模型更聪明”，而是谁敢让 AI 真正在生产环境里干活。

而敢让 AI 干活的前提，不是相信 AI 永远不会出错。恰恰相反，是从一开始就假设：它可能判断错，可能理解错，也可能执行错。

然后通过最小权限、分级授权、人工审批、临时权限、审计和回滚，把错误控制在一个可以接受的范围里。

好的 AIOps 权限体系，不是把 AI 的手脚绑死。而是做到一句话：该看的让它看，该干的让它干，不该碰的东西，它再聪明也碰不到。这才是 AI 真正进入生产运维体系之前，必须先补上的那道安全护栏。