凌晨两点，AI SOC该替你做到哪一步？

原创

雾芯
雾芯

雾帜智能

2026年10月10日 10:41
上海

在小说阅读器读本章

去阅读

在公众号小说中沉浸阅读

凌晨两点的值班场景

设想一个值班场景。

凌晨两点，手机响了：某账号连续登录失败后，出现了一次成功登录。你打开电脑，眼前只有一条告警。

这个账号是谁在用？成功登录来自哪里？登录后做了什么？如果现在禁用它，会不会影响正在运行的业务？

这些问题不查清，谁也不敢轻易点下“处置”。如果AI只是写好一段分析，再补一句“建议进一步排查”，剩下的夜班还是你的。

我们希望，AI交到你手里的是一项已经向前推进的调查。

这也是今天雾帜智能做AI SOC，最关注的事。

先把下一步查起来

在我们的AI SOC中，事件可以从已有安全系统进入后台，触发研判。AI在授权范围内查询账号、资产、日志与情报，拿到返回结果，再决定下一步。不必每查一项，都等人重新敲一句提示词。

沿着刚才的假设场景，查到成功登录，并不能直接认定账号失陷。还要核对设备、会话和后续访问。如果记录显示这是一次授权测试，就继续确认测试范围；如果发现异常访问，就沿着新线索查下去。

为此，我们把事实、关联和决策分开组织：日志记录了什么，几条线索为什么有关，处置建议依据什么。结论要能找到证据，缺失的日志也要明明白白留在调查里。

同时，研判被拆成轮次、任务和步骤。能并行的查询一起做，依赖前一项结果的动作先等一等。新证据可以改变方向，工具失败也要影响后续安排。

值班人员需要看到：查到了哪一步，卡在哪里，还有什么没查清。

AI得知道自己在哪家企业上班

同样一条异常登录，涉及测试账号和核心业务账号，分量完全不同。

所以，AI需要的不只是通用安全知识，还有这家企业的资产背景、处置规程、历史事件，以及眼下真正可用的工具。我们的产品通过知识检索补充这些背景，通过受控的工具接入连接日志平台、终端、边界设备等已有系统。

比如，账号属于一个夜间批处理任务，贸然禁用可能打断业务；某个来源地址挂着“可疑”标签，也还需要结合本地访问记录判断。企业上下文，决定了通用建议能不能变成可执行的下一步。

工具也有现实边界：接口有没有权限，返回是否正常，目标是否在管理范围内，都要纳入工作过程。查不到，就把缺口交代清楚，转给人补充。

“没有查到”和“没有发生”，是两回事。

需要人决定时，把依据一起交过来

接着设想：更多证据指向账号被盗，下一步可能涉及禁用账号。

这时，一个“是否同意”的按钮还不够。接手的人需要知道异常发生在哪里、证据来自哪些记录、账号承载什么业务，以及候选动作各有什么影响。如果考虑先限制可疑会话，也要说明这个选择能控制什么风险、还留下什么问题。

在我们的企业方案里，封禁、隔离、账号禁用等处置默认进入人工审批；低风险动作，则在试点验证、明确授权后逐步放开。

安全负责人定边界，分析员复核关键判断，业务方确认影响。AI持续补证、整理进展，把需要人作决定的部分连同依据交过来。

凌晨两点被叫醒已经够辛苦了，至少别让接手的人再从第一条日志读起。

执行之后，还得回头看

得到批准、调用工具、返回成功，事情还没结束。

策略是否生效？可疑活动是否继续？业务有没有受到影响？这些检查，需要继续进入调查。某个步骤“完成”，不能让尚未解决的问题从视野里消失。

我们把工具返回、任务进展和人工决定留在同一项事件里，让后续研判用得上，也让接班的人看得懂。复盘时，反复缺失的资产背景、始终取不到的日志、经常需要人工补位的步骤，才有机会成为下一次改进的起点。

从2024年的AI虚拟SOC团队，到2025年的DeepSOC开源与DeepSOCX企业化，我们一直在把这件事往前做。如今，雾帜智能的AI SOC已得到部分银行、轨道交通、金融科技和能源客户的认可。

回到凌晨两点。我们期待你打开工作台时，能看见已经核对的证据、仍待回答的问题，以及需要你决定的下一步。

让人接手时，工作已经往前走了。 这是我们衡量AI SOC价值的一把尺子。