Figma 公开 AI 代理代码安全实践

Figma 在官方博客中详细披露了其如何利用 AI 编码代理在代码生成、Pull Request 审核、历史代码审计三个阶段持续发现并修复安全漏洞，并把这一整套实践沉淀为一份可被新员工直接阅读的「威胁模型」。

为什么先做 PR 审核

Figma 安全团队选择先构建 PR 审核代理，因为它的改进闭环最快。这一阶段有三个关键特征：覆盖所有 PR 的「通用性」、作者直接在 PR 内回复发现的「自助性」，以及精确率（precision）与召回率（recall）各自独立可测的双向信号。

精确率靠 PR 作者对每条发现点赞或点踩来度量；召回率则通过让审核代理重跑已知存在 bug 的提交、统计漏报数来衡量。

双模型并行，各补其短

目前 Figma 同时运行 Claude Code（Opus 4.8，xhigh 算力档位）与 Codex（GPT-5.6 Sol，high 算力档位）两套代理，因为两款模型遗漏的漏洞种类不同——只要任一模型命中一条发现，就会被推送给开发者。每次 PR 审核的中位花费约 0.5 美元，绝大多数 PR 没有任何需要标记的内容。

代理也曾捕捉到涉及复杂多步骤链路的漏洞：在某次 PR 中，它推演出一个被注入的 sandbox 对象泄露了宿主 realm 的 Function 构造函数，进而打开桌面客户端代码执行路径。

从 15% 到 70% 精度的爬坡

2025 年 8 月 Anthropic 发布 Claude Code Security Reviewer 后，Figma 当天即以「影子模式」部署：结果只送往 Slack 与 Datadog，不直接出现在 PR 评论中。第一周共产生 27 条发现，仅 4 条为真实漏洞，精确率约 15%。

Figma 设定 70% 精确率为目标——理由是「团队成员愿意读的发现，必须是十条里至少有七条真的」。为达到这条线，安全团队回放了过去 8 周的 PR 记录并人工标注误报，据此写出代理应遵循的策略。

用先例代替规则

策略文档全文 99 行、2,560 字、68 条「先例」（precedent）。Figma 在写法上更偏好先例而非宽泛规则：例如不写「在 dbops 中不要标记 SQL 注入」，而是写「dbops 只由拥有直接数据库访问权的高权限操作员调用」。这样的表述保留了代理执行安全推理所需的上下文，也更接近人类安全工程师的判断逻辑。

写作过程还带来一个意料之外的副产品——这份策略本身已经等同于一份完整的威胁模型，形态上恰好是新员工入职第一天应当阅读的安全全景图。

同一份策略，串联三道关

由于代码生成、历史代码审计与 PR 审核共用同一份策略，Figma 不必为每个环节单独构建威胁模型。代理需要的安全上下文必须以显式、结构化、极高分辨率的形式存在，而过去十年这些上下文散落在文档、事故复盘与团队记忆中，如今第一次被统一沉淀到这份 99 行的策略文档里——它才是整个代理安全体系的真正回报。