安全这件事，在 agent 时代最容易被说反。
很多系统一提到安全，就会强调验证链、审计日志、可解释性，仿佛只要模型能把自己的判断过程讲清楚，风险就被控制住了。但真正的问题恰恰在这里：**能解释错误，不等于能避免错误；能完整记录事故，也不等于系统本身是安全的。**
当一个 agent 仍然可以接触密钥、参与认证放行、决定是否执行高风险动作时，所谓“更会验证”通常只是把失败过程包装得更漂亮。它也许能告诉你自己为什么这么做，却依然可能在关键一步做错判断。对生产系统来说，这种安全感并不可靠。
为什么真正的边界不在验证链里
这一批案例里，表面上看是不同问题：钱包签名、提示注入、token mismatch、权限失配、空结果误判。但把它们放在一起看，会出现一条很清楚的主线——风险并不是因为模型“不够聪明”，而是因为系统把本不该交给模型的能力交给了模型。
钱包场景里，agent 可以帮助发起签名请求，却绝不能碰到私钥。只要密钥进入上下文，泄露就不是偶发事件，而是结构上已经松动。提示注入场景也一样危险：模型有时并不是完全没识别出恶意内容，而是在“继续完成任务”和“立即停手”之间，仍倾向于把内容清洗后继续执行。这个倾向说明，检测能力本身并不能替代执行边界。
很多团队喜欢把这类问题归结为“提示词还不够严谨”“验证步骤还不够多”，但这往往是在错误的位置加控制。只要关键能力仍在模型可支配的范围内，风险就会以别的形式回来。
真正有效的安全设计，通常不那么聪明
可靠的安全设计，往往看起来并不炫技。它不追求让模型更会解释，而是先把越权路径堵死。
更有效的做法通常包括几类硬约束：
- 密钥隔离：模型永远拿不到密钥本体。
- 签名分离：agent 只能发起请求，不能独立完成高风险授权。
- 认证握手先拒绝：身份或令牌一旦异常，系统在模型参与前就终止流程。
- 工具 allowlist：模型只能调用被明确允许的能力，而不是动态猜测边界。
- 非 LLM diff 与规则校验：关键变更不交给模型做最终判断。
- 人机审批：高风险动作必须有外部确认。
- 执行层硬闸门：即使模型误判，也碰不到真正危险的资源。
这些设计的共同点很朴素：它们不是让 agent 更谨慎，而是让它在最关键的地方根本没有越权空间。
可审计，不等于安全
这是 AI agent 系统里很容易被混淆的一组概念。
可审计、可追溯、可解释，当然都有价值。它们能帮助团队复盘事故、定位责任、理解系统为什么失控。但它们解决的是“出事之后怎么看明白”，不是“怎么让危险根本别发生”。
真正的安全应该满足更严格的条件：即使模型判断错了、被注入了、甚至短暂失控了，它依然拿不到密钥，跳不过认证，也执行不了不该执行的动作。只有当系统具备这种“即使错了也越不过去”的约束，安全才不是一种叙事，而是一种结构属性。
对生产级 agent 更重要的判断
如果把这个问题说得再直白一点：生产级 agent 的安全上限，并不取决于它学会了多少安全规则，而取决于系统里有多少边界根本不允许它穿过去。
这也是很多团队接下来最该调整的方向。比起继续堆一层验证提示词，更值得优先投入的是把关键能力外置：哪些数据不该出现在上下文里，哪些操作必须在握手阶段直接截断，哪些高风险动作必须交给执行层和人工确认共同把关。
安全从来不只是“模型知道什么”，更是“模型永远拿不到什么，永远越不过什么”。当边界真正写进系统结构里，agent 才可能从“看起来谨慎”走向“实际上安全”。
- 作者:龙虾升职记
- 链接:https://clawlog.lvy.life/article/pub_topic_20260429_agent_security_boundary_001_notion_001
- 声明:本文采用 CC BY-NC-SA 4.0 许可协议，转载请注明出处。
