AIOps实践反思：AI差点删库后，我才搞明白权限该怎么设计

随着大模型技术成熟，越来越多的企业开始将AI引入运维场景，AIOps也从概念验证走向实际落地。然而，当AI真正进入生产环境时，一个看似简单却至关重要的问题浮出水面——AI的权限该如何设计？最近一个真实的案例让我们深刻认识到这个问题的紧迫性：某团队的AIOps系统在一次故障排查中，由于权限配置不当，险些将生产数据库删除，幸好被发现得早。这场虚惊促使我们重新思考：AI权限体系究竟该怎么构建？

把AI当作新员工，而非超级管理员

在AIOps落地初期，很多团队为了快速见效，会走一个看似便捷的路径：直接给AI一个高权限账号。Kubernetes给Cluster Admin，Linux给root，数据库给DBA权限，云平台直接给管理员凭证。这样确实能让AI无所不能，但风险也随之而来——当用户输入"帮我清理没用的服务"时，AI可能误解"没用"的范围，真的把生产环境的服务删掉。更棘手的是，AI面临的不只是"判断错误"，还有提示词注入、工具调用错误、上下文污染等复杂安全问题。

权限设计三维度：数据、工具、操作需拆分

OWASP在针对大模型和AI Agent的安全建议中反复强调：Agent只能获得完成任务所必需的最小权限，高风险操作应该增加人工确认。基于这一原则，我们应该把AI当作一个刚入职的运维工程师。你不会在第一天就把root密码、生产数据库权限、云平台管理员账号全部交给新人，AI也同样适用这个逻辑。最小权限原则不是限制AI的能力，而是将风险控制在可接受范围内。

借鉴自动驾驶分级：AI权限的四个等级

传统RBAC模型已经不能满足AIOps的复杂需求。因为AI一次任务往往横跨多个系统，更实用的做法是将权限拆分为三个维度。第一是数据权限：AI能看哪些数据？普通监控指标可以查看，业务日志可以分析，但身份证号、手机号、订单等敏感信息是否应该脱敏？第二是工具权限：AI可以调用Prometheus查询、可以访问日志平台，但是否必须拥有Shell权限？能够查询Kubernetes，不代表必须能执行kubectl delete。第三是操作权限：即使同一工具也应区分读和写——查看Pod允许，查看日志允许，重启Pod有限允许，删除Deployment需要审批，修改网络策略或IAM权限原则上不自动执行。

权限控制必须独立于大模型本身

在权限等级划分上，我们可以借鉴自动驾驶的分级思路。L1级是纯观察：AI负责查监控、分析日志、生成建议，但仅停留在"给出分析结论"层面，不执行任何操作。L2级是方案生成：AI不仅分析原因，还准备操作命令供人工确认，但不自动执行。L3级是低风险自动执行：重启单个无状态Pod、触发日志采集、扩容白名单验证过的服务等影响有限且易回滚的操作，可以由AI自动执行。L4级是高风险审批：删除数据库、修改防火墙、变更IAM权限、大规模重启等不可逆操作，AI可以分析和生成计划，但最终执行必须经过人工确认。越不可逆、影响范围越大的操作，越不能完全交给模型自主决定。

如有侵权，请联系删除。