从RSAC2026看安全运营技术发展趋势(3)：Agnetic SOC实战经验分享
原创 Benny Ye 2026-06-17 12:00 北京
实战化的Agentic SOC应坚持“人类主导、AI支撑”的核心原则，不仅要靠应用场景，还要考虑智能体安全与AI运行维护。
【引言】 今年以来，Agentic AI for SecOps比去年火爆十倍。尤其是OpenClaw以及Hermes等智能体系统在国内的出圈，人们（包括安全业界）对智能体助力安全产生了极高的期待。而事实上，根据笔者的观察，企业生产级的安全智能体系统寥寥，其应用普及还有很多障碍需要跨越。而前不久结束的RSAC2026大会上，安全厂商们纷纷展示了自己的安全智能体系统，虽然有的也很夸张且不实际，但也不乏接地气的产品和应用场景。会上还有不少企业现身说法，展示了大量贴近实战的Agentic SOC落地成果与踩坑经验。笔者认为，深入研究RSAC2026大会上有关智能体的内容，对于我们开发实战化的企业级安全智能体应用（譬如Agentic SOC）或有裨益。
为了更深入分析RSAC2026上的安全运营平台（主要是Agentic SOC），今年度的文章分为四部分，分别是：
从RSAC2026看安全运营技术发展趋势(3)：Agentic SOC实战经验分享
从RSAC2026看安全运营技术发展趋势(4)：综合观察与反思
本篇为第三篇。
本篇核心发现：当前，企业生产级 Agentic SOC 的落地范式，绝非追求极致自主化运营，而是以 “人类主导、AI 增效、可控自治” 为核心。业界真实实战共识是：AI 擅长认知辅助、流程减负、信息聚合、内容生成；生产级落地宜遵循只读优先、证据可追溯、人在回路、分级自治、全链路审计的原则，实施分阶段、可度量、带安全护栏的工程化建设。
用户视角下的Agentic SOC实战经验分享
看看Agentic SOC的使用者们是如何实战的。
Expel：一种分层的人机协作SOC运营框架
MDR公司Expel的CEO及联合创始人Dave Merkel在会上分享了一种层次的人机协作SOC运营框架，将AI、自动化和人工操作综合运用到检测与响应流程中，平衡好人、技术和流程之间的关系，改变现在安全运营的困境，但同时避免落入完全自主化的陷阱。
Dave Merkel首先引用了多个统计数字来表明现在安全运营面临的告警疲劳问题。比如，Forrester数据指出“一个SOC平均每天处理11000条告警”，然后引出他的分层人机协作SOC框架的核心目标：构建一套系统，让机器干其擅长的大规模数据处理，让人类专家专注于判断、上下文分析与反制攻击者。这个框架的核心思想是：人类主导、AI支撑，而不能是AI主导、人类支撑。
如上图，Dave Merkel对比了两种相反的应用AI的运营思路：AI主导、人类支撑的运营闭环和人类主导、AI支撑的运营闭环。他表示，在AI主导、人类支撑的闭环模式下，由于目前AI还不成熟，AI输出尚无法脱离人类的监督、检查、确认，而AI的过程越长，就越不可控。如果以AI为主，人根本没有精力去对每个重要结果进行审核，但只要出一次事故，都是人类担责（AI不会担责），因此这个模式对人类分析师很不友好。正确的模式是人类主导、AI支撑的闭环，在以人为主的流程中逐步加入AI，逐步用AI替换人类操作的环节，而且一旦出现问题，可以迅速回退。
Dave Merkel的观点是：反对一上来就用AI彻底取代现有的安全运营流程，而主张循序渐进的方式。
Dave Merkel认为，传统的以手工为主的或者半自动化的运营方式肯定难以为继，但指望完全自主的SOC也不切实际。正确的运营方式应该是先搭建一个基础平台，配置一个自动化和自主化的框架，然后逐步提升运营的自动化和自主化程度，并持续的度量与改进。
这个人机协作SOC框架的三个核心原则是：
1）结果导向原则：确保每个AI和自动化能力必须解决实际问题，而非追逐技术噱头。要明确运营流程中的关键成功指标，建立可度量的指标体系，持续评估AI和自动化的效果。
2）人机协同原则（Design for the human moment）：确保人类对AI的始终掌控。保留人工验证环节，确保关键决策可被审查，为无法完全自动化的环节设计人机交互接口。
3）信任透明原则：确保AI的工作过程是可信任的，不能信任黑盒系统。AI工作过程应全程透明、可追溯（什么时候、做了什么操作、产生什么结果），AI行为可解释、可审计。
接下来，Dave Merkel给出了一个威胁事件运营的闭环管道，分为7个环节：采集与摄取、解析、上下文富化、检测与关联、分诊、调查与处置、沟通与报告。针对每个环节，列举了可以应用的AI和自动化技术。但需要注意，不要刻意追求将各个环节的AI和自动化完全串起来，更需要关注的是解决具体问题。
可以看到，自动化比AI更有用。
聚焦AI，威胁事件运营闭环在日志富化、告警分诊、事件调查与处置，以及沟通与报告环节引入了AI能力。
1）日志富化：可以借助AI进行告警（其实是事态/Event）的流行度分析，评估事态的频度和分布模式。
2）告警分诊：这是公认的AI大有可为的地方，譬如演讲中提到的相似告警查找，以及跨产品间工具（API）调用，或者少量样本下的告警分类和告警研判（真假判定）。
3）事件调查与处置：这也是AI大显身手的地方，譬如调查过程和结果摘要描述，基于各种上下文的事件调查。但在处置这块，需要慎重。
4）沟通与报告：生成报告、结案陈词、生成处置建议（并调用剧本执行）、推送到工单或者作战室、状态同步等等都是AI可以自主进行的。
必须谨记，以上所有AI能力都必须保证过程的透明性和可解释性，并需要确保人类可以在必要时及时介入（design for human moment）。此外，AI能力还要做到可度量，从而能够持续改进，形成良性的运营节奏。
【注1：正如Gatner指出的那样，在安全运营中，自动化不等于AI。在笔者从Gartner2024年北美安全峰会看安全运营的技术趋势一文中的“超大规模安全运营”章节中，有一幅类似的区分不同角色下的AI与自动化搭配使用的建议。】
【注2：正如本系列文章第二篇中指出的，安全运营需要混合使用AI和自动化能力。】
借助上述AI+自动化能力嵌入到威胁事件运营闭环各个环节之中，安全运营团队可以获得的收益巨大。
Dave Merkel表示，借助自动化和AI技术，2016-2024年Expel客户量翻三倍但零新增分析师。
演讲环节以及后面的听众问答环节，Dave Merkel分享了在应用这个人机协作SOC框架时的一些关键经验。
1）如何将AI和自动化应用到运营的不同环节？
答：需要建立详细的技术部署地图。在供应商选型的时候，要求他们展示具体事实证据，比如：模型的运行原理、结果生成的可追溯性、故障处理机制，等。
2）能否提供完整的证据链与决策依据？
答：所有检测结果应附带完整证据链，包括使用了什么模型、决策逻辑、调查全过程记录、审计日志等。Dave Merkel表示，“看不见证据就等于没发生”。
3）分析师的专业能力如何沉淀与发展？
答：分析师的工作要逐渐从告警处理转向更高价值的工作，比如：主动安全评估、GRC、SOC运营管理能力建设。对分析师而言，通过AI和自动化节省的时间可以转化为专业技能的深化。最后，即便采用AI，仍要关注人，核心专家的经验依然是关键资产。
4）如何量化告警噪音的实际降低效果？
答：譬如告警转事件率、误报率年度对比。注意，需要持续收集安全信号质量指标，证明防御体系的实际改进。
5）完整事件生命周期的平均响应时间（MTTR）是多少？
答：要精准定义本单位的MTTR所涵盖的闭环环节。要建立MTTR的KPI，譬如MTTR的年降幅。注意，需建立详细的响应时间基线，区分正常/异常情况下的处理效能。
6）整个框架和AI模型如何自我持续改进？
答：建议设立专注AI创新的团队，持续观察SOC需求，开发/引进的新AI组件必须经过指标验证才能进入beta测试。建立可观测性机制，通过收据发现真实问题。逐步将人工环节替换为AI模型。
7）如何衡量效率提升，如何计算成本？
答：要建立 行动速度、准确性、完整性等可量化参数。要将Token成本作为SOC成本的一部分，可建立预测模型，结合历史数据、用户/业务增长率和攻击活动增长率预测Token支出。要对比Token成本支出增长与人工时间节省，评估规模化扩展的可行性。总之，要明确每个AI组件的产出贡献，要持续检测Token的成本变化趋势。
【笔者注：对于使用付费的云上LLM，计算Token成本比较直接。对于使用本地部署的LLM，则需要转换为的算力成本。】
8）AI生成内容的漂移问题如何控制？
答：可以采用分级风险管控机制。对于关键的内容，譬如事件分类，必须经过人工验证才允许输出；而对于非关键的内容生成，如告警关闭，可以采用简单的自动化校验机制，譬如用统计学方法去识别漂移。总之，整个系统要保持“人类主导”的设计原则，具体选择什么验证方式要根据AI任务的复杂度而定。
9）如何有效评估AI输出的内容？
答：关键是要建立一个适用的标准化评估框架。而除了传统的思路，还可以考虑用多AI模型交叉验证的方式。还需要注意的是，基础模型的进步可能会导致之前的某些优化技术（譬如某些提示词）过时。
最后，Dave Merkel指出，分层的人机协作SOC框架力求达到的“技术+AI与自动化+人类智慧”的应用效果是：
1）在不牺牲准确性的前提下提升速度；
2）实现透明的同时不妥协安全性；
3）持续改进但不导致成本失控。
他表示，最先进的技术，应赋能最宝贵的资源——人；最佳安全防护，来自用正确的技术支撑聪明人做最擅长的事。
Exeter金融公司和泰森食品公司：将AI放进SOC的经验教训
来自这两个企业的主任安全工程师联合进行了一个分享，介绍他们将AI能力嵌入各自SOC过程中获得的经验与教训。
来自Exeter的安全专家Ankit Gupta首先介绍了她公司的现有SOC运营过程：各种遥测数据送入SIEM，产生的告警/事件送入他们的工单系统进行分析后，调用SOAR进行处置。
她的安全团队面临的痛点是：
分析师需要在5–7个工具间反复切换找上下文
（人工）分诊记录不一致、难以审计
大量告警导致疲劳、漏看
知识只存在于人脑，没有沉淀到工单
她承担，安全团队是迫于压力必须使用AI。她做了大量调研，为了避免AI失控，设计了以下强制约束条件（设计原则）：
默认只读：所有操作默认只读，需人工批准高风险动作
审计追踪：必须保留完整的提示检索和输出预期记录
性能要求：不能增加分析师工作步骤或降低响应速度（否则采用率会崩溃）
证据支撑：每个结论必须有提示、上下文或证据支持
成本控制：严格限制数据预算和延迟时间
她精心制定了一个将AI引入SOC平台的方案，该方案具有以下特点：
AI角色定位：将LLM视为擅长起草和总结的初级分析师，而非独立调查员；
AI价值目标：主要价值在于减少调查过程中的摩擦，而非替代人工判断
AI功能聚焦：专注于证据关联、假设起草和认知负荷降低；
AI嵌入方案：在SIEM和工单系统之间，以及SIEM和SOAR/IR系统之间通过AI建立桥梁；
效果度量：对AI的效果进行指标化度量；
风险控制：当模型猜测或不受约束行动时非常危险，因此要采用强监控手段；
防护机制：构筑提示注入防御和恶意行为检测的安全框架。
AI/LLM嵌入的方案如下图所示：从SIEM/EDR产生的告警送入数据湖中进行上下文富化，然后通过LLM实现自主化告警分诊，生成事件并附带详细的上下文信息，再送入工单系统进行案例管理，最后由人对案例进行调查和处置。
系统遵照最初的设计原则，采用了强有力的风险控制机制：
AI操作默认只读，如果需要进行写/修改都需要经过人类批准，操作人员本身基于RBAC进行权限控制；
证据优先，分析调查中的每个结论都必须链接到真实的痕迹/实体ID（即论据要真实）；
结果输出严格采用JSON格式，便于后续使用，并且每次结论要给出置信度评分；
AI调用的工具采用白名单机制，并且要有策略检查机制；
采用全链路审计，从提示词、上下文、模型到工具版本都要进行审计。
Exeter的安全专家分享了一个典型场景：对Outlook发起的可疑Powershell进程的告警进行研判的过程。
1）LLM处理过程：
EDR提供进程树、登录异常等原始数据
LLM生成结构化事件摘要（非聊天输出）
2）输出结果包含三个核心要素：
事件描述（what happened）
证据引用（artifact ID）
后续建议（what to check next）
3）安全机制：当发现攻击者有横向移动时，可以通过预授权机制对主机进行隔离，但此时可以调用的工具需要走白名单列表核对。当然，所有调查和处置的过程都要记录审计日志。
她还建立了一套对量AI运营过程和效果的指标体系，以下是关键的面向领导层的四个关键成功指标：MTTD、MTTR、误报率、分析师情绪（分析师使用率）。
【笔者注：每个单位对MTTD/MTTR的定义可以不同，但在一个单位内要保持统一】
MTTD：从告警产生到这个告警被分诊并升级到案例（事件）的时长。这个指标可以展示AI接入告警分诊后的效果。
MTTR（平均响应时长）：从一个案例被确认到这个案例中的事件被遏制/止血的时长。
MTTR'（平均解决时长）：从一个案例被确认到这个案例被关闭的时长。
案例（事件）误报率：告警分诊并升级到案例的事件中，状态为关闭的，且关闭原因为良性的（也就是误报）的比率。譬如，一周有100条案例被关闭，其中有30个的关闭原因是“该事件为良性”或者“该事件为误报”，那么这周案例的误报率就是30%，表明有30条告警其实应该在分诊时就关闭的，不应升级为案例（事件）。这个误报率越高，表明分诊效果越差。
分析师情绪反馈：询问分析是否信任并使用某个AI功能。这是一个主观评分，由分析师回答。这个指标很有意思，好的AI一定是跟分析师配合的很好的，否则会形成新的摩擦。
Exeter的安全专家分享了他们的一个真实的指标结果。
可以看到，MTTD下降了36%，MTTR下降了22%，误报率下降了16%，而分析师满意度也从3.0上升到了4.2。
Exeter的安全专家表示，这些成效的取得，关键原因在于：更快的证据拼接、统一的记录、减少工具切换，而不是靠自主执行动作。
接着，Exeter的安全专家总结了她们发现的实际有效的AI赋能SOC的应用场景：
告警升级到案例（事件）后的自动总结摘要生成；
多源的证据自动拼接；
沟通汇报材料的初稿生成；
查询和剧本的初稿生成；
分析师新手快速入门指导。
她还提及了其团队发现的两个规律：
让模型做总结、撰写、关联证据——让分析师变快
让模型做决策、执行——必出事故
她表示，AI的核心价值不是替代专业知识，而是消除摩擦，使工作流程更具可重复性。
到此为止，Agentic SOC实战似乎顺风顺水。但实际上，在运行过程中遇到了很多坑，包括AI能力失效问题，分析师体验问题，等等。而且，生产环境要真正把Agentic SOC跑起来，还有很多工程化的问题需要考虑，包括AI护栏（AI Safety）、AI安全防护（AI Security）、系统自身的运行维护，等等。
【笔者注：要实战化Agentic SOC，还需要付出很多AI自身产生的成本，并且可能这个成本很高，这是一个扎心的事实。】
演讲的第二部分，由另一位来自泰森食品公司的首席安全工程师Shilpi Mittal就上述冰山之下的问题进行了分享。
首先，是AI在生产环境中遇到的失效问题及其修复对策。
最先失效的问题 | 我们的修复方案 |
上下文混乱：字段缺失、主机/用户ID不统一 | 先标准化和富化再喂给LLM；绝不允许猜测缺失信息 |
极端场景幻觉自信（长尾告警尤其严重） | 强制引用来源 + 置信度门槛 + “我不知道”模式 |
通过工单、日志、粘贴内容进行提示注入 | 把外部文本全部视为不可信；指令与数据隔离 |
流量高峰延迟与限流（如作战室模式中） | 异步、缓存、优雅降级、紧急停止开关 |
工具执行风险：一个错误动作就会引发新事件 | 默认只读；工具必须显式审批才可使用 |
其次，是要优化分析师体验。
分析师使用障碍主要表现在：
额外步骤厌恶：增加点击次数或缺少引用时会被弃用
模糊置信度：分析师需要确切证据而非可疑的AI自信
要让Agentic SOC好用，不仅要强大的AI，还需要丝滑的用户体验：工作流程必须符合工程师的习惯，否则最先进的模型也会失败。
界面改进要点：
UX优化：明确区分已知/未知信息及下一步检查项
协作模式：避免评判性语气，改为"这是我所见，这是相关证据"
反馈机制：可以添加“有用/无用”快速反馈循环持续优化提示和检索。
第三，是Agentic SOC的安全护栏。
输入净化：给LLM的输入数据要标准化；
用RAG的时候，检索出来的信息要标记来源；
提示词要做版本控制；
输出约束：结构化输出，论点要有论据支撑，论据要引用来源，未经验证的内容禁止输出；
确保人在回路之中（HITL），统一人机协作接口；
持续评估安全护栏效果，持续改进。
他给出了四条强制执行的安全护栏原则：
无引用 → 不相信
无人控 → 不执行
无评估 → 不发布
无审计 → 不上线
第四，是Agentic SOC的AI自身安全防护。
泰森食品公司的安全专家表示，LLM无法可靠的区分指令与数据，因此，要重点防范可能混在数据中的指令注入。对于LLM要读取的数据，譬如工单、日志、粘贴的信息等等都要视为不可信数据，要进行必要的安全防护。接着，他针对OWASP LLM 十大风险提出了他们的应对方案，包括：
检索内容视为不可信
系统策略与内容分离
工具约束（白名单+审批）
日志记录 + 提示词注入检测
抬高数据泄露成本
与此同时，要建立用于测试系统有效性的基准测试用例集；要对Agentic SOC建立可观测，对数据引用覆盖率、事实准确率、安全策略匹配度、响应延迟等进行评估与验证；要对AI工程进行版本管理和变更控制，包括提示词版本管理等等，每次变更都要经过基准测试，通过后才能发布；要进行攻防演练与渗透测试，重点关注提示注入攻击、数据渗出、不安全工具请求、越狱尝试等，定期评估AI安全状况；要记录各种日志，用于观测和安全审计。
第五，是关于Agentic SOC系统的自身运行维护。他表示，“要像运行生产系统一样去运行这个Agentic SOC系统”。【注：虽然你的目的只是要用Agentic SOC，但是需要在维护好Agentic SOC自身运行方面投入巨大资源。】
这里对Agentic SOC系统的运行维护体现在三方面：
可靠性维护：低延迟意味着更多算力和预算，优雅降级必须考虑（应对LLM的可用性和性能问题），要设置AI终止开关，要考虑回退到无AI下的分析师操作体验。
成本控制：LLM缓存机制可以节约成本，要考虑Token的限制（长度、成本等），可以设计批量提交、异步摘要等机制。
变更管理：提示词/模型的版本管理、回归评估、分析师反馈闭环。
第六，泰森食品公司的安全专家给出了一个分阶段落地Agentic SOC的路线图。
准备阶段：准备好基线数据，就是当下的分诊时长、返工率，扽等各种指标。
第一阶段：让AI工作在只读模式下，就是你给他提供高质量的数据，让它产生你严格要求的信息输出，不要执行任何操作。
第二阶段：让AI在受控的情况下进行操作。受控包括：工具白名单、操作前人工审批等。
第三阶段：上规模、强治理。持续对系统进行评估、测试、审计、优化。
专家表示，只有在获得分析师信任、可衡量时间节省、行为稳定、安全通过后，才进入下一阶段。
最后，泰森食品公司的安全专家进行了演讲总结。一句话总结：让模型证明它的结论，让人类掌握最终决策权。
核心要点包括：
LLM 擅长撰写、总结，不擅长决策、执行
引用来源是获得分析师信任与可审计性的最快路径
提示词注入是SOC真实威胁，因为你的数据由攻击者控制
把AI工具当作生产系统去运营：评估、版本、回滚
从只读开始，衡量价值，然后带护栏逐步提高自治度
演讲结束后的问答环节，也有不少值得回味的信息。
1）工具选择问题
泰森食品公司答：曾评估过3个外部工具（包括Splunk和Sentinel等），但准确率仅50-60%，且不符合他们公司的合规要求。因此，他们采用的自研的模式，在内部部署LLM。
2）团队规模和开发周期问题
泰森食品公司答：核心团队5人，专职开发人员负责系统构建。此外还有支持团队。初始版本开发耗时6个月，目前仍在持续改进中。
3）分析师的体验和反馈
泰森食品公司答：产品刚发布时，分析师期望"魔法效果"，实际需要人机协作，有落差，要尽快达成共识：AI不能取代人类智能。
Exeter公司答：在测试阶段，分析师还是比较喜欢这个系统的。到了生产阶段，由于AI幻觉等各种问题，分析师感受到了运营压力，需要不断优化减少AI误判。
4）某个场景AI跑成熟之后，会在这个场景上取代人类吗？
泰森食品公司答：Agentic SOC设计目标不是取代人，是增强人。而且系统设计时人在场景中起到关键作用，因为系统决策权留给了分析师，AI只是做辅助决策。不过，随着AI对抗强度提升，响应速度需要提升，有些场景可能不能处处让人去决策。
5）运行方式问题
Exeter公司答：聊天模式 + 工作流模式，各50%，但其实聊天模式不常用。团队是7*24运行。
金佰利：AI在SOC中的实战应用
金佰利公司的网络安全检测与自动化工程负责人Ashwin Rajendra主导公司的SOAR平台与AI驱动工作流设计，负责优化全球安全运营。他在Splunk发起的一个演讲中分享了其公司的Agentic SOC实战应用经验。
首先，Ashwin Rajendra介绍了他们公司的安全自动化全景图。
整个系统核心是PAN的SOAR，数据底座则是Splunk的ES提供。首先，这个SOAR通过多种方式集成了公司的各种安全基础设施（50到60款），收集他们的告警信息，其中有一部分是借助Splunk ES处理后转发过来的。其次，这个SOAR通过多种方式集成了大量的威胁情报，并基于这些情报实现各种数据富化（IP富化、哈希富化、URL富化、域名富化）。第三，SOAR跟Anomali系统进行对接实施IOC阻断。第四，SOAR跟ServiceNow对接派发工单，由ServiceNow进行工单处置。
在数据底座方面，他们采用了Splunk自带的数据管道，并采用低成本的数据湖进行长期的数据存储。同时，系统并非用Splunk ES集中存储所有安全数据，还有一些数据通过联邦数据检索的方式分布存储、虚拟集中、按需读取——这也就是数据编织。
该系统的一个核心流程是收集多源威胁情报，系统对多源情报数据进行算法评分，得出威胁情报的综合评分。融合后的情报能够与收集到的告警信息进行比对，用于威胁检测、调查和修复决策。
图中没有描绘AI模块，但Ashwin Rajendra表示，威胁检测、调查和修复三个环节都应用了多智能体，并形成了决策树结构。针对不同的任务，AI的工作流程自主化分为三个层级：
人在环中(Human in the loop)：高风险决策需人工确认
人在环上(Human on the loop)：AI执行+人工监督
全自动(Human out of loop)：低风险标准化操作
从实战上看，80%的任务是自动执行的。
在LLM方面，在本地部署了LLM，配备了50GPU的算力，同时也通过开放接口使用云端商业LLM（如OpenAI、Claude）。不同的LLM用于不同的应用场景。其中涉及敏感信息的处理，用本地LLM。
接着，金佰利的这位项目负责人分享了AI应用落地的关键点：建立对AI的信任。信任源于监管和透明，而非取代人类的判断。
Ashwin Rajendra将信任分解为三个部分：
1）定义清晰的角色，对应系统的三大功能组成（检测与分析、响应与修复、合规与策略）。
2）可解析性，包括透明的决策逻辑、可审计可追责、人类可理解。
3）持续验证，包括建立可靠的基准、具备人类控制的护栏、持续测试。
最后，Ashwin Rajendra提供了一个SOC中实施AI应用的路线图。整体上，建议采用小处着手、深度集成、可信扩展的方式。
在基础建设阶段，主要是建立统一的遥测，并统一数据模型；将多个系统的工作流程进行连接整合；建立治理框架，明确审批机制、审计机制。
在初次引入AI的时候，从减少分析师摩擦的场景入手（跟前面Exeter和泰森食品的建议相同）。譬如：告警分诊和富化、事件调查与摘要、响应指导与操作推荐、跨工具的上下文收集。同时，要对LLM不断进行调优，譬如温度参数控制，RAG技术优化等，要反复测试与验证。
AI应用价值被证明并建立起信任后，开始进行扩展，朝着真正的Agentic SOC前进，AI的作用逐步从助理变成半自动执行体，最后变成自主执行体。整个扩展的过程要由安全护栏保障，要持续进行度量（譬如节省了多少分析时长、MTTR、调查质量等），以证明其价值。
小结
综合Expel、Exeter、泰森食品、金佰利等安全运营服务商与多家商业化实体行业企业的RSAC2026实战分享可以看出，当前Agentic SOC正在走出概念炒作阶段，逐步形成了一套可复用、可落地、可度量的企业级实战方法论。
当前，真实生产环境的AI安全运营，核心是解决运营摩擦、提升分析师效率、降低告警噪音、标准化运营流程，而非替代人工、放开自主权限。
各家实战落地呈现高度统一的共性规律：
第一，人机协作范式高度收敛。所有成熟落地案例均坚持“人类主导、AI支撑”的核心原则，摒弃AI主导的运营模式。AI仅负责数据富化、证据拼接、告警摘要、报告生成、知识库辅助等低风险、高重复性的认知工作，核心研判、风险决策、高危处置始终由人类掌控。
第二，AI落地边界清晰可管。企业实战验证：大模型在总结、关联、文案生成场景稳定可靠，但在自主决策、自动化处置、复杂场景推理中极易产生幻觉与偏差。因此生产级落地普遍采用“默认只读、人工审批、工具白名单、证据强制溯源”的安全护栏体系，从机制上杜绝智能体失控风险。
第三，可度量、可观测、可迭代是规模化前提。成熟落地均建立了完整指标体系，通过MTTD、MTTR、误报率、分析师体验、AI准确率、Token成本等量化指标持续迭代优化，杜绝AI技术噱头化、效果不可见的问题。
第四，Agentic SOC是工程化体系，而非单纯模型能力。实战落地的最大痛点不在于大模型能力不足，而在于AI漂移、提示注入、上下文污染、算力成本、延迟限流、版本管理、运维可靠性等工程化、安全治理问题。企业必须将Agentic SOC当作核心生产系统运维，建立输入净化、输出约束、攻防测试、版本管控、优雅降级的全流程保障机制。
第五，落地路径呈现标准化阶段特征。行业统一最佳实践为：先只读辅助、再受控操作、最后适度自治，无信任不扩权、无度量不升级、无审计不上线，循序渐进提升自动化与智能化水平。
总之，本次RSAC大会上从用户侧分享的这些Agentic SOC实战经验，是我们不可多得的实战材料，值得好好研究。
【参考资料】
从RSAC2026看安全运营技术发展趋势(1)：Agentic AI重塑安全