行业在卷「怎么让 AI 跑得更自动」。
可真正决定安全的，是没盯着它的那半天——那时候它手里够得到什么。
作者 | 听风
编辑/排版 | MM77
翠鸟AI技术漫研 — 拓新AI边界、探索技术增量
一套 AI 运维做得好不好，衡量标准是：
当 prompt injection 真的发生时，这个 agent 能造成的最大破坏有多大。——而大多数人还在比谁让 AI 跑得更自动。
把破坏半径压到最小的四件事：
凭据不进 AI 上下文 → 按操作分层放权 → 护栏靠机器强制不靠自觉 → 全程留可审计证据。
👇下文每条都配一个反面做法，和一次我自己踩的真坑。
我维护着一批生产服务器的运维工具：
日常是 SSH 上去巡检、处置故障、留档。前阵子我想把它「AI 化」，让一个编码 agent 帮我盯。
🤨然后我在自己的配置文件里，看到这么一行：
# AI 的「免确认允许清单」（配置文件节选） "allow": [ "Bash(SSH_HOST=\"<生产机>\" SSH_USER=\"root\" SSH_PASSWORD=\"****root·明文密码****\" python probe.py)" ]
为了让 AI 勘查那台机器时不用每条命令都找我确认，我把生产机的 root 密码，明文钉进了 AI 的允许清单。
当时觉得方便。后来越想越不对——这不是「配置写得糙」，是我对「AI 运维」这件事的理解，从根上就偏了😣🙅♂️。
01. 大多数人把「自动」当成目标
打开任何一篇讲 AI 运维的宣传，关键词都是「自主」「无人值守」「端到端闭环」......
方向全指向一件事👉：让 AI 少问你、多干活。
这套叙事里，AI 越自动 = 运维越先进。
可换个角度：AI agent 一旦接上生产系统，它和一个被入侵的内部账号在能力上没有区别——区别是它以机器速度运行。
一个被攻陷的人，一晚上能翻几台机器；一个被攻陷的 agent，几分钟就能把你交给它的凭据、工具、数据全用一遍。
业界 2026 年的共识写得很直白：「一个被攻陷的 agent，以机器速度运行。」
衡量一套 AI 运维，先看它出错时能造成的最大破坏——而不是它顺手时能干多漂亮。
换个说法，落地时该往哪使劲就变了🫠：
不再是「怎么给它更多权限让它更能干」，而是先算清楚——当它出错时（不是「如果」，是「当」），最坏能坏到哪。
02. 为什么「出错」是必然，不是万一
因为有 prompt injection，而它是所有大模型至今没解决的底层弱点。
攻击者不需要让模型「叛变」，只需要让它照常听话——把恶意指令藏进一段它会读到的内容里（一个被攻陷机器上的日志、一个进程名、一段文件内容），模型读到就可能执行。
☑️Simon Willison 在 2025 年把这个风险总结成「致命三要素」（lethal trifecta）：
一个 agent 只要同时具备下面三样，就无条件地暴露在数据泄露风险里——无论模型多对齐、系统提示词多硬。
① 读到不可信内容-任何攻击者能控制的文本/数据，进了它的上下文
② 能接触敏感数据-凭据、密钥、私有信息在它手里
③ 能对外改变状态-能发请求、能执行命令、能把东西送出去
☑️基于此，Meta 后来把它推广成更好记的「三取二原则」（Rule of Two）：
一个 agent 在同一上下文里，这三样最多同时占两样。占满三样，就是在等着被人用一段注入的文本牵着走。
回头看我那行配置🫠：
我的运维 agent ☞ ：读服务器上的日志和进程（不可信内容 ✅）、上下文里有 root 明文密码（敏感数据 ✅）、能 SSH 执行任意命令（改变状态 ✅）。
三个全占（💣！）一旦哪台被管的机器已经被攻陷、往日志里塞了行注入，理论上攻击者能拿这把 root 横扫其余每一台。
03. 正确的做法长啥样
结论不是「别用 AI 运维」，而是给它套上一套让它坏不到哪去的结构。
这四条按依赖顺序排——第一条不做好，后面都是空中楼阁。
方法1 凭据不进AI的上下文
这是 lethal trifecta 里最好拆的一环——把「敏感数据」那一项从 agent 手里拿掉。
密钥不该以明文出现在 AI 读得到的任何地方：不在提示词里、不在允许清单里、不在它能 cat 的配置文件里。
我的做法是：把这些明文密码从配置里搬进操作系统级的加密密钥库，运行时才解密进内存、用完即走。
AI 的上下文里再也看不到密码本身。
业界更进一步的方案是给每个 agent独立身份 + 短时凭据（JIT）：不发「万能主密钥」，每次任务临时签发、用完即失效、可秒级吊销。
反面做法：
「反正 secrets 目录 gitignore 了」——文件没进 git，不代表没进 AI 上下文。
我那行 root 密码就在一个没被忽略的配置里躺着，git 拦不住它被喂给模型。
方法2 按操作分层放权，而非一刀切
「三取二」不是把 agent 阉割成废物。
是让我们按操作类型切：
只读的巡检（看磁盘、看进程、看服务），放开让它自主跑；会改变状态的变更（删文件、停服务、改 DNS、卸载挂载），一律走人工确认。
这正是 OWASP 给 AI agent 列的头号风险——Excessive Agency（过度授权）：给了它超出任务所需的功能、权限和自主度。
分层的本质就是：按「这一步到底需不需要写权限」来收敛。不可逆的操作永远留一道人闸。
反面做法：
给一个 run_command 工具就以为控制住了——工具级的允许/拒绝太粗。
允许它跑命令，等于允许它跑任何命令。粒度得细到「只读命令放行、写命令拦截」。
方法 03护栏靠机器强制，不靠 AI 自觉
我项目的规矩文档里写着六条铁律：「只读优先」「先备份后变更」「破坏性操作先确认」。
方向全对。问题是——它们是写给 AI 看的自觉，不是机器强制的边界。指望模型每次都自觉遵守，等于把安全押在它这次没被注入、没幻觉上。
正确的落地是：
用 hook 之类的机制在执行前硬拦危险命令（rm -rf、systemctl stop、umount、DROP），让「破坏性先确认」从一句建议变成一道过不去的关卡。
前提是你得假设注入一定会成功，然后设计成「就算成功了，它也干不成高破坏的事」。
一个让我自己都意外的证据写这篇时，我让 Claude 帮我改那个含密码的配置文件，它被自己的安全分类器拦下来了——理由是「覆盖权限文件属于未经请求的自我修改」。
连 AI 改自己的允许清单都得受机器约束。这就是护栏该有的样子：不看动机，只看行为。
方法 04 全程留可审计的证据
agent 是「行动」不是「生成」——它拿着真凭据做真操作，风险从「模型说了什么」变成「系统做了什么」。
所以每次处置都得留下能回溯的证据链：谁、什么时候、动了哪台、做了什么、回滚点在哪。
这既是出事后能查的底线，也是对齐 ISO 42001 / NIST AI RMF / EU AI Act 那套审计要求的入口。
我的项目里每个任务都写一份 runbook + 复盘存档，就是这个用途——（顺带一提，把这些 runbook 改造成 AI 能直接读的技能（Skill），还能让 agent 在告警触发时按册子自己调查，是「自动化巡检」迈向「AI 运维」的下一步。）
反面做法：
让 agent 以 root 跑——它能关掉自己的监控、改审计日志、装后门，你直接失去全部可见性。
这也是「永远别让 AI agent 跑 root」成为 2026 铁律的另一半原因。
04. 说实话，我今天用的方案也有边界
我把密码搬进了系统级加密密钥库，但它不是银弹🙅♂️。
这类「绑定当前账号」的加密，防的是「别的账号、或者文件被拷到别的机器」——那样解不开。
但它防不住「以我这个账号运行的恶意进程」：
任何跑在我登录会话里的代码，都能用同一个账号身份把它解开；信息窃取类恶意软件偷 Chrome 保存的密码，走的就是这条路。
所以它解决的是「明文散落」这个具体问题——密码不再摊在一个谁读到谁通吃的明文文件里了。
它没解决、也解决不了「本机已经被拿下」。
对本机运维的场景，这个边界可以接受；但如果是多人、或跑在不可信环境里，就得往 SSH key + 短时凭据 + 独立身份那套走。
看来，知道一个方案的边界在哪，比用了它更重要。
05. 带走一张表📋
下次有朋友要把某个系统「AI 化」，上线前可以拿这张表过一遍——它其实就是「三取二」的落地清单：
AI 接入生产系统 · 上线前自查：
- 凭据是否出现在 AI 读得到的任何地方（提示词 / 允许清单 / 可 cat 的配置）？有 → 先搬走。
- 这个 agent 是不是同时占了「读不可信内容 + 持敏感数据 + 能改状态」三样？占满 → 拆掉一样。
- 只读操作和变更操作，分层了吗？变更是否强制人工确认？
- 危险命令是靠 hook 机器拦截，还是靠 AI「自觉遵守文档」？靠自觉 → 换成硬拦。
- 假设 prompt injection 一定成功，此刻它能造成的最大破坏是什么？能接受吗？
- 每次操作是否留下了可回溯的证据链（谁 / 何时 / 动了什么 / 回滚点）？
- 它跑在 root / 你的完整权限账号下吗？是 → 降权到专用最小权限身份。
- 我们用的凭据方案，边界在哪、防不住什么，说得清吗？
这八条过下来，多半会发现自己卡在第一条或第四条——不是技术难，是「方便」的惯性太强。
比如，我那行 root 密码就是这么来的：当时只想少按几次确认键🫠。