Here's a pattern I keep seeing.

A team wires up an AI agent that can do real things — send emails, run commands, query and modify the database, call external APIs. The demo is magical. It reads a request, figures out the steps, takes them, reports success. Everyone's impressed, and it ships.

Then comes the first incident. It emails the wrong list. It runs a destructive command against the wrong environment. It reads a web page that quietly tells it to do something nobody asked for, and it obliges. Suddenly the magical demo is a very un-magical cleanup, and someone's asking how this was allowed to happen.

Here's the thing: the demo was never the hard part. Getting an agent todosomething is genuinely easy now. The hard part — the part that almost always gets skipped in the rush — is everything that keeps the agent from hurting you when it inevitably does the wrong thing. And itwilldo the wrong thing, because it's a probabilistic system acting in an unpredictable world.

So this is the checklist I think belongsbeforeyou let an agent touch anything that matters. Not the fun part. The part that separates an agent you can actually deploy from a liability with a good demo.

1. Least privilege — the agent can only reach what it strictly needs

This is the highest-leverage guardrail, and it's the one most worth getting right first, because it makes entire categories of disaster simply impossible.

An agent thatcannotreach production cannot wipe production. An agent thatcannotsend money cannot be talked into sending money. An agent with no access to a system can't be the cause of an incident in that system, no matter how confused or compromised it gets. So the question to ask before anything else isn't "what should this agent be able to do?" — it's "what is theleastit needs to do its job?" Then give it exactly that and nothing more.

Almost every catastrophic agent story, when you trace it back, turns out to be a permissions decision someone made without quite noticing — handing over credentials that could reach productionat all，或者工具权限范围超出了任务所需。破坏性操作成了头条新闻，但真正的问题在于那个过宽的授权，它在很久之前就被悄悄犯下了。最小权限原则是一道护栏，能在预防成本最低的环节捕获错误。

2. 对重大操作进行人工审批——按影响范围设闸

有些操作你可以让智能体自由执行。有些操作你绝对不该让它在无人看管下执行。技巧在于把这条线画好。

那些不可逆或高影响的操作——发送、花钱、删除、导出、部署——应当暂停等待人工介入。但有两件事决定这道护栏的成败。第一，不要什么都设闸。一个智能体在一次会话中请求四十次许可，会训练人类不读内容就点“批准”，于是你的审批步骤就成了走过场——那次点击记录的是出席，而不是同意。把闸门留给真正值得设闸的操作。

第二，审批必须有意义。对一件人类无法评估的事情问“批准此操作？y/n”，就是盖橡皮图章。要展示影响范围：这会影响什么、会花费什么、即将改变什么、相关历史是什么。给审批者足够具体的东西，让他真的能够拒绝。盲目做出的审批不是控制，而是一份签了名的责任负担。

3. 把智能体读到的一切都视为不可信

你的智能体摄入的任何东西——网页、邮件、文档、同事的文件、工具的输出、代码注释——都可能携带指令。这就是提示注入，而且它不是一个已解决的问题：你无法可靠地检测隐藏在自然语言中的恶意指令，因为表述它们的方式无穷无尽，而攻击者会适应你部署的任何过滤器。

所以不要把信心放在检测坏输入上。把控制放在操作上。智能体可以做的重大事情（发送、花钱、删除、导出）集合很小，你可以把它们一一列举出来——所以用硬性检查来给这少数几个调用设闸，这些检查不依赖模型对它所读内容是否可信的判断。实用的经验法则是：当智能体同时拥有私有数据访问权限、接触不可信内容，以及能够对外采取行动，三者同时具备。去掉这三要素中的任何一条，一次成功的注入所能触及的范围都会小得多。

4. 一个真正能说“不”的审查者——并且已经过测试证明它会说“不”

对于有后果的行动，第二道检查——一个验证步骤，或一个独立的“裁判”智能体，其职责是在行动执行前审查拟议的行动——会带来真正的保护。一个必须说服独立审查者的系统，比一个仅凭第一冲动就自行行动的系统要难被推向坏结果得多。

但这里有个人们会跳过的部分：一个总是批准的审查者不是控制措施。它感觉像是安全措施，它生成一份令人安心的日志，而它实际上什么都拦不住。在你信任一个审查者之前，交给它一个故意设计的坏行动——一个你知道应该被拒绝的行动——并确认它确实拦截了。一个你从未亲眼见过触发的护栏不是护栏；它只是一个有着漂亮 UI 的希望。测试那个“不”，否则你根本没有。
更好的做法是，让那个测试永久化：让一个故意失败的探针按计划运行，并像其他检查一样发出回执，这样“审查者已经过测试证明会说‘不’”就成为系统一个长期、可证明的属性，而不是某个下午的记忆。（致谢：@slabb。）

5. 一条独立的审计追踪——因为证人不能是嫌疑人

当出问题时，你会去查日志来重建发生了什么。而陷阱就在这里：如果日志是由智能体写的，那它们就是由那个行为不端的家伙写的。一个困惑或被攻陷的智能体不会产生一份让你警觉的破损日志——它会生成一份干净的日志，一份对糟糕决策的整洁记录，这更糟，因为一份干净的日志会让你停止追查。

所以记录必须在智能体无法控制的地方产生——它周围的基础设施或监督层，而不是智能体自己的自我报告。把它封存起来，使篡改会留下可见的缺口，而不是无声的编辑。并且不仅要记录什么智能体做了什么，还要记录它当时相信什么——它以为自己处在哪个环境中，它以为自己正在对哪个目标采取行动——因为在错误的信念下，行动通常是可辩护的，而信念才是真正解释这起事件的部分。

关于这在实践中是什么样子，先做一个简短的、公开的说明：我从事xenition.com的工作，这是一个 AI 工作空间，而正是这一整套组合——审批门、独立的审计日志、第二位审查者——是我们不得不刻意构建进去的，而不是事后附加的。在我们的设置中，智能体的重大操作会经过审批门，每一步都会写入一份并非由智能体自己撰写的审计日志，并且有一个独立的评判智能体在操作执行前对其进行审查。我并不是把它当作那个答案——很多技术栈会以不同方式组装这些部件，正确的形态取决于你的系统。我提到它只是作为一个具体的例证，说明这一切都不是理论上的：审批门、独立记录和第二位审查者都是你今天就能实际交付的东西，而且越来越是你应该交付的东西。

6. 爆炸半径限制——假设它会出错，并限定最坏情况能有多糟

上面的护栏降低了事情出错的频率。这一条则接受某件事最终一定会出错，并确保没有任何单一错误是灾难性的。

给智能体设定硬性限制：支出上限、速率限制、在必须汇报之前可执行操作数量的配额。默认优先选择可逆的操作——软删除优于硬删除，分阶段发布优于一次性全量发布，草稿优于直接发送。思维方式的转变才是关键：不要再试图保证智能体永不犯错（你做不到），而要开始保证当它犯错时，损害是小的、可控的、可恢复的。一个只让你付出一次可逆变更和耸耸肩的错误的代价，与一个让你付出一个数据库的错误的代价，完全是两回事。

7. 衡量效果而非报告的可观测性

最后，要观察正确的东西。一个旨在回答“智能体是否报告成功？”的仪表盘，从构造上就是一个旨在信任证人的仪表盘——而我们刚刚已经讲过为什么证人不可信。智能体会很乐意报告一个看起来有效的成功，同时却指向错误的目标，而你那绿色的仪表盘会告诉你一切正常。

所以要衡量世界，而不是智能体对它的描述。不变量是否成立？总额是否仍然平衡？被引用的记录是否真的存在？系统是否仍处于一致状态？这些检查写起来比“它是否返回了 200”更烦人，而它们是唯一能抓住那种报告看起来完美、现实却是错的故障的检查。衡量效果，而不是自我报告。

要点

能力是容易的部分。它也是令人兴奋的部分，这正是为什么它获得了所有关注和所有演示时间——也正是为什么那些与这两者都不沾边的护栏，被留给了“以后”，而“以后”往往意味着“事故之后”。

但智能体在生产环境中的真正价值，从来都不是它能做什么。而是它能在安全、可重复、可恢复的前提下做什么——是它在不变成你下个季度要花时间收拾的烂摊子的前提下能做什么。上面这七项并不是用 AI 构建中光鲜亮丽的部分。它们是决定光鲜亮丽的部分能否经受住现实世界考验的部分。

先造刹车，再造引擎。或者至少，在你把它开上高速公路之前。

如果你已经把智能体部署到生产环境，我真的很好奇：这些当中，哪些是你在第一次事故之前就已经具备的——而哪一个是你正好在事故之后才补上的，因为它用惨痛的方式教会了你？我们大多数人至少都曾用昂贵的代价学会了其中一项。你的是哪一项？