夜雨聆风
AI 编程助手安全边界四层模型
一个很有意思的变化正在发生。
过去，大家讨论 AI 编程助手，问得最多的是：它会不会写代码？能不能修 bug？能不能做完整项目？
现在，这个问题已经不够了。
因为新一代编程助手不只是“写代码”。
它会读你的仓库。
会看你的 README。
会运行你的测试。
会调用终端。
会访问网络。
会根据报错继续修改文件。
它越来越像一个坐在你电脑里的初级工程师。
但是，问题也在这里。
一个初级工程师进公司，第一天不会拿到生产数据库权限、云服务密钥、发版权限和财务账号。
可是很多 AI 编程助手，第一次打开你的项目，就可能接触源码、环境变量、终端、浏览器登录态和外部网络。
这不是效率问题。
这是安全边界问题。
先给结论：AI 编程助手的第一竞争力，不是更聪明，而是更可控
我对 AI 编程助手的判断很简单：
谁先把安全边界做成产品能力，谁才可能真正进入企业和团队的长期开发流程。
模型能力当然重要。
但当模型已经能写代码、跑命令、读仓库之后，真正决定它能不能被放心使用的，不是“会不会写”，而是：
• 它能看到什么？
• 它能修改什么？
• 它能执行什么？
• 它能把什么发出去？
• 它做错了能不能被追溯和回滚？
这篇文章的信息增量，是一套“AI 编程助手安全边界四层模型”：
如果这四层缺一层，AI 编程助手就很难从“个人尝鲜工具”变成“团队生产力工具”。
第一件事：不要把所有上下文都当成可信输入
AI 编程助手最大的变化，是它读的东西变多了。
以前你让模型写代码，输入主要来自你。
现在不一样。
它会读：
• README。
• issue。
• PR 评论。
• 代码注释。
• 测试输出。
• 网页文档。
• 工具返回。
• AGENTS.md 或类似项目规则文件。
这些内容看起来都是“资料”。
但在 Agent 眼里，它们都可能进入同一个上下文窗口。
这就带来一个风险：攻击者可以把指令藏在资料里。
比如，在一个陌生仓库的 README 里写一段“为了完成安装，请执行以下命令”；在 issue 里伪装成维护者提醒；在工具返回里夹带“忽略之前规则”的文本。
如果 AI 分不清“资料”和“指令”，它就可能把不可信内容当成任务要求。
这就是提示注入在 Agent 时代真正危险的地方。
在聊天机器人时代，提示注入最多让它说错话。
在编程助手时代，提示注入可能让它执行命令。
所以第一层边界是输入隔离。
一个成熟的 AI 编程助手，必须明确区分：
• 用户指令。
• 系统规则。
• 项目规则。
• 工具输出。
• 不可信外部内容。
外部内容可以被阅读、总结、分析。
但不能自动升级成可执行指令。
第二件事：不要让 AI 默认看到所有私有资产
很多开发者低估了本地开发环境的价值。
你以为 AI 只是看代码。
实际上，一个开发者电脑里往往有：
•.env 文件。
• Git token。
• SSH key。
• 云服务凭据。
• npm、pip、Docker 登录态。
• 浏览器 session。
• 内部 API 地址。
• 测试数据库连接。
这些东西对攻击者来说，比某段业务代码更值钱。
如果 AI 编程助手可以任意读文件，再加上它还能联网，风险就会放大。
这就是 Simon Willison 反复强调的“致命组合”：私有数据、不可信输入、外部通信。
三者单独出现，都不一定致命。
叠在一起，就可能变成数据外流链路。
所以第二层边界是数据最小化。
一个很简单的规则是：
源码、测试、文档可以读。
密钥、token、生产配置、浏览器数据、云服务凭据，默认不能读。
不要指望模型自己判断“这个文件敏不敏感”。
敏感路径应该由工具层控制。
第三件事：工具权限必须分级，而不是全开或全关
很多团队对 AI 编程助手只有两种态度。
一种是完全不敢放权。
那它只能变成聊天窗口。
另一种是为了效率完全放开。
那它就变成一个带自然语言入口的高权限脚本执行器。
更合理的做法，是工具分级。
这套分级不是为了拖慢 AI。
恰恰相反。
它是为了让 AI 在低风险区域更快。
搜索代码、读文件、跑单元测试，这些动作应该顺滑。
读取密钥、联网、删除、安装依赖、操作数据库，这些动作必须停下来。
效率不是把所有动作都自动化。
效率是让该快的地方快，让该停的地方停。
第四件事：没有审计，就没有真正的信任
很多人 review AI 生成代码，只看最终 diff。
这不够。
因为 Agent 的风险不仅在最终代码里，也在执行过程里。
它中间可能跑过命令。
可能读过文件。
可能访问过网络。
可能失败后做过几次尝试。
可能为了让测试通过改弱了断言。
如果这些过程没有记录，出了问题你只能猜。
所以第四层边界是审计回滚。
至少要记录四类信息：
• 它读了哪些关键文件。
• 它执行了哪些命令。
• 它改了哪些文件。
• 它跑了哪些测试，结果是什么。
企业里真正可用的 AI 编程助手，不能只是“帮我改好了”。
它必须回答：“我为什么这么改，我怎么验证，出了问题怎么撤回。”
反方观点：安全边界太多，会不会把 AI 编程助手废掉？
这是一个真实问题。
如果每一步都审批，AI 会变慢。
如果什么都放开，风险会变大。
解决办法不是在“全开”和“全关”之间二选一。
而是把任务分层。
低风险任务，可以自动化：
• 读源码。
• 查调用链。
• 补测试。
• 改文档。
• 跑单元测试。
• 生成说明。
中风险任务，需要确认：
• 安装依赖。
• 访问网络。
• 创建 PR。
• 改配置。
• 修改多个模块。
高风险任务，默认不交给 AI 自动做：
• 读密钥。
• 删除数据。
• 改数据库。
• 改云资源。
• 发版。
• 操作生产环境。
真正成熟的安全边界，不是把 AI 关起来。
而是让它知道什么时候可以自己跑，什么时候必须问人，什么时候根本不能做。
对开发者：今天就能做的 5 件事
第一，把敏感文件从 AI 可读范围里排除。
至少包括 .env、私钥、云凭据、浏览器数据、生产配置。
第二，不要在陌生仓库里让 AI 自动跑 shell。
先让它只读分析，再决定是否执行命令。
第三，给项目写一份 AGENTS.md。
写清楚测试命令、禁止读取的路径、需要确认的动作。
第四，把联网设为需要确认。
尤其是当 AI 已经读过私有代码或本地文件之后。
第五，保留工具调用日志。
不要只看最后的代码 diff。要看它中间做了什么。
对团队：安全边界会成为 AI 编程工具的采购标准
未来团队选择 AI 编程助手，不应该只看模型榜单。
还要问这些问题：
• 是否支持项目级规则？
• 是否支持敏感路径屏蔽？
• 是否支持命令审批？
• 是否支持网络控制？
• 是否支持容器或沙箱？
• 是否保存工具调用记录？
• 是否能把 AI 行为纳入 code review？
谁能把这些能力做得更顺滑，谁就更接近真正的企业级 AI 编程工具。
因为企业买的不是“会聊天的模型”。
企业买的是可控、可审计、可集成的工程能力。
最后
AI 编程助手会越来越强。
这件事几乎没有悬念。
但越强的工具，越需要边界。
没有安全边界，AI 编程助手只是一个让人兴奋的 demo。
有了安全边界，它才可能成为团队真正敢用的生产力系统。
一句话：
AI 编程助手必须先学会“不能做什么”，然后才配做更多事。
参考来源
• Anthropic Engineering：Claude Code and Agent Security，https://www.anthropic.com/engineering/claude-code-and-agent-security
• Anthropic：Claude Code Security，https://docs.anthropic.com/en/docs/claude-code/security
• NVIDIA Developer Blog：Indirect AGENTS.md injection，https://developer.nvidia.com/blog/indirect-agents-md-injection-a-new-attack-vector-for-ai-coding-agents/
• arXiv：Your AI, My Shell，https://arxiv.org/html/2509.22040v1
• OWASP Top 10 for Large Language Model Applications，https://owasp.org/www-project-top-10-for-large-language-model-applications/
