AiSOC（beenuar/AiSOC）：把本地大模型请进安全运营中心，每个结论都带可审计的账本

一、导读

安全运营中心（SOC）是当代企业里「告警比人多」最严重的地方：EDR、云审计、身份系统每天产出海量告警，分析师疲于奔命。AiSOC 把大模型请进了这条流水线——但它给 LLM 立的规矩比绝大多数智能体项目都严：模型分诊的每一条提示词、每一次工具调用、每一个引用，全部写入可审计的 Investigation Ledger；没有人工批准，任何响应动作都碰不到厂商 API。这个由安全公司 Cyble 全额资助、以 MIT 协议开源的项目，昨天（11 月 1 日）刚发布 v21.0.0「eval-honesty major」，单日涨星 436，成为当日榜单上大模型相关项目中的第一名。本文拆解它的架构原理，看看「用小模型做分诊、用硬闸门管住智能体」这条路走通了没有。

二、项目速览

项目	AiSOC（beenuar/AiSOC）
定位	开源可自托管的 AI 安全运营中心（AI SOC）
当日涨星	436（GitHub Trending 日榜，2026-11-02）
总星数	5,976（截至 2026-11-02）
协议	MIT
主语言	Python（约 29.7 MB），另有 TypeScript、Go
最新版本	v21.0.0（2026-11-01 发布）
部署形态	Docker Compose，core 16 容器约 8 GB 内存，full 22 容器约 12 GB
内置模型	Ollama 跑 llama3.2:3b-instruct-q4_K_M（约 2 GB，CPU 可推理）
资助方	Cyble（cyble.com），无闭源模块、无遥测回传
核心接口	REST 518 个操作 / 417 条路径；MCP server 31 个工具

三、为什么是它

AiSOC 冲上涨星榜不是偶然，三条线在这个时间点交汇了。

第一，AI SOC 本身是安全行业当下最热的赛道。商业侧 Dropzone AI、Prophet Security 等一批「AI 告警分诊」创业公司接连融资，行业共识正在形成：LLM 最先在安全运营里落地的形态，不是替分析师写报告，而是替分析师做告警初筛。但商业产品全是黑盒——模型看了什么、凭什么下结论、误报了怎么办，客户无从知晓。AiSOC 把这件事开源化，并且把「可审计」做成了第一性的架构约束，恰好踩中了黑盒模式的软肋。

第二，v21.0.0 是一个罕见的「评估诚实」大版本，就在发榜前一天（11 月 1 日）发布。这次升级没有加新功能，而是重构了自己数字的发布方式：每张评测记分卡必须标注实际服务的模型（网关证实或自报，带 provenance 状态）；召回率的分母必须把弃权和运行失败都算进去；告警削减率同时公布三个口径（75.3%、33.3%、24.5%），并把最刺眼的那个放在 README 里；任何没测过的指标显示「not measured」而不是 0。这种把难看的数字主动钉在门面上的做法，在开源项目里相当少见，也让它在讲究「可验证声明」的安全圈里赢得了口碑。

第三，它的工程纪律经得起安全从业者的审视：README 里的每一个数字都由 CI 脚本（make stats）从源码树重新清点，不一致就挂构建；每条标记 Stable 的能力背后都有一个「负面对照」测试——把被测的东西故意弄坏、要求检查变红，才算证明有效。对一个做安全的开源项目来说，这种纪律本身就是传播点。

四、架构原理

AiSOC 端到端架构手绘图：接入层（87 种连接器与 Ingest API）、处理层（OCSF 规范化、Kafka 事件脊柱、2530 条检测规则）、智能层（LLM 分诊、本地模型、调查账本）到响应层（playbook 与人工审批闸门）的四层架构

4.1 一条告警的完整旅程：11 步流水线

AiSOC 的官方架构文档用一个事件走完全程的方式描述系统，全链路 11 步，每一步都对应仓库里的真实代码。整体拓扑如下：

flowchart LR
    subgraph SL["接入层"]
        conn["services/connectors<br/>87 种连接器 + 4 类采集器"]
        push["Ingest API<br/>/v1/ingest/batch"]
    end
    subgraph PL["处理层"]
        ing["services/ingest（Go）<br/>OCSF 规范化 + 活动投影"]
        kafka[("Kafka 事件脊柱<br/>aisoc.raw_events")]
        fus["services/fusion（Python）<br/>2530 可执行规则 + 76 窗口规则"]
        pg[("PostgreSQL<br/>告警/事件/账本")]
    end
    subgraph IL["智能层"]
        agt["services/agents<br/>LLM 分诊与调查"]
        gw["LiteLLM 网关<br/>aisoc-角色别名"]
        oll["Ollama<br/>llama3.2:3b 本地模型"]
        ledger[("Investigation Ledger<br/>提示词/调用/引用/结论")]
    end
    subgraph RL["响应层"]
        api["services/api"]
        act["services/actions<br/>25 种 playbook 步骤"]
        human["SOC 分析师"]
    end
    conn --> ing
    push --> ing
    ing --> kafka --> fus
    fus --> pg
    agt --> gw --> oll
    agt --> ledger
    pg --> agt
    agt --> api --> act
    act -. "待审批动作" .-> human
    human -->|"批准/驳回"| act
    act --> vend["厂商 API<br/>EDR/云/身份"]

接入与规范化（第 1–2 步）。 遥测有两个入口：连接器按计划轮询厂商 API，或外部工具直接推送 ingest HTTP API。一个关键安全设计是「租户来自凭据，从不来自请求头」——即使客户端伪造 X-Tenant-ID，也会与凭据授权范围取交集，越界即拒绝。四个专用采集器读取云环境的真实出口（CloudTrail 组织轨迹经 S3 通知到 SQS、GCP Pub/Sub 订阅、Azure Event Hubs 捕获、syslog/CEF 监听），每个都带可续游标和每次轮询的有界预算，积压时施加背压而不是把内存打爆。ingest 服务用 Go 编写，把厂商载荷映射成 OCSF 形状的统一信封，并给每个事件盖上「活动投影」：行动者、动作、资源、位置、结果五元组，其中 actor.kind 有七种取值（human、service_account、workload、api_token、oauth_app、ai_agent、unknown），27 个连接器场景下都从厂商文档化的字段推导、绝不从用户名形状猜——一个长得像人名的服务账号，正是让身份规则要么噪声大要么致盲的误读源头。

检测与关联（第 3–6 步）。 Kafka 主题 aisoc.raw_events 是事件脊柱，让下游一切消费者互不感知。fusion 服务评估 2,530 条可执行规则（765 条原生 + 1,770 条 Sigma 导入），外加 76 条滑动窗口规则（73 条按阈值计数、3 条按有序序列匹配）；同时判断事件是否「可晋升」——厂商发现类（OCSF 类目 2）或严重度不低于 high 的事件才成为告警，例行遥测只进事件湖。匹配结果再过租户自己的 tuning overlay：你在控制台关掉的规则是真停了，抑制动作连同作者和理由一起记录。新告警按「租户:实体:战术」关联键归并进未关闭事件，十条相关告警由此变成分析师眼前的一件事。

AI 分诊与调查（第 7–8 步）。 告警写入 Postgres 并发布到 aisoc.alerts.fused，两个消费者接力：realtime 服务经 WebSocket 推给控制台；agents 服务调用 LLM 做自动分诊，产出结论、置信度和建议动作。模型默认是 Ollama 里固定版本的 llama3.2:3b-instruct-q4_K_M（约 2 GB，纯 CPU 可推理），经 LiteLLM 网关按 aisoc-角色别名路由——这意味着 core 档部署不需要任何云凭据就能产出真实的分诊结论和真实的 token 计数。项目对模型能力的标注非常克制：50 条告警实测中，这个 3B 模型在输出被约束为 JSON 之前有 44 次可用、之后 50 次可用（scripts/measure_triage_reliability.py 给出方法），README 直说「它不是前沿模型」。

治理响应（第 9–11 步）。 playbook 可以由告警触发，但三个开关（部署级、租户级、playbook 级）必须全部打开才会真正行动，默认一律 preview——计划与模拟步骤附在告警上供人阅读。审批是一个持久化暂停：运行现场（步骤索引加完整上下文）挂起到 Postgres，重启后从批准处的下一步恢复，无人决策的审批会带着记录过期，而不是永远吊着。真正执行时，25 种步骤类型里 16 种是「治理动词」，每次派发都对照能力契约逐个分级——批准了一个 playbook 不等于批准了它包含的一切动作；审批人必须持有该动作的权限层级，且不能是申请人自己（职责分离）。动作执行后还要向厂商探测验证结果，而不是把 HTTP 200 当成功。

4.2 管住模型的四道闸门

AiSOC 对 LLM 的约束设计是全文最值得抄的部分，可以归纳为四道闸门。

第一道：出站提示词先验证。 即将发给模型的提示词如果包含原始 OCSF 载荷、厂商日志行或形似密钥的值，请求在发送前被拒绝——注意是「拒绝发出」，不是「发出去之后事后脱敏」。v20.3.0 又加了字节数上限（默认 240,000 字节），超长提示按注水法在各非系统消息间公平截断，系统提示词原样保留，每一处剪裁都标记在文本里。

第二道：模型永远不写查询语句。 智能体调用的是类型化工具——事件湖查询、图谱遍历、富化查询，模型只负责挑工具、传参数；hunting 场景下自然语言被翻译成模板化的 ES|QL、SPL 或 KQL，模型从头到尾写不出一句原始查询。这直接封掉了「模型生成危险 SQL」这一整类事故。

第三道：接地性检查。 结论里引用的每个指标都对照证据核验——引用了证据中从未出现过的 IOC，结论自动降级转人工复核而不是自动关闭；调查路径（人主动发起的那种）上，报告的置信度会直接降到实测接地率，并在摘要里写明哪些指标缺乏支持。空证据集干脆拒绝评分，返回 groundedness: null 而不是 0.0——手工开立的案件不带遥测，硬打分会让「没测」伪装成「测了全不支持」。

第四道：一切进账本。 每条提示词、每次工具调用、每条引用、每个结论和 token 成本，全部写入 Investigation Ledger，并可导出为签名的证据包（逐字节一致、提示词以摘要形式呈现、遵循 OCSF 1.9.0）。MCP 审计组工具（aisoc_replay_decision、aisoc_explain_step）让外部智能体客户端也能回放任意一步「它当时被喂了什么、答了什么、用了哪些工具」。

4.3 「可执行是挣来的」：检测规则工程

检测规则侧有一条更朴素也更硬的纪律：一条规则只有在真实连接器和真实引擎上重放、并被亲眼看到触发之后，才被允许进入编译规则集——绝不因为目录里有文件或 YAML 里写着 enabled 就计入。这个数字还因为诚实而变小过：架构文档记录了它从 2,603 降到 2,530 的过程，引用着根本不存在的计数器的规则被重写或拒绝，而不是留在总数里充数；目前还有 2 条规则无法触发（从 119 一路降下来），全部等行为基线数据。规则迁移工具 aisoc-migrate 同样「拒绝而不是近似」：捆绑的 2,005 条 Splunk 规则中 1,734 条可翻译，其中 1,711 条是部分翻译（字段匹配带过来、聚合阈值带不过来），86.5% 被明确标注为「有用的起点」而非「完成的迁移」——一条几乎正确的检测规则比缺失的更难发现。

4.4 与同类架构的路线差异

与把 LLM 当「全权分析师」的激进路线相比，AiSOC 把模型放在「初筛实习生」的位置：判定要引用、动作要审批、能力要逐次分级。与 Wazuh 这类传统开源 SIEM/XDR 相比，差异不在规则数量而在链条末端——传统引擎到告警为止，AiSOC 把「告警之后谁来看」也工程化了。与商业 AI SOC 相比，它的差异化是数据主权（默认本地模型，出站 LLM 为零）加结论可审计。而所有这些约束的 Enforcement 不靠文档靠测试：CI 里每一个能力行都有对应工作流，跑真实基础设施、带负面对照，两个 live 测试套件还真的抓到过离线测试抓不到的缺陷——连接器调度器曾把所有轮询任务注册成暂停态，回溯狩猎的批量写出曾在一个租户的行级安全上下文里冲刷了下一个租户的数据。

五、应用场景

先看一张原理图，把上一节的四道闸门与审计闭环连起来读——这也是后面所有场景共同的信任基础：

AiSOC 管住 LLM 的四道闸门与审计闭环手绘图：出站提示词验证、类型化工具、接地性检查、全量账本，以及从 Kafka 告警到人工审批、厂商验证的完整时序

场景一：中小安全团队的告警初筛与降噪

痛点：三五个安全工程师的团队要盯 EDR、云平台、身份系统十几个来源的告警，绝大多数是例行扫描和误报，人肉分诊既慢又漏。如何解决：AiSOC 把接入做到「连上即可用」——87 种点选式连接器覆盖 Splunk、Sentinel、Elastic、CrowdStrike、Okta、AWS、Kubernetes 审计等主流来源，没有厂商画像的来源也能走通用映射解析出主机、用户和源 IP。告警产生后本地模型自动给出分诊结论、置信度和理由，关联引擎把十条相关告警并成一条事件，优先级评分用「严重度 × 资产关键度 × 身份特权 × 已知在野利用暴露」相乘排序——上下文相乘而非相加，保证信息级告警永远不会排到严重告警前面。最小示例：

git clone https://github.com/beenuar/AiSOC && cd AiSOC
make up            # 16 个容器，约 8 GB 内存，无需任何云凭据
make smoke         # 十阶段黄金流水线自检，逐段报 PASS/FAIL

控制台登录后按 Load sample data，五个场景走真实 ingest 通路（不插行），亲眼看到事件变成告警、告警被 AI 分诊的全过程。收益与量化：官方演示口径下，首次启动 64 秒即可到登录控制台；分诊记录带 token 成本，成本仪表盘直接可见每条告警花掉的推理开销。适用边界：它明确声明不是 SIEM 替代品——不做长期日志留存与合规检索，也没有发现未接入遥测的能力；已有完整 SIEM 的团队应把它当「告警之后那一层」叠加使用。

场景二：数据不出域的合规环境分诊

痛点：金融、政务、医疗环境的遥测高度敏感，商业 AI 分诊 SaaS 要把告警内容发给云端大模型，安全与合规团队过不了关。如何解决：AiSOC 默认零出站——捆绑的 llama3.2:3b 就在自家容器里推理，README 的安全姿态表里「出站 LLM：默认无，捆绑模型随栈部署」是一条可验证的承诺；确需更强模型时，可在控制台按租户配置 openai、anthropic、azure-openai、local-ollama、local-vllm、local-litellm、custom 七类提供方，凭据用 Fernet 加密落库、API 永不回显。最小示例（Apple Silicon 上让原生 Ollama 走 Metal 加速，容器化路径在 Mac 上拿不到 GPU）：

brew install ollama
OLLAMA_HOST=0.0.0.0 ollama serve
ollama pull llama3.2:3b-instruct-q4_K_M
make up-host-llm   # 复用你已装的 Ollama，不另起容器

收益与量化：分诊可用性实测 50/50（输出约束为 JSON 后），结论带置信度与逐字理由，全程留在内网。适用边界：3B 模型的判断上限明确，需要更强推理的复杂调查应配置托管模型，代价是数据出域——这个取舍要由安全团队显式做出，而不是默认发生。

场景三：把「AI 说了什么」变成可呈堂的证据链

痛点：SOC 用 AI 辅助后，审计与复盘变成新难题——模型当时看到了什么、为什么关闭这条告警，说不清楚就等于把处置决策架在不可解释的黑盒上；监管部门与客户也开始要求对自动化决策给出可追溯说明。如何解决：这是 AiSOC 的立身之本。每条调查都是 Investigation Ledger 里的一串记录：提示词、工具调用、引用、结论、token 成本，可整体导出为签名证据包（逐字节一致、提示词以摘要形式存储、OCSF 1.9.0 编码）。回放是时间冻结的：历史重放在检索查询层强制证据截止时间（不是靠提示词自觉），且无法执行真实动作——变更边界在写入适配器上，不由指令控制。最小示例（用 MCP 客户端审计任意一步）：

{
  "mcpServers": {
    "aisoc": {
      "command": "python3",
      "args": ["-m", "app.server"],
      "cwd": "/path/to/AiSOC/services/mcp",
      "env": {
        "AISOC_API_URL": "http://localhost:8000",
        "AISOC_API_TOKEN": "your-token"
      }
    }
  }
}

接上后按 aisoc_list_alerts → aisoc_get_alert → aisoc_run_investigation → aisoc_explain_step 的顺序走一遍，第四步就是调阅「系统当时被喂了什么、答了什么」。收益与量化：v21.0.0 起每张评测记分卡带 provenance 状态（verified / self_reported / unattributed / serving_mismatch / no_calls），无法绑定到归因调用的测量结果不能授权自动关闭——审计口径从「相信我」变成「查我」。适用边界：证据包面向审计与复盘，不替代取证级的终端镜像与日志保全。

场景四：存量检测规则的迁移与补强

痛点：团队在 Splunk、Sentinel、Elastic 里积累了上千条检测规则，换平台时规则资产怎么搬？搬运后哪些规则真的能触发？如何解决：packages/aisoc-migrate 直接翻译 SPL、KQL、EQL 三种方言，且拒绝翻译它带不动的东西（transaction、lookup、join、sequence 等九类构造），因为「几乎正确的规则比缺失的更难发现」；搬进来的每条 Sigma 规则都要在真实连接器与引擎上重放到亲眼触发才计入可执行集，--prove-gate 开关甚至会回退 Windows 连接器、要求全部 1,687 条 Windows 规则归零触发来验证闸门有效。最小示例：

python3 packages/aisoc-migrate/inbound.py --dialect spl --file my-searches.txt

收益与量化：捆绑实测口径为 2,005 条 Splunk 规则 1,734 条可翻译（其中 1,711 条部分翻译，86.5%），未达标准的规则连同原因留档。适用边界：部分翻译意味着聚合类阈值逻辑仍需人工重写，把它当「有用的起点」而非自动迁移工具。

场景五：威胁情报驱动的回溯狩猎

痛点：新 IOC 公布时，过去 30 天的遥测里有没有它留下的痕迹？多数团队没有便利手段回头查。如何解决：full 档部署的 ClickHouse 事件湖存全部规范化事件，新的威胁情报到达时自动重扫历史（retro-hunt），假设交给模型填充闭合 schema、每个值绑定参数化，模型根本表达不出自由查询；服务内置 CISA KEV 目录（无需 API key 的真实外部情报源），启动几分钟内就能在控制台看到 1,754 条真实在野利用漏洞条目。收益与量化：68 个 YAML 狩猎模板对着租户事件编译，114 个过滤字段全部可编译到湖列或存储载荷；回溯发现与新预测分开标注，绝不把新情报扫出的旧痕迹计为「当时的预测」。适用边界：回溯狩猎是可 rehearsal 的显式模式（RETRO_HUNT_DRY_RUN=1 只记录建议重开不落变更），需要 full 档的事件湖支撑。

六、快速上手

三种起跑姿势按资源从少到多：不想装 Docker，pip install aisoc-sandbox && aisoc-sandbox demo 可在 30 秒内离线走完一条告警的智能体漏斗；在 GitHub Codespaces 里打开仓库跑 make up，连本机都不需要；正经体验用标准路径——git clone 后 make up，首次运行会生成 15 个真实密钥、创建管理员并一次性打印密码。硬性要求是 Docker Compose v2、Docker VM 内 8 GB 内存（full 要 12 GB）与 20 GB 磁盘，make doctor 会逐个查询数据存储本身而不是问容器活没活着。装完先 make smoke 跑十阶段自检，再 make demo 加载带标记的合成数据。要上生产记住四件事：ENVIRONMENT=production 必须显式设置（默认 development 在认证旁路名单里）、前置反代做 TLS、备份好 make up 生成的 .env、CORS 来源设成控制台真实地址（生产环境配通配符会拒绝启动）。

七、横向对比

维度	AiSOC	Wazuh（开源 SIEM/XDR）	商业 AI SOC（Dropzone 类）	传统 SIEM（Splunk/Sentinel）
定位	告警分诊与 AI 调查层	端到端 XDR/SIEM	AI 告警分诊 SaaS	长期留存与合规检索
AI 分诊	本地 3B 模型，可换 7 类提供方	无原生 LLM 分诊	云端专有模型	部分带 AI 助手附加销售
结论可审计	全量账本 + 签名证据包	依赖通用日志	黑盒为主	各家程度不一
数据主权	默认零出站	完全自托管	遥测出域	自托管或云
响应动作	25 类步骤、默认人工审批	主动响应模块	自动化程度不一	SOAR 另购
上手成本	16 容器 8 GB 内存	组件较多	注册即用	重实施
协议	MIT	GPL 系	闭源订阅	商业许可

选型建议：已有 SIEM、缺「告警之后谁来看」的团队，AiSOC 与 Wazuh 不冲突，一个管分诊一个管采集留存；合规敏感选 AiSOC 的本地模型路线；只想要零运维的 SaaS 体验再考虑商业产品（功能以各家官方资料为准）。 AiSOC 自己的建议同样诚实——它不替代长期日志留存，别把它当 SIEM 用。

八、局限与风险

四条官方承认的边界要记牢。第一，托管大模型路径从未被实测——项目没有 funded key，所有已发布的智能体数字都来自本地 3B 模型，托管路径「存在但未测」；3B 模型的分诊是「可用输出」意义上的 50/50，不等于判断准确率。第二，长时段规模数字不存在：压测脚本有 ramp、突发、背压和 24/72 小时浸泡画像，但长档没跑过，任何吞吐数字都没有出处。第三，包分发半成品：五个 PyPI 包已可用，三个 npm 包还差首次上传的 NPM_TOKEN。第四，四项评测指标里三项是「基底自洽性门禁」而非智能体准确率，只有 MITRE 准确率测的是活体智能体。外部风险方面，AI SOC 的通用攻击面——对分诊模型的提示注入——在行业里已有概念验证讨论，AiSOC 的缓解是出站提示词验证与接地性检查，但接入了不可信遥测来源的部署仍应假设攻击者会尝试影响模型输入；此外项目创建于 2026 年 5 月，半年冲到近 6,000 星，贡献高度集中于主开发者（1,042 次提交），巴士因子与长期维护节奏有待观察。

九、小结与行动建议

AiSOC 的价值不在「用了大模型」，而在「如何让一个会犯错的模型进入安全决策链而不失控」：模型只初筛、动作要审批、结论带引用、过程全记账、数字敢自曝。这份克制让它成为当下最值得研究的开源智能体工程样本之一，哪怕你的团队不做安全。

给不同读者的行动建议：

安全工程师：本周找台 8 GB 内存的机器跑 make up + make smoke + make demo 三连，用 sample data 观察分诊质量与关联效果，再决定接哪一路真实遥测。
智能体开发者：重点读四道闸门的实现——出站提示词验证、类型化工具、接地性检查、持久化审批暂停，这套模式可直接搬到任何「LLM 决策 + 人工兜底」的业务。
平台与合规团队：审查 Investigation Ledger 与签名证据包的导出链路，评估其作为自动化决策审计依据的充分性。
检测工程师：用 aisoc-migrate 试翻译现有 SPL/KQL 规则，读拒绝清单里「为什么带不过来」，比任何教程都更快理解两个引擎的能力差异。
观望者：等托管模型路径被实测、长时段压测数字发布之后再评估生产采用，当前阶段的正确姿势是试点与观察。

参考资料

AiSOC 仓库与 README：https://github.com/beenuar/AiSOC（获取日期 2026-11-02）
官方架构文档（11 步流水线与 5 张图）：https://github.com/beenuar/AiSOC/blob/main/docs/architecture/README.md（获取日期 2026-11-02）
AiSOC Technical Guide v1.2（27 页 PDF，2026-10-31）：https://raw.githubusercontent.com/beenuar/AiSOC/main/apps/web/public/papers/aisoc-technical-guide.pdf（获取日期 2026-11-02）
v21.0.0 发布说明（eval-honesty major）：https://github.com/beenuar/AiSOC/releases/tag/v21.0.0（获取日期 2026-11-02）
分诊可靠性测量脚本：https://github.com/beenuar/AiSOC/blob/main/scripts/measure_triage_reliability.py（获取日期 2026-11-02）
文档门户（安装/API/基准方法学）：https://beenuar.github.io/AiSOC/（获取日期 2026-11-02）
项目成熟度定义与声明-门禁矩阵：https://github.com/beenuar/AiSOC/blob/main/docs/audit/MATURITY_DEFINITION.md（获取日期 2026-11-02）