昨天 OpenAI 发了一篇安全文章标题叫《The Defender’s Window》。里面有个细节很容易让人记住。Greg Brockman 让 ChatGPT Work 用公开可用的 GPT-5.6 Sol 检查自己的个人网站。这个网站并不复杂静态站点AWS 托管Cloudflare 在前面。大约 15 分钟模型找出了 13 个问题。官方文章举出的例子并不是什么电影里那种“超级黑客漏洞”而是很普通的安全债邮件域配置不完整、前端依赖过旧、Cloudflare 到源站的一段链路仍然使用了不安全配置等。后面模型又花了大约一个小时协助修复和调整这些配置。我觉得这件事最值得关注的地方不是“AI 会不会黑客”。而是以前因为人工时间不够而长期没人检查的那批低优先级问题正在变得越来越容易被机器批量发现。这会改变安全工作的优先级。过去很多团队心里其实有一张默认风险表高危零日 立即处理 严重漏洞 尽快处理 旧依赖 有空再说 过度权限 等重构 DNS/邮件配置 以后再补 废弃服务 暂时别动 测试环境暴露 应该没事这个排序有一个隐含前提攻击者的时间也是有限的一个不显眼的小配置错误如果单独利用价值不大攻击者可能懒得看。AI Agent 改变的恰恰是这个成本结构。如果机器能够自动枚举 比对 检查配置 阅读代码 关联资产 发现异常那么以前“不值得人工花时间找”的问题会突然变得值得批量寻找。这就是我理解的 Defender’s Window。我会先还哪几类技术债不是先买一套新的 AI Security 产品。我会先清下面五类东西。1. 身份和权限这是我会排第一的。检查离职账号长期不使用账号管理员权限Service AccountAPI Key云 IAM数据库高权限用户CI/CD 凭证第三方集成 Token。很多严重事件最后并不是靠“神奇漏洞”完成而是拿到一个本来就权限过大的身份所以最值得问的不是这个账号会不会被盗而是如果它今天真的被盗能做多大范围的事权限应该按 blast radius 设计。2. 长期没人升级的依赖依赖治理最怕这种状态能跑 所以不敢动几年以后变成因为太老 更不敢动我会至少维护组件 当前版本 最新安全版本 是否公网暴露 是否有已知漏洞 Owner 升级窗口不需要第一天全部升级。先让“没人知道它存在”变成“有人负责”。3. 被遗忘的公网资产最危险的系统有时候不是主站而是old-admin.example.com staging.example.com test-api.example.com legacy-vpn.example.com没人维护但 DNS 还在。证书还在。端口还开着。甚至账号还是几年前的。先做资产盘点Domain Subdomain Public IP Cloud Account Public Bucket Load Balancer VPN Remote Access资产不知道就谈不上防守。4. 网络和信任边界很多内部系统默认能进内网 可信这个假设越来越危险。一旦某个账户、终端或服务失陷过于平坦的内网会放大影响。优先检查管理平面是否隔离生产数据库是否允许任意应用访问CI Worker 能否访问生产测试环境能否访问真实数据服务之间是否使用独立身份网络策略是否按最小范围开放。5. “一直知道但一直没修”的配置这一类非常真实。例如这个Header以后补 这个Bucket反正没人知道 这个账号先共用一下 这套老TLS改起来麻烦 这个Secret后面再换以前可以拖半年。现在我会重新评估。因为 AI 带来的不是单个漏洞威力突然变大而是寻找、组合和验证问题的成本下降OpenAI 文章里有一句话我觉得比“AI攻击”更重要它强调的方向并不是只让 AI 生成更多 Security Findings。目标应该是缩短发现问题 →确认问题 →生成修复 →验证修复 →安全发布这条链路。这点非常重要。很多安全平台已经有一个老问题扫描器每天报 3 万个问题最后真正修的很少。如果 AI 只是让 3 万变成 30 万防守反而更差。所以我会把 AI 安全 Agent 的 KPI 定成有效修复数而不是发现数一个安全 Agent 最好不要拥有“无限修复权”可以分三档。自动修适合明确依赖版本更新格式化安全配置静态检查可验证问题测试覆盖充分的低风险代码。流程发现 →开PR →CI →自动合并/人工合并提议修适合IAM网络数据库认证基础设施。Agent 生成Change Proposal Diff Risk Rollback Plan人审批。只报告适合高影响生产系统可能造成业务中断证据不充分涉及合规。不要为了“自治”强行自动化。我更喜欢“安全不变量”这个概念与其每天问有没有漏洞不如定义一组系统必须始终成立的条件。例如生产数据库不能直接公网访问 CI Worker不能拥有生产管理员权限 任何长期API Key必须有Owner 所有生产Secret必须有到期或轮换策略 测试环境不能读取真实用户全量数据 关键写操作必须有审计然后持续验证这些不变量。security_invariants:-id:prod-db-no-public-accessseverity:critical-id:service-account-no-adminseverity:high-id:secrets-have-ownerseverity:mediumAI 很适合帮助找证据读配置解释差异生成修复建议。最终是否满足不变量最好仍由确定性程序判断。安全团队用 Agent也要给 Agent 上安全边界这是另一个容易被忽略的问题。安全 Agent 为了检查系统往往会被赋予代码仓库云配置日志资产清单漏洞信息权限信息。这本身就是高敏能力。所以必须限制Read Scope Write Scope Network Secrets Tenant Environment Approval不要因为它叫“Security Agent”就给管理员全权。一个我会实际推进的 30 天计划第 1 周把资产找全完成公网资产 代码仓库 云账户 高权限身份 关键依赖 Secret先不追求完美。先形成事实表。第 2 周定义 20 个安全不变量不要写 200 条。先写最关键的 20 条。要求每一条都能回答怎么自动检查 失败谁负责 多久修第 3 周让 AI 做“读和提议”只允许扫描 分析 生成PR 生成配置Diff不要直接生产修改。第 4 周挑 3 类低风险修复自动化例如依赖补丁静态配置明确的代码规则。验证误报和回滚。再扩。我反而不建议第一步做的事不是一上来让 Agent自动扫描全公司 自动修复所有漏洞原因是你可能连资产Owner是谁 哪些环境能改 哪些变更会停业务都没整理清楚。AI 会把执行速度放大。治理没跟上时速度越快事故也可能越快。最后昨天那篇文章给我的核心信号不是“AI 网络攻击时代来了”这种大标题。更实际的是技术债的安全折旧速度正在加快。以前一个没人管的小问题可能躺几年。以后机器能更便宜地读代码、读配置、枚举资产、关联弱点。防守方真正应该利用的窗口就是趁同样的能力也开始普及把那些“知道但一直没空修”的东西先清掉。新安全时代最值得投入的可能仍然是最老的几件事最小权限 资产清单 补丁 隔离 审计 安全发布只不过现在我们终于有机会让机器帮人把这些基础工作做得更快。