AI 编程 Agent 的安全缺口：风险潜伏在任务描述阶段

Coding Agent 跨过了过去两年里很多流程都没有跟上的一条线。它们不再逐行给出建议了。给定一个任务，它们会阅读代码库、在多个文件中规划改动、运行测试、阅读失败信息并重试。开发者的角色从写代码变成了审查已经完成的工作。

这个转变就是安全问题所在，而且这其实不是模型的问题。

Coding Agent 现在实际做什么

Coding Agent 接收用自然语言描述的任务，分析相关代码，形成计划并执行它。要求在 Express API 上实现邮件验证，它就会找到路由和中间件的定义位置，为用户记录写迁移文件，添加中间件，实现验证接口，写测试，运行测试，修复失败的用例。数十个文件编辑和终端命令，中间没有任何审批步骤。

每个 Agent，无论产品名称是什么，都由相同的四个部分构建而成：分解任务的 Planner、具有终端、文件系统和通常还有 git 的执行环境、将测试输出和错误反馈回计划的反馈循环、决定模型能看到什么的上下文层。执行环境是 Agent 和只会输出代码的聊天机器人的真正分界线，因为它让 Agent 可以通过运行代码来检查自己的工作。

它们能可靠处理的任务范围比人们预期的更广：跨多个文件的特性开发、bug 诊断与修复、重构、测试生成、文档编写、依赖升级、性能优化。

漏洞从哪里来

Agent 编写的代码可能携带 SQL 注入、跨站脚本、不安全反序列化和有问题的认证检查。这些已经有大量记录。真正被忽视的是原因。

这些缺陷通常不是出现在模型写不出安全代码的时候。它们出现是因为任务描述从来没有说过安全在范围内。一条写着"添加搜索功能"而没有提到输入清理的提示语，经常会产生容易受到注入攻击的代码，而 Agent 没有任何信号表明这很重要。它只为给定的需求做了优化。

这是一个具体而有用的诊断，因为这意味着修复方法不是等待更好的模型。Agent 在明确需求上表现强，在隐含需求上表现弱，所以进入生产环境的缺陷就是那些没有人写下来的东西。

特性级需求优于通用警告

直觉的做法是在每个提示语后面加一段安全样板文字。这产生的效果低于你的期望。广泛的威胁模型语言往往会产生看起来像是有人考虑过的安全形状的计划和测试，而没有实际解决具体的缺陷。更糟的是，看起来像是已经审查过的输出会招致更少的审查。

有效的是更窄范围的东西。对于你面前的改动，说明威胁、攻击路径和你需要的对策。写可以验证的结果，而不是无法验证的原则。"参数化每个由搜索字符串构建的查询"是可以检查的。"遵循安全最佳实践"是不行的。

这与文档提取中出现的相同教训：单一全局准确率目标什么都告诉不了你，而逐字段验证才能告诉你一切。通用指令没有东西可以对照检查。

像审查新承包商一样审查 Agent 输出

取得良好效果的团队收敛到相同的姿态。Agent 输出完全像来自称职的新承包商的工作一样对待：在任何东西合并之前，先做功能性审查，再做独立的安全审查。

在实践中，这意味着在人类打开 diff 之前，在每个 Agent 分支上运行自动化扫描。这意味着对你的系统重要的漏洞类别存在于任务模板中，而不是在某个高级工程师的脑子里。有些团队运行专门针对漏洞检测调优的第二个 Agent 作为专用通道。

当 Agent 能看到项目的 linting 和测试配置时，代码质量指标如复杂度和测试覆盖率与人类代码大致相当。差异出现在更微妙的地方：命名、注释质量、大规模改动中的架构一致性。这些正是人类审查仍然有价值的地方。关于 Coding Agent 如何规划、执行以及哪里会出错，完整的分析更详细地涵盖了架构和成本方面。

Agent 不是最薄弱的环节。Specification 才是。你在任务描述中遗漏的每个假设都是一个 Agent 从未被要求满足的需求，而安全假设正是团队最常遗漏的那些，因为这些从来没有为人类开发者写下来过。没有人需要告诉高级工程师搜索框会被陌生人输入内容。

把它写下来。然后像审查承包商的第一条 Pull Request 一样审查结果。