2026Q2 AI安全创新项目回顾
原创 aerfa21 2026-09-07 21:06 浙江
15 个 AI 安全项目做完，我最大的感受不是「AI 真能干」，而是「终于看清它哪块干不了」。能接重复的活，替不了拍板的活，还开了一个要有人去守的新战场——保护 AI 本身。复盘写在公众号了，带团队做 AI 方向的朋友可以来聊聊。
上一篇我写的是市场——28 份 AI 安全岗位的 JD 翻下来，最贵、最稀缺的是「既懂安全、又懂大模型」的人。有同行看完问我：那你们自己是怎么干的？
这篇就讲我们自己。把市场需求当成一个输入，结合团队的职责和业务实际，我们在 Q2 铺开了一批 AI 项目。半年做下来，最值钱的收获不是做出了多少东西，是我们慢慢摸清了 AI 在安全上到底能干什么、干不了什么——也就是它的能力边界。
先交代一个前提：为什么拖到今年才动手
在网络安全部，安全运营是动手最早的一批，早几年就在用大模型做告警分析、工单处置。但有件事我一直没做：把 AI 写进团队成员的 OKR。
不是不重视，是两个顾虑。一个是还不够成熟，AI 用在安全上，头两年更像锦上添花，能辅助，但撑不起一个要考核、要产出的正式目标。另一个，是我更在意的——怕大家一心研究 AI，把安全基本功丢了。渗透、漏洞、攻防，这些是吃饭的家伙。AI 火起来那阵子，圈子里确实有人一头扎进去，最后基本功（原本就不扎实）松了，AI 也没做出名堂。我不想让团队变成那样。
变化发生在今年。AI 到了能落地的拐点，再不下场就晚了。Q2 定 OKR 的时候，我让内部蓝军和产品安全两个团队的每个人，都给自己至少定一个 AI 相关的专项。配套也一并给了：公司出模型资源，我给大家划出正规、正式化的学习和应用时间 - - 不是让大家业余偷偷试，是名正言顺地学、名正言顺地用。
这批 AI 项目，就这么铺开了。
在上个季度，我们铺开了 15 个项目
这 15 个项目，是贴着团队的两条职责线展开的——一条是攻击，一条是产品安全，外加几个给两条线供弹药的支撑性项目。我把它们都摆出来，不是为了晒数量，是想让大家看清楚：我们把 AI 试在了哪些地方。
攻击这条线，试的是「AI 能不能帮我们更快、更深地找漏洞」：
AI 组件漏洞挖掘：对着公司里在用的模型、Agent、AI 组件做漏洞挖掘，第一次把枪口对准了「AI 本身」。
Web 漏洞挖掘 Agent：用多个 Agent 协同，自动挖 Web 漏洞。
白盒漏洞挖掘 Agent：让 AI 读源码，挖代码里的洞。
攻击路径规划：让 AI 自动规划多步攻击链。
AI 渗透比赛：出去打比赛，以赛代学代练。
C2 开发：攻防基础设施，这个后来暂缓了。
产品安全这条线，试的是「AI 能不能把 SDL 里的脏活累活接过去」：
安全需求智能分析：让 AI 读需求文档，提取该补的安全点。
AI 代码审计：HW前，用 AI 对产品代码做漏挖。
PSIRT 工单 AI 处置：安全工单让 AI 自动分析、自动派发。
SRC 漏洞报告分析：让 AI 自动读外部漏洞报告、尝试复现。
恶意组件监控：盯着供应链里的恶意组件。
MCP 工具开发：摸 Agent 时代的「API 安全」。
供货提测数据分析：给重要客户的供货产品安全测试做提效。
支撑性的，是给上面两条线供弹药的：
BAS 运营：攻防演练的自动化、持续化。
技术文章监控与 TTPs 提取：让 AI 盯着外面的新技术、新手法，转化成我们自己的检测规则。
这 15 件事的产出是实实在在的：39 个 AI 组件排查，247 个漏洞，5 台服务器被拿下控制权；AI 代码审计在护网前对 8 款产品漏挖出 64 个漏洞；安全工单的 AI 处置比例做到 56%；还沉淀了 71 条安全需求、42 个验证用例。
单看这些数字，是一份说得过去的答卷。但对我来讲，这些实践的价值不在数字，而在做完这 15 件事之后，我们摸清了一条线。
这次最大的收获：摸清了 AI 的能力边界
15 个项目试下来，我最想说的不是「我们做出了什么」，而是「我们搞清楚了 AI 的边界在哪」。这个边界，大概划在三件事上。
第一件，AI 能干的，是重复且有规则的活。告警研判、代码初筛、报告复现、需求归类——这些以前要堆人的活，AI 现在能稳定地接过去，而且比人快、比人不累。这一类，我们不用再纠结「要不要用 AI」，答案已经清楚：它可以当生产力用了，不是玩具。
第二件，AI 干不了的，是需要对抗直觉和拍板的活。真正的攻防对抗、体系怎么设计、一个漏洞到底要不要修、修到什么程度——这些要经验、要责任、要判断力的事，AI 顶多是个助手。它提供一堆选项，但下不了决心。谁要是觉得 AI 能把安全负责人也替代了，那是把「提效」和「决策」两件事混为一谈了。
第三件，也是最容易被忽略、最要命的一件：AI 本身，成了新的攻击面。Agent、MCP、记忆机制，这些 AI 时代的产物，天生带着一堆我们以前没见过、也防不住的漏洞。这不是「用 AI 做安全」，是「保护 AI 本身」——一个全新的战场。
这三件事合起来，就是 AI 在安全上的能力边界：能接住重复的活，替不了拍板的活，还顺手开了一个需要有人去守的新战场。
收敛的标准：能不能沉淀成产品
边界清楚了，下半年怎么走，也就不需要拍脑袋了。
我先摆三个输入：一是市场——上一篇那 28 份 JD 说得明白，最贵、最稀缺的是「保护 AI 本身」；二是刚摸清的能力边界——提效的活我们已经有底了，真正的稀缺在「保护 AI」；三是业务实际——供货安全、PSIRT、SRC 这些刚需，一条都不能停。
这三个输入解决的是「劲儿该往哪使」。但真要决定留哪个、砍哪个，我用的是一条更冷的标准：这件事做完，是变成一个人的手艺，还是沉淀成团队能复用、能放大、能产品化的能力。
手艺会跟着人走，人一变动，能力就断了；只有沉淀成产品、工具、方法的东西，才留得下来，才能复用，才能放大。所以收敛的时候，我优先留下那些能沉淀成产品的，砍掉那些做完就完了、只挂在某一个人身上的。
按这条标准过一遍，15 个项目归拢成 5 个主题：
Agent 安全
：也就是「保护 AI 本身」，从零搭一套 Agent 安全测试体系，把挖洞的手艺沉淀成一套可复用的方法。
SRC 漏洞验证
：把「AI 自动复现漏洞报告」跑通全链路，沉淀成能反复用的流程和工具。
AI 资产攻防
：先把公司里的模型、Agent、MCP、RAG 这些 AI 资产摸清家底，再做体系化攻防，把零散的攻防动作沉淀成体系。
AI Native SDL
：把需求分析、代码审计、工单处置这些散点，拧成一条嵌进安全左移的完整线，这是把产品安全的能力往产品里沉淀。
AI 黑盒扫描器
：把攻防能力沉淀成工具，替代日常渗透里那些重复的人工测试，支撑日常安全测试。
这五个有一个共同的指向：都不是「做一次就完」的事，而是「做完能留下来、能被反复用」的事。收敛不是砍，是往能沉淀成产品的方向聚焦。边界清楚了，才知道哪几个方向值得把人手和精力压上去。
一个我一直守着的边界：什么能对外说
这里想借这篇文章，把一个边界讲清楚。
团队里的具体成果，比如谁挖出了什么漏洞、谁搭了什么体系，走内部渠道——月度简报、公司级输出，让该看到的人看到。我个人的公众号只写自己的思考、方法论和判断，不拿同事的具体产出当素材。
这不是藏私，是尊重。一个团队的成果属于团队，不该变成某个人刷存在感的素材。我能写的是：我怎么看这个市场、我怎么铺项目、我怎么摸边界、我怎么收敛。这些是我的东西。
所以看这篇文章时，我列的是项目方向、讲的是判断和取舍，而不是「谁挖出了多少漏洞」——那些数字属于团队，在内部报表里，不在公众号上。
接下来：把「保护 AI」这件事讲清楚
最后说点往后的事。
摸边界的过程里我发现，要把「保护 AI 本身」做深，绕不开一个更基础的问题：怎么把 AI 安全讲清楚。不光是给团队讲，更是给每一个还没入门的同行、甚至非安全圈的人讲。因为这门知识太新，新到没有一个共识的框架——大家说 Prompt 注入，十个安全人里八个听过、三个能说清原理、一个真正动手测过。这种状态下，团队内部要拉齐认知，光靠一份测试规范不够，得有一套能被人看懂、记住、复用的东西。
所以下半年，我打算在公众号上分两条线写实践：一条是 AI for Security，怎么用 AI 把安全测试、代码审计这些重复的活接过去，我们踩过哪些坑、边界在哪；一条是 AI Security，怎么守住 Agent、模型这些 AI 本身新冒出来的风险。不追热点，也不写事件盘点，就是把自己动手做过的事摊开来，让外行也能听懂 AI 安全到底在防什么。
这篇，是这个系列开张前的一次铺垫：先把我们为什么死磕「保护 AI 本身」、AI 的边界到底在哪讲清楚，后面的实践才有来处。
如果你也在带团队做 AI 方向的尝试，欢迎留言说说你摸到的边界是什么样。这种判断，一个人想容易钻进死胡同，多个人对一对，往往能想明白。
长按识别二维码，和我交流
More...
-- 深耕研发安全 --
-- SDL 100问 --
......
--------- AI安全事件分析 ---------
-- 软件供应链对抗探索 --
--------- 实战演习 ---------
--------- 安全运营 ---------
--------- 软件安全 ---------
--------- 企业安全 ---------
--------- 渗透测试 ---------
--------- 安全开发 ---------
--------- 个人体验 ---------