后AI时代的产品安全
内容提要
AI改变了软件开发流程，传统线性SDLC已被循环往复的“Jeremy Bearimy”模式取代。安全团队不能再固守某一阶段，而应随工作流动：将安全要求、设计模式和威胁模型做成智能体可主动获取的上下文与插件，并对智能体设置强制护栏。核心仍是信任、最小权限和“假设失陷”等原则。DigitalOcean曾发生沙箱逃逸，但因架构按不可信环境设计，影响有限。
延伸解读
从“推”到“拉”：安全团队的角色转变
文章指出，传统安全团队常通过强制要求、审批关卡和追票来“推”动开发人员，这会消耗积累的信任。在AI智能体参与开发后，安全团队应转向构建“拉”式项目：提供工程师和智能体主动愿意使用的工具与指南。因为向智能体推送要求的成本极低，智能体会直接适应并继续工作，所以安全团队可以把要求做成智能体可获取的上下文和插件，而非对人员设卡。
智能体护栏：把门禁设在智能体上
文章认为，在“Jeremy Bearimy”式循环开发流程中，安全不能再固守某个阶段。有效做法是将安全要求、设计模式和威胁模型转化为智能体可主动获取的上下文，并对智能体设置强制护栏，阻止其绕过非可选要求。文章以SSRF为例：智能体在获得安全插件和钩子后，能自动识别风险并采用批准的外呼模式，无需工程师事先知道要询问安全团队。
沙箱逃逸事件：架构设计决定影响范围
DigitalOcean曾发生AI产品沙箱逃逸，研究人员逃出后可在服务环境执行命令。但由于Secure Design团队按“不可信环境”和“假设失陷”原则设计架构，逃逸者无法横向移动：存储凭证只读且限于客户已连接的资源，计算环境为单租户。文章据此说明，最小权限和“假设失陷”等旧原则在智能体开发时代依然关键，只是交付方式变为智能体可拉取的上下文。
Q&A
AI时代软件开发流程发生了什么变化，导致传统安全模式失效？
AI使软件开发不再遵循线性的SDLC（需求、设计、构建、测试、部署、运维），而是变成循环往复的“Jeremy Bearimy”模式：设计可能在深夜的提示中发生，智能体在站会前就提交多个PR，测试阶段缩短到几分钟，甚至先有实现再反推需求。安全团队无法再锚定在某个固定阶段，必须随工作流动。
在AI驱动的开发模式下，安全团队应该如何调整工作方式？
安全团队应停止固守某个阶段，转而随工作流动：将安全要求、设计模式、威胁模型等知识做成智能体可主动获取的上下文和插件，并对智能体设置强制护栏（hooks），让智能体在生成代码时直接拉取安全上下文，而不是向开发者推送要求。
DigitalOcean如何通过安全设计降低沙箱逃逸的影响？
DigitalOcean的Secure Design团队在开发时就将服务环境设计为不可信，遵循“假设失陷”原则。当研究人员逃逸沙箱后，发现存储凭证是只读且仅限客户已连接的资源，计算环境是单租户的，活动会关联到其账户，因此无法扩大影响，仅作为加固清理处理。
产品安全团队如何平衡安全要求与开发速度？
产品安全团队应通过“拉取”而非“推送”的方式：提供开发者主动使用的工具和指南，积累信任；对于智能体，推送要求成本极低，可以设置强制护栏。同时，安全债务计划允许路线图负责人灵活决定修复时间，无需安全团队批准延期，从而在保持问责的同时最大化速度。
智能体在安全开发中能起到什么作用？能否举例说明？
智能体可以主动拉取安全上下文并应用到代码生成中。例如，当工程师要求智能体实现webhook注册功能时，智能体识别到SSRF风险，会拉取安全团队提供的出站调用模式，自动实施阻止内部地址、DNS重解析检查、禁止重定向、签名载荷并编写回归测试，无需安全团队介入。
后AI时代产品安全的核心原则有哪些变化？
核心原则如信任、最小权限和“假设失陷”并未改变，改变的是交付方式。安全团队仍需确保产品设计遵循安全基础，但如今通过智能体拉取的上下文和护栏来传递这些原则，而不是依赖固定的评审阶段。
