被 Agent 重新激活的 16 个网络安全难题

安全行业有一个长期存在的尴尬：很多方案在论文里很漂亮，在真实系统里却很难普及。

形式化验证可以提高协议可信度，但把自然语言标准翻译成可验证规范，成本极高；SELinux、AppArmor、seccomp 可以做细粒度隔离，但策略配置复杂到很多团队宁愿绕过；C/C++ 到 Rust 的迁移有明确安全价值，可大型遗留系统的改写成本往往压过收益；威胁归因、溯源取证、供应链审计都很重要，却严重依赖少数专家。

这些方向失败的原因，很多时候不是技术路线错误，而是经济账算不过来。

6 月 22 日，Stevens Institute of Technology、University of Wisconsin-Madison、Microsoft Security Response Center、KIT 等机构研究人员发布论文《Rising From the Ashes: How Agentic AI is Unblocking Challenges in Cybersecurity》。

论文 PDF

这篇文章没有提出一个新的检测算法，也没有给出某个 benchmark 的 SOTA 结果，而是提出了一个更偏趋势判断的问题：Agentic AI 是否会让一批曾经“太贵、太慢、太依赖专家”的安全技术重新具备落地条件？

论文系统梳理了5 类长期阻塞因素、5 类 Agent 能力，并进一步展开到16 个网络安全 case study。

这篇文章最值得关注的地方，不是“Agent 能不能替代安全人员”，而是它提醒我们：Agent 正在改变安全防守的成本结构。

安全行业真正被卡住的地方

论文先把安全技术难以规模化的问题拆成 5 类。

第一类是人工成本过高。有些安全任务不是做不了，而是没人有时间做。例如给大型代码库手工加安全插桩、为小众协议编写完整形式化规范、逐个仓库梳理真实依赖关系、给每个业务系统单独调访问控制策略。单点项目可以投入专家，规模化之后就会变成长期人力黑洞。

第二类是响应时延太低。安全事件有时必须在攻击完成前响应。比如自愈系统要在 exploit 生效前修复状态，实时监控要在攻击路径扩散前找到关键子图，内部威胁检测要在账号继续窃取数据前做出处置。人工分析的节奏很难赶上攻击链推进速度。

第三类是专家稀缺。漏洞挖掘、内核安全、浏览器安全、编译器、密码协议、威胁情报、取证溯源，每个方向都需要深厚经验。更麻烦的是，真实攻击往往跨多个领域，一次复杂分析可能同时需要代码、系统、网络、情报和业务知识。

第四类是任务高度定制化。一个系统的安全策略，很难直接复制到另一个系统；一个代码库的 Rust 迁移经验，也很难直接应用到另一个代码库；一个供应链风险模型，在不同语言生态、构建系统、组织流程中都需要重新适配。

第五类是问题本身复杂。安全任务很少只看单一信号。判断一个告警是否重要，可能要同时看进程树、文件访问、网络连接、用户角色、业务时间窗口、历史行为、威胁情报和攻击 TTP。人类分析员很难长期稳定地把这些上下文全部纳入判断。

论文的判断很直接：这些阻塞因素共同导致很多安全技术停留在“专家项目”“实验系统”“高价值目标保护”阶段，难以变成常规部署步骤。

Agent 为什么可能重新改变这件事？

论文对应提出了 5 类 Agentic AI 能力：自然语言理解、大规模信息处理、认知耐力、泛化与复制、多学科知识整合。

自然语言理解让 Agent 可以直接读取标准、策略、报告、需求文档，也可以生成代码、配置和分析结果。它降低了“把现实问题转成工具输入”的门槛。

大规模信息处理让 Agent 可以同时处理代码库、日志、依赖关系、漏洞库、威胁情报、用户行为等多源数据。很多安全问题的难点不在单点判断，而在上下文太多。

认知耐力让 Agent 可以持续执行重复、繁琐、标准化但高要求的分析任务。安全分析员会疲劳，审计规则会漂移，Agent 至少提供了批量一致执行的可能。

泛化与复制让一次专家能力沉淀可以被复制到多个系统。专家不再需要给每个仓库、每台主机、每个业务系统从零手工处理，而是把经验固化到 Agent 工作流里。

多学科知识整合则解决安全领域的一个老问题：复杂攻击链经常横跨浏览器、操作系统、编译器、密码协议、供应链、业务流程。单一专家很难覆盖全部领域，但 Agent 可以把这些知识放进一个推理和工具调用框架中。

这也是论文的核心逻辑：

Agentic AI 不只是自动化现有流程，而是让过去很多“不经济”的安全方案重新进入可实施区间。

16 个被重新激活的网络安全难题

论文把16 个方向分成4 类：系统安全、软件安全、威胁情报、攻击检测。它们有一个共同点：过去都有技术基础，但都被成本、速度、专家、定制化或复杂度卡住了。

这 16 个方向可以看作 Agentic AI 进入网络安全的路线图。下面重点拆开看。

01 系统安全

把专家项目变成部署步骤

系统安全里有大量机制早就存在，但落地复杂度很高。

1. 安全插桩优化

很多安全技术需要在目标系统里插入额外代码，用于观察、约束或控制行为。例如 fuzzing harness、sanitizer hook、审计点、信息流控制点等。难点在于，插桩位置不能乱放，既要理解程序语义，又要理解安全分析目标，还要考虑性能成本。

论文认为，Agent 可以读取源码，理解分析目标，提出在哪里插桩、如何插桩，并辅助验证插桩是否有效。这样一来，安全插桩就有机会从多月人工工程变成可复制的分析流程。

2. 移动目标防御与软件多样化

移动目标防御的思路很早就有：让系统攻击面不断变化，提高攻击者适配成本。比如改变内存布局、指令选择、系统调用接口、网络端口、地址空间等。

问题在于，变化必须足够快，还不能破坏兼容性和性能。过去这类方案很难规模化，是因为它要求防守方同时懂编译器、运行时、系统部署和攻击模型。Agent 的潜在价值在于分析系统约束，生成多样化变体，并根据风险动态调整重配置策略。

3. 安全标准形式化

大量安全标准、组织规范和合规要求仍然是自然语言文本。真正要做形式化验证，就要把这些要求翻译成机器可检查的规范。

这一步很难，也很贵。Agent 的价值在于读取自然语言标准，生成候选形式化表达，再交给专家审查。它不能直接替代形式化专家，但可以把专家从“从零翻译文本”中解放出来，转向审查、修正和确认。

4. 供应链分析

供应链安全已经成为企业安全建设的核心方向，但现实里的 SBOM、依赖关系、包版本、贡献者行为、构建路径，经常存在不完整和不准确的问题。

论文指出，Agent 可以分析整个代码仓库，识别依赖及其版本，并与漏洞库交叉比对；也可以持续分析新贡献者公开信息和提交行为，辅助发现项目接管、typosquatting、dependency confusion 等风险。

这点非常适合落到 AI Coding 时代。因为代码生成工具会不断引入新包、新依赖、新配置，一旦缺少持续供应链审计，幻觉依赖、恶意包、包名混淆、依赖污染都会变成新的入口。

5. 安全自愈系统

普通自愈系统可以重启服务、切换流量、恢复进程，但安全自愈更复杂。

如果程序遭到攻击，系统不能只追求“不崩溃”。一个错误修复可能让程序绕过鉴权、进入不一致状态，甚至让攻击者获得更稳定的执行路径。论文强调，安全自愈需要理解当前攻击破坏了什么状态、哪些函数可以修复、哪些修复会造成更大风险。

Agent 的价值在于快速分析程序逻辑和攻击状态，生成针对当前场景的修复策略。但这个方向必须非常谨慎。真正落地时，Agent 不能直接在线修改生产系统，而应进入“建议修复—沙箱验证—策略审批—最小化执行—回滚审计”的闭环。

6. 系统安全策略定制

SELinux、AppArmor、seccomp、capability-based sandboxing 都可以做细粒度权限控制。现实里很多策略过于宽松，或者配置复杂到运维人员直接关闭。

论文认为，Agent 可以观察应用行为，理解策略语言，为每个部署环境生成定制化访问控制配置。

这其实对应一个很明确的产品方向：Agent 化最小权限配置生成器。它不是只给出“建议开启 seccomp”，而是读取进程行为、系统调用、文件访问、网络访问和业务场景，生成可测试、可回滚的最小权限策略。

02 软件安全

攻防能力都会被放大

软件安全是 Agentic AI 最容易引发争议的部分。

7. 漏洞发现

复杂漏洞发现需要跨领域知识。一个浏览器漏洞可能涉及 JS 引擎、JIT、沙箱、内存布局；一个内核漏洞可能涉及驱动、并发、权限模型和硬件行为；一个智能合约漏洞又要理解链上状态和经济激励。

论文认为，Agentic AI 可以覆盖多个安全子领域，跨代码库和攻击技术建立联系，辅助漏洞发现、漏洞严重性评估、修复优先级和补丁管理。

这会直接改变漏洞挖掘的组织方式。传统模式依赖少数高水平研究员，Agent 模式则可能变成“人类专家定义任务和边界，Agent 批量探索代码路径，验证器筛选高价值候选”。

8. 漏洞利用生成

论文专门讨论了 exploit generation。它指出，从发现 crash 到生成可工作的 exploit，中间存在很大鸿沟。真实 exploit 需要理解目标软件、运行环境、防护机制和系统约束。

这里有一个关键观察：生成 exploit 很难，但验证一个候选 exploit 是否成功，通常相对便宜且明确。 Agent 可以围绕验证 oracle 反复迭代候选方案，这会让漏洞可利用性验证变得更自动化。

这也是这篇文章最需要加安全边界的地方。漏洞利用生成对防守方有价值，比如判断漏洞优先级、验证补丁有效性、评估真实风险；但同样具有明显双重用途。未来这类能力需要更严格的身份、场景、权限、审计和输出控制。

9. 迁移到内存安全语言

大量关键基础设施仍然由 C/C++ 编写，内存安全问题仍然是重要漏洞来源。迁移到 Rust 等内存安全语言，是一个方向明确但工程成本极高的问题。

论文提到，C/C++ 到 Rust 的迁移难在三点：大型代码库人工重写成本高；同时懂源语言和目标语言的专家少；每个代码库都有自己的惯用写法、构建系统和隐含不变量，现有自动翻译器还可能大量生成 unsafe Rust。

Agent 的潜在作用，是理解 C 代码中的别名、所有权、生命周期和不变量，生成更符合 Rust 语义的候选代码，再由专家审查。这会把内存安全迁移从“全人工重构项目”变成“Agent 生成 + 专家验证 + 分阶段替换”的工程流程。

10. 领域定制化代码优化

很多软件只使用通用库的一小部分功能，剩余代码会扩大攻击面。论文引用研究指出，在典型 Linux 桌面上，超过 2000 个程序平均只使用约 5% 的标准 C 库，其余部分并没有为应用提供必要价值，却增加了攻击面。

Agent 可以分析具体部署中实际使用的功能，生成精简构建，做 library debloating、protocol debloating、kernel feature reduction。这个方向和安全产品结合很紧：未来“最小化攻击面”可能从人工 hardening 文档，变成 CI/CD 里的自动化构建步骤。

11. 代码 IP 保护

代码混淆、代码变形、metamorphism 过去常见于软件保护和恶意软件对抗。难点在于，真正的语义保持变换需要理解程序整体逻辑，而不只是套几个固定混淆模板。

论文认为，Agent 可以同时理解程序语义、结构特征、统计特征和威胁模型，生成更复杂的代码变形方案。

这个方向同样有双重用途。用于正版软件保护、模型推理代码保护、关键算法保护时有价值；用于恶意载荷变形、绕过检测时风险很高。因此它不适合做无边界开放能力，更适合被纳入受控安全工具链。

03 威胁情报

Agent 适合做证据关联，不适合直接拍板

威胁情报和攻击归因的难点，不只是技术分析，还包括证据权重和不确定性管理。

12. 攻击归因与威胁情报

一次安全事件发生后，防守方需要回答三个问题：发生了什么、谁可能在背后、下一步可能做什么。

这需要结合技术证据和非技术证据。技术证据包括恶意软件相似性、基础设施重叠、代码复用；非技术证据包括 OSINT、泄露文档、语言文化线索、地缘政治背景等。论文指出，一份有支撑的归因报告通常需要数周分析，还要面对攻击者的 false flag 和工具复用。

Agent 的价值不是替人类给出最终归因，而是收集和关联多源证据，提出候选假设，标出证据薄弱和相互矛盾的位置。

换句话说，Agent 更适合作为证据分析员和假设管理器，而不是最终裁判。

13. 取证溯源分析

取证溯源要重建攻击路径：哪个进程最先被利用，哪些文件被访问，数据是否外传，影响范围有多大。

Provenance analysis 会把进程、文件、socket、用户等实体之间的因果关系记录成图。调查人员可以从告警点向后追根因，也可以向前看影响范围。论文认为，Agent 可以解释复杂 provenance graph，识别可能攻击路径，并给出支撑证据。

这对 SOC 很关键。很多组织已经采集了大量日志、EDR、NDR、云审计、身份访问记录，但真正缺的是把这些证据串成“攻击故事线”的能力。

04 攻击检测

真正的价值是降低告警噪声

检测系统最大的问题，常常不是没有告警，而是告警太多。

14. 内部威胁检测

内部威胁检测很难，因为攻击者可能拥有合法权限，行为也会伪装成正常操作。传统方案会建立用户行为模型，但每个组织角色、流程、业务节奏都不同，误报很容易淹没分析员。

论文认为，Agent 可以读取用户活动，建立用户和角色级正常行为模型，并解释为什么某个事件可疑。

这类能力如果落地，重点不是简单打一个风险分，而是解释异常背后的上下文。例如：这个员工是否有访问该数据的业务理由？这个操作是否发生在异常时间？是否和最近登录地点、终端指纹、审批链路冲突？是否与近期离职、外发、批量下载等行为组合出现？

15. 实时溯源监控

实时 provenance 监控可以把进程、文件、系统之间的交互放进连续图谱里，帮助发现攻击路径。但规模是最大难题。

论文提到，即便是中等规模组织，每周也可能产生数万条告警，底层事件流每天可达数亿条记录。Agent 的价值在于从海量事件流中找出真正需要关注的小部分子图，并解释为什么这些子图值得调查。

这对应下一代安全运营的核心方向：把告警压缩成可解释的攻击链，而不是继续增加告警数量。

16. 自适应蜜罐

传统蜜罐多是静态诱饵。攻击者一旦识别环境不真实，就会停止交互，甚至反向利用蜜罐误导防守方。

论文认为，Agent 可以生成更复杂的诱饵环境，模拟网络结构、通信行为和主机活动，并根据攻击者动作动态调整响应。多个 Agent 还可以主动探测攻击者使用的环境指纹识别机制。

这意味着蜜罐可能从“静态陷阱”升级成“可对话、可适配、可分析攻击者意图的交互式环境”。

这篇文章真正指向的产品形态

如果把论文里的 16 个方向放到一起看，会发现它们并不对应 16 个孤立工具，而是指向一个更大的产品形态：

Agentic Security System。

它至少需要 6 层能力。

第一层是任务编排层。把供应链分析、日志排查、漏洞验证、策略生成、补丁建议等任务拆成可执行步骤。

第二层是证据图谱层。把代码、依赖、SBOM、漏洞库、告警、日志、身份、终端、网络、威胁情报统一成可追溯证据链。

第三层是工具调用层。连接 SAST、DAST、fuzzer、SBOM scanner、EDR、SIEM、SOAR、sandbox、CI/CD、代码仓库等已有安全工具。

第四层是验证器层。对 Agent 输出做静态检查、动态验证、策略模拟、回归测试、补丁验证和误报复核。

第五层是权限治理层。明确 Agent 能读什么、能调用什么、能修改什么，哪些动作必须人工审批。

第六层是审计与回滚层。记录 Agent 的输入、工具调用、关键推理摘要、输出、修改内容、审批记录和回滚路径。

这也是企业落地安全 Agent 时最容易忽视的点：不能只看模型能力，更要看系统边界。

没有验证器，Agent 可能产生错误修复；没有权限治理，Agent 会变成高权限攻击入口；没有审计，出了问题无法追责；没有沙箱，自动化 exploit 验证和补丁测试会带来额外风险。

必须看到的风险：安全Agent自己也会成为攻击面

论文最后也提醒，Agent 不是万能方案。Agent 输出具有随机性，需要验证和检查；Agent 性能评估也很难，因为一旦 benchmark 变成优化目标，评测本身可能失效；更重要的是，Agent 会继承底层 AI 系统的漏洞，并因自治性和高权限访问进一步放大风险。

对安全场景来说，这一点尤其关键。

一个普通聊天机器人答错了，最多是信息质量问题；一个安全 Agent 答错了，可能错误封禁业务、错误放行攻击、错误修复系统、误判归因结论，甚至在工具调用中引入新风险。

因此，安全 Agent 的落地原则应该是：

低风险任务可以自动执行，高风险任务必须验证后执行，关键变更必须人类审批。

更具体一点：

能自动做的是信息收集、依赖识别、日志聚合、告警摘要、风险初筛、证据链整理。

需要验证后做的是补丁建议、策略生成、漏洞可利用性验证、攻击路径还原、行为异常判断。

必须人工审批的是生产系统修复、权限变更、隔离封禁、对外归因、删除数据、主动探测、可利用性 PoC 生成和运行。

安全 Agent 的能力越强，越不能裸奔。

写在最后

这篇论文的学术创新并不强，它更像一份研究议程和方向清单。但它抓住了一个关键变化：网络安全不只是缺工具，也缺可复制的专家能力。

很多安全方法没有普及，不是因为没有价值，而是因为太贵、太慢、太定制、太依赖专家。Agentic AI 让这些限制开始松动。

安全插桩可以自动建议，系统策略可以按部署环境生成，供应链风险可以持续分析，漏洞验证可以迭代执行，取证图谱可以自动解释，告警可以被压缩成攻击故事线。

这并不意味着 Agent 已经解决了 16 个安全难题。更准确的判断是：

Agent 正在把一批曾经只适合专家团队、高价值目标和研究原型的安全技术，重新拉回工程落地的讨论范围。

未来的安全产品，也许不会只是“检测一个风险”或“生成一份报告”，而是提供一套可审计、可验证、可控权的安全 Agent 工作流。

安全防守真正缺的，可能从来不是想法。

缺的是能把专家能力复制到每一个系统、每一个仓库、每一条告警、每一次变更里的工程机制。

Agentic AI 正在把这个机制推到台前。