AI 安全员进政府代码库，真正关键不是 20 小时
第一性原理 佛学觉照

AI 安全员进政府代码库，真正关键不是 20 小时

| 阅读 11 分钟

Anthropic 在 7 月 6 日发布了一个很容易被误读的案例：Government of Alberta uses Claude to find and fix cybersecurity vulnerabilities across government systems。

最容易传播的数字是这个：Alberta 的技术与创新部门用 Claude Code 在 20 小时内扫描了 4.66 亿行政府代码。

这个数字当然惊人。但如果只看速度，反而会错过真正重要的东西。

这个案例不是“AI 替政府安全团队干完活”。更准确地说，它展示了另一种新工作流：AI agent 扩大安全审查覆盖面，人类工程师保留证据判断、补丁验证和发布控制权。

真正的问题不是 AI 扫得有多快，而是谁握着最后的发布权。

这不是普通的代码助手演示

根据 Anthropic 的案例说明，Alberta 从 2025 年开始使用 Claude Code，并同时使用 Opus 和 Sonnet 模型审查政府系统、发现漏洞并协助修复。

这不是一个单仓库 demo。

Anthropic 写到，团队把约 50 个 agent 并行跑起来，覆盖 1,280 个应用和 3,400 个代码库，寻找安全漏洞、基础设施和部署流程弱点，以及技术文档缺口。

Claude Code 不只是说“这里可能有问题”。更关键的是，它要把问题落到具体文件和代码行，解释原因，提出修复，必要时补测试。

然后，补丁发版前还要经过 Alberta 工程师 review and approve。

这条边界很重要。因为它决定了这个案例到底是治理进步，还是自动化冒险。

如果 AI 只是把全量代码库扫一遍，然后直接改生产系统，那是高风险自动化。

如果 AI 把隐藏在海量遗留系统里的问题变成可复核证据，再交给工程师判断，那它更像一个新的安全控制面。

公共部门为什么特别适合，也特别危险

政府系统有一个长期难题：代码旧、系统多、文档不完整、业务不能停。

很多公共服务不是没人知道它老，而是没人敢轻易动它。

Anthropic 的案例里有一个很典型的例子：一个约 25 年前用 Java 手写的补贴项目门户，原本开发耗时约 5 个月；在一些重建场景里，类似系统可以被压缩到 4 到 5 天。

这类数字背后的真实含义，不是“以后不用工程师了”。

它说明 AI 可以把遗留系统的理解成本降下来。

过去，团队要先弄清旧系统到底做什么、依赖什么、哪里危险、怎么迁移。这个前置理解成本常常高到让现代化项目一直拖着。

AI agent 如果能快速读代码、补文档、找风险、提迁移方案，就能把“没人敢动”的系统变成“可以分批处理”的系统。

但公共部门也因此更危险。

政府系统里有税务、补贴、医疗、身份、教育、企业、交通等高敏信息。AI 能读得越多，访问控制、审计、数据边界和最小权限就越重要。

所以这个案例不能被简化成“政府终于开始用 AI 写代码”。

它更像是在问：当 AI agent 进入公共基础设施代码库，什么样的责任链才算合格？

关键不是并行 agent，而是证据链

很多团队看到 50 个 agent 并行，会自然想复制规模。

这其实是错误顺序。

真正应该复制的是四层机制。

第一，范围要清楚。哪些代码库可以读，哪些不能读；哪些 agent 只能审查，哪些可以提出 patch；是否能碰 secrets、配置、生产凭据和外部网络。

第二，证据要清楚。每个发现都必须落到文件、代码行、触发条件、影响范围和可复核解释。没有证据的“安全建议”，只是另一种噪音。

第三，验证要清楚。AI 生成的修复不能只看起来合理。它需要测试、静态分析、人工复核，必要时还要有回滚计划。

第四，发布权要清楚。agent 可以提出改变，但不能偷走系统 owner、security lead 和 release manager 的判断。

如果这四层没有建立，agent 越多，风险越大。

因为它会把错误判断、重复报告、误报、危险建议和权限误配一起放大。

漏洞发现天然是双用途能力

这类案例还有一个必须讲清楚的边界：漏洞发现不是无条件的好事。

在防御者手里，它能让组织提前修补系统。

在攻击者手里，它可能变成攻击前的侦察和武器化入口。

Anthropic 最近在 Fable 5 cyber safeguards 中也把这个问题说得很直接：网络安全能力经常是 dual use，同一类技术既能帮助防御，也可能被用于攻击。

这就是为什么 AI 做安全不能只讨论模型能力，还要讨论授权、上下文和控制。

Claude Help Center 对 Opus 和 Sonnet 的实时 cyber safeguards 也提到，prohibited use 和 high-risk dual use 会被默认阻断，合法防御场景可以通过 Cyber Verification Program 申请调整。

这说明一件事：真正成熟的 AI 安全工作流，不会把“发现漏洞”当成一个单一按钮。

它会问：

这个代码库是不是你有权审查的？

这个请求是在修复防御问题，还是在生成攻击能力？

输出是文件行级证据，还是可直接武器化的 exploit？

有没有人工审批、日志、隔离分支、测试和回滚？

没有这些问题，AI 的安全能力越强，越像一把没有护套的工具。

这条边界还不能只放在模型输出层。0DIN 在 6 月底披露的一篇 agentic coding 工具风险研究里，把问题推进了一步：当 AI coding agent 被授权运行 shell、读取文件、访问网络和处理本地环境时，一个看起来普通的仓库、安装说明和错误恢复流程，也可能把风险带到开发者机器上。

这不是在说不要让 agent 读代码。

它说明同一套能力需要两层安全：一层约束模型不要生成明显危险的攻击能力，另一层约束 agent 运行时到底能碰什么、能执行什么、能访问哪些凭据、哪些命令必须人工确认。

企业和政府应该学什么

Alberta 案例最有价值的地方，不是让其他组织直接开 50 个 agent。

更实际的复制方式，是从一个小得多的闭环开始。

先选一个非生产仓库，或者一个有明确 owner 的低风险系统。

只允许 agent 查一类问题，比如依赖漏洞、权限配置、输入校验、日志泄露或文档缺口。

要求每个 finding 必须包含文件行、风险解释、修复建议、测试结果，或者说明为什么需要人工处理。

只让 agent 在隔离分支提 patch，不给它生产凭据，不让它碰 secrets，不让它直接发布。

然后记录四个指标：误报率、重复报告、人工审查时间、通过 review 的修复比例。

如果这些指标站得住，再扩大范围。

这才是从 Alberta 案例里能搬走的东西。

不是“AI 很快”。

而是“AI 进入安全工作流时，必须先变成可审计的同事”。

真正的新安全员

很多关于 AI agent 的讨论，都喜欢把 AI 写成一个新员工。

但在政府代码库这种场景里，真正的新安全员不是 AI 本身。

真正的新安全员，是一套人和 agent 共同组成的控制面。

agent 负责扩大覆盖面，快速读旧代码，提出线索，生成初步修复和测试。

人负责定义范围、判断严重性、确认证据、承担发布责任。

系统负责保留日志、限制权限、执行测试、隔离变更、阻断高风险双用途行为。

这三者合起来，才叫公共系统里的 AI 安全能力。

所以，Alberta 案例最值得记住的不是 20 小时。

而是它把 AI 放在了安全控制链上，而不是发布按钮上。

未来所有把 agent 接入企业和政府核心代码库的团队，都应该先回答同一个问题：

当 AI 找到一个“看起来应该修”的漏洞时，谁来证明它是真的，谁来决定它能不能上线，谁来为上线后的后果负责？

回答不了这个问题，20 小时只是速度。

回答得了，它才可能变成新的安全基础设施。

参考来源

💬 评论