PostHog 有个叫 wizard 的命令行工具,能读你的代码库、装 SDK、埋点、建仪表盘。团队一度想把它变成安装 PostHog 的默认方式。做这件事的 context engineer Sarah Sanders 说,野心刚冒头,她的安全警铃就先响了。一个能执行命令的 Agent,长得实在太像恶意软件了。
原视频:https://www.youtube.com/watch?v=I2cbIws9j10(约 05:35:13 开始)
从一个修 bug 的小工具,长成八千人每周在用的默认选项
wizard 是个 agentic CLI:装好正确的 SDK,埋好事件,建好仪表盘。以前手工做这些事要一两个小时,wizard 五六分钟跑完,推理还免费。它的起点很朴素,同事 Josh Schneider 看到 Cursor 帮人配置 PostHog 时经常瞎猜、装错。他想着能不能做一个靠谱点的 Agent。团队验证过它确实比 Cursor 瞎猜强很多。野心跟着变大:能不能让它兼容任何框架和技术栈,自动装好一切,变成安装 PostHog 的推荐方式。演讲当天,团队刚好看到每周有八千名开发者在跑这个工具。
能跑命令的 Agent,骨架长得像恶意软件
wizard 的结构和大多数 Agent 项目差不多:挑好的模型、引导它的 prompt、一组工具。特别的地方在于一个自研的上下文引擎,她管它叫”wizard 的大脑”,玩笑说是”穿着风衣的 markdown”。这个引擎从文档、手写的经验教训、真实跑通的示例项目里取材,喂给 Agent 做模式匹配。
Sarah 的原话是,任何能执行命令的 Agent,骨架几乎就是”恶意软件起步包”。如果你想使坏,递给它的东西跟递给 wizard 的差不多。这话挺狠,先把自己团队的产品定了性,不是每个人愿意在台上这么说。也正因为这样,团队早早收了紧:bash 默认拒绝执行,只能装团队审核过的可信包,能跑 build、类型检查、lint,别的基本不行。它拿不到环境变量,也读不到 .env 文件,这条路直接堵死。密钥全部走一个独立的 vault,模型层面根本看不到。
两件无害的事握手,就开了一个漏洞
团队内部安全组做了一次审计。Sarah 说有意思的不是找到的具体漏洞,是这些漏洞的形状。几乎没有一条是明显作恶的设计,全是两件各自看着无害、出于好意的东西握手,凑巧开了个口子。她的结论很直接:攻击会组合,代码审查不会。开发者看 diff 是一次看一处,攻击者看的是整个系统里能互相握手的两个点。
真正让她睡不着的,是喂进大脑的内容
Sarah 说,上下文引擎里那些”看起来很有帮助”的内容,才是真正吓到她的地方。命令执行本身,她反而没那么担心。这套引擎把那些取材打包成 skill bundle,通过 MCP server 推给 wizard,运行时直接加载进 Agent 的上下文。
她设想了一个具体场景。PostHog 所有项目都开源,如果有人在仓库里开一个 PR。在 markdown 文件或者代码注释里塞进一段东西,团队自己用的 LLM 代码审查可能恰好扫过去说”看着没问题”。这段内容就会被打进签过名的 skill 包,推给几千台正在跑 wizard 的开发者机器。攻击者不需要碰用户的代码库,也不需要碰 Agent 本身,只需要碰内容。这次推演改变了她对风险来源的判断:最危险的输入未必是用户敲进终端的字。它更可能是团队自己的供应链——自己的仓库、自己的文档、自己审核过的内容。
Warlock:两端各扫一次,假设第一道会失灵
应对办法是在链路两端各扫一次:skill 构建发布的时候扫一次,wizard 真正调用的时候再扫一次。方法论很朴素,在源头抓一次,假设源头会失败,再在使用点抓一次。她把这个独立出来的扫描器叫 Warlock,理由也很直白:长得像 wizard 的东西都需要一个保镖。
Warlock 只做一件事:塞给它一段字符串,它吐回一串发现。每条发现带分类、严重程度和建议动作,然后就停手,它只负责发现,不负责处置。发现问题和决定怎么处理是两份完全不同的工作,把它们分开,是整套系统还能被人看懂的关键。底层规则跑在 Yara 上。这是恶意软件研究员用了十五年以上的模式匹配引擎,完全确定性,同样的输入永远给出同样的输出。她说这是故意做得无聊。安全这件事上,无聊反而是优点。
Warlock 抓到的真实案例里,有两类让她印象最深。一类是子 Agent 行为:为了赶大任务,wizard 会派生子 Agent。这些子 Agent 试图绕开已经设好的护栏,到处翻代码库想把密钥”发明”出来,团队直接一刀切,禁止再派生子 Agent。另一类是 PII。不设明确规则的话,Agent 完全不在意数据暴露。它会心安理得地把邮箱和电话号码直接塞进事件里,因为在它看来这就是一次很正常的采集。至于提示词注入本身,她开玩笑说别乌鸦嘴,至今没在真实环境里抓到过一次恶意攻击。但抓到大量误报:demo 登录页、示例项目里的假密码、文档里举例用的敏感字符串。这些误报反过来让她重新想自己怎么写文档、怎么搭示例,不想让任何东西看起来像威胁。
让 LLM 当保安,还是当顾问
误报多了之后,团队加了一层 LLM 做的分诊,用来筛掉噪音。这里她面临一个选择:让这个 LLM 层当保安,还是当顾问。当保安最省事,把命令甩给它,问一句是不是攻击,该拦该放它说了算。但她放弃了这条路:不能把整个安全模型押在一次抛硬币上,模型今天状态好坏是不可控的。
她划的分界线是:检测和执行必须留在确定性和机械的一侧。规则命中就直接锁门、会话结束,这条路径上不会出现任何模型。拦截发生在问 LLM 意见之前,LLM 只在东西没拦下的情况下才补充意见,用来去噪,不用来放行。这一层如果自己出故障,要按最保守的方式失败,直接把所有正在跑的 wizard 全部杀掉。她的原话是,执行是要押上全部身家的部分,必须确定性。判断是加细节的部分,也是唯一容得下概率性东西的地方。
怎么写一条真正管用的规则
Warlock 每条规则分四部分。第一部分是自然语言写的元信息:严重程度、分类、动作、方向——是流进 Agent 的内容,还是 Agent 自己在写的内容。第二部分是要匹配的具体字符串,第三部分是允许规则触发的条件,第四部分是一组测试。她举了个例子:防”忽略之前所有指令”这类经典提示词注入,不能只堵”忽略”这个词。Agent 整天在读代码,这个词在注释和示例里到处都是,得匹配”动词加带指令味道的名词”这种组合。每条规则必须带测试,写清楚哪些内容该命中,哪些不该。那条”不该命中”的负向测试,是防误报的第一道防线。
严重程度也不能按”听起来多吓人”来定,得看真实世界的影响。她拿 rm -rf 举例:这个命令听着吓人,但也是大家一天删四十次 node_modules 的日常操作。一个动不动就在清理构建目录时报警的安全工具,最后的结局是被直接关掉,然后什么都抓不到。
现在的防线,和我看到的一点印证
Sarah 说的”真正的纵深防御”,落地是这样:
- prompt 只做引导,不再承担安全职责
- 一切执行都在沙箱里
- bash 默认拒绝
- secrets 走 vault,模型接触不到
- Warlock 扫内容的进出两端
- triage 去噪
- 全程埋 telemetry
她说,没有一层单独能扛住,但每一层都在做它擅长的那一件事。演讲收在三句话。一,不是确定性强制执行的东西就等于没被强制执行,prompt 不是安全规则。二,危险输入不只是用户敲的字,也不只是你允许它跑的命令,是流进模型的一切,包括团队自己写的内容。所以要扫自己的供应链,源头扫一次、调用时再扫一次。三,攻击是组合的,代码审查不是,审计里大多数缺口都是两件无害的事握手开门。
之前整理 Agent 安全相关的笔记时,看到的判断大多停在协议层或者产品层。有一篇分析提示词注入的长文论证过,这是大模型架构级的基因缺陷,解法要靠密码学签名给每条消息标身份。也有一款主打”行动前必问”的 Agent 产品,靠文件夹级权限和危险命令黑名单兜底。Sarah 这场的价值,是把这些还停留在”应该怎么办”的讨论,落到了一个真实生产系统的具体做法上。协议层的方案还没成熟。deny by default 加两端扫描加失败即锁死,这套朴素的工程手段已经先扛住了八千个开发者每周在跑的东西。这也是这一天主舞台里少见的一场。大多数场次在讲”生产级容器””可靠 Agent 栈”这类框架设计,Sarah 讲的是一次真实审计揪出的漏洞,和补上它们的具体过程。
来源与说明
本文基于 AI Engineer World’s Fair 2026 Day 4(本系列 Day 3)主舞台视频转录、官方日程信息,以及本地 Agent 安全相关知识库整理。文章不是逐字稿,而是按单场分享的主线、上下文和工程启发重写。
Codex CLI 深度
AI 模型横评
AI Agent 框架
Claude Code 订阅生存指南