AiSOC：把 AI 安全运营中心的决策过程摊开给你看的开源方案
项目速览：开源人工智能驱动的安全运营中心、警报融合、紫队演习、代理辅助分类、MITRE ATT&CK 调查。麻省理工学院许可，可自行托管。
秒懂
- 它是什么？
- AiSOC 是一个可自托管的开源 AI 安全运营中心，用 LangGraph 编排告警分诊、事件调查和紫队演练。它最大的卖点不是自动化本身，而是把代理的每一步提示词、工具调用和推理过程都记录在案，并且用公开的评测门禁来约束行为。
- 适合谁用？
- 适合以下团队采用：需要自托管、对数据出境敏感、并且愿意接受 AI 代理介入安全运营的安全团队。不适合以下团队：没有 Python 或 Docker 基础、希望开箱即用、或者对 AI 生成的分诊结果零容忍的团队。
- 能商用吗？
- 可以。MIT 是宽松许可证：你可以使用、修改并销售基于它的软件，只需保留版权和许可证声明。
- 还在维护吗？
- 在维护。仓库最近一次提交在 5 天前。
- 用什么语言写的？
- 主要是 Python（依据 GitHub 的语言统计）。
以上回答依据项目的 GitHub 数据（最近同步于 2026年9月18日）和我们的分析，不构成法律意见。
开源项目深度解析
它解决什么问题，给谁用
安全运营中心每天面对大量告警，其中大部分是误报。AiSOC 想解决的是两个问题：告警太多，人工看不过来；AI 代理介入之后，你无法信任它为什么做出某个判断。这个项目把告警融合、AI 调查和紫队演练装进一个可自托管的栈里，目标用户是那些既想用 AI 又不愿把数据交给闭源厂商的安全团队。它明确区分自己和闭源 AI SOC 厂商：代理决策有日志，评测有公开的 CI 门禁，数据出境可控。如果你只是想要一个告警管理工具，它太重；如果你想要一个能解释自己行为的 AI 安全助手，它正好。
核心机制：LangGraph 编排与 Investigation Ledger
AiSOC 的编排器是一个约 600 行的 LangGraph，放在 `services/agents/` 目录里。这个图把调查流程拆成 Detect、Triage、Hunt、Respond 几个阶段，代理在阶段之间调用工具、引用证据。关键的设计是 Investigation Ledger，它把每次运行的 LLM 提示词、模型响应、引用的证据以及下游工具调用都存下来，之后可以回放。README 里强调这是它与闭源厂商的本质区别：你不仅能看到结论，还能看到推导过程。这个设计对安全审计很重要，因为安全运营里出了问题要追责，没有过程日志就没法复盘。600 行的规模意味着你可以通读整个编排逻辑，换模型、改工具调用都很直接。
跑起来：四条路径，从零依赖到完整栈
AiSOC 提供了四种启动方式，对应不同的环境。最简单的是 `npx aisoc triage --demo`，它用确定性引擎对 200 条告警打分，输出 12 TP、171 FP 抑制、17 条待审，全程不需要 LLM API key。如果你有 Python 3.10+，可以 `pip install -e packages/aisoc-sandbox && aisoc-sandbox demo`，这是一个零依赖的内存模拟器，能在 5 秒内走完整个代理漏斗，支持 `lateral-movement`、`aws-credential-exfil` 等内置场景，也可以用 `--file` 传入自己的 JSON。完整栈需要 Docker 和 pnpm，`git clone` 后运行 `pnpm aisoc:demo`，会启动 Postgres、Redis、Kafka、api、agents 和 web，浏览器打开 `/cases/INC-RT-001?tab=ledger` 就能看到 LockBit 3.0 案例的实时调查过程。干净机器上可以用 `curl -fsSL .../install.sh | bash` 自动装依赖。注意，README 提到 `npx aisoc` 要等 v8.0 发布才正式上线，目前只能从 `packages/aisoc-lite/` 构建。
评测门禁：不是嘴上说好用，而是有 CI 在卡
这个项目最实在的部分是评测。README 说，每个 PR 要过五套评测：告警缩减是针对固定 1000 条告警流的真实测量；另外三套基于规则的套件是在确定性的 200 事件数据集上（55 个模板，带模板级宏）做自一致性检查；第五套验证底层遥测语料。这意味着告警抑制率不是宣传数字，而是有具体基准的。`compose-smoke` 和 `e2e` 工作流会在每次 push 时跑同样的 `pnpm aisoc:demo` 路径，夜间还有冷缓存重复测试。这比大多数开源项目只跑单元测试要严格得多。但注意，评测套件衡量的是自一致性，不是真实世界的检测能力，它不能证明 AiSOC 能发现所有攻击。
数据出境与隐私：伪匿名化不是匿名化
AiSOC 强调你控制什么离开你的边界。没有回调到厂商云，也没有模型改进遥测。如果使用托管 LLM，证据默认会伪匿名化，内部 IP、主机名、邮箱、路径、密钥、用户名都会变成不透明令牌。如果你想完全隔离，可以跑本地模型，比如 Ollama 或 vLLM。README 明确说数据流细节在 `docs/trust/data-flows.md` 里。这里有个需要警惕的点：伪匿名化是可逆的，不是匿名化，对于严格合规的环境，仍然需要自己审计到底什么被发送出去。而且，伪匿名化只针对证据，LLM 提示词本身可能包含上下文信息，这一点文档没有详细说明，需要你自己去看数据流文档确认。
替代方案：Wazuh 和 Splunk ES 的差距在哪
README 的对比表给出了两个替代品：Wazuh 和 Splunk ES。Wazuh 是 GPL-2 许可，可以自托管，但没有自主 AI 调查能力，它是传统的规则和告警引擎。Splunk ES 是专有软件，企业版才能自托管，有部分 Splunk AI 功能，但代理决策审计轨迹不公开。AiSOC 的定位是夹在两者之间：它比 Wazuh 多了 LangGraph 编排的 AI 调查，比 Splunk ES 多了 MIT 许可和公开的审计日志。如果你已经有 Wazuh 的部署，迁移到 AiSOC 意味着要接受一个更复杂的架构（Kafka、Redis、Postgres），但换来的是可回放的代理决策。
维护与升级成本：活跃开发，但依赖较重
项目最近更新频繁，v7.7.0 在 2026 年 8 月发布，v7.6.0 和 v7.5.0 分别在一个月和两个月前。这说明项目处于活跃开发期，但这也意味着 API 和配置可能变化较快，升级时要注意 CHANGELOG。完整栈依赖 Postgres、Redis、Kafka，这三个组件本身就是运维负担，不是小团队能轻松维护的。好在有 Helm 和 Terraform 目录（`infra/helm/`、`infra/terraform/`）用于生产部署，但这也要求你熟悉 Kubernetes 或 Terraform。MIT 许可意味着你可以随意修改和分发，但如果你 fork 了，就得自己跟上上游的更新。社区演示站点运行在 Fly.io 上，README 明确说它可能离线，所以不要依赖它做任何关键评估。
编辑结论
适合以下团队采用：需要自托管、对数据出境敏感、并且愿意接受 AI 代理介入安全运营的安全团队。不适合以下团队：没有 Python 或 Docker 基础、希望开箱即用、或者对 AI 生成的分诊结果零容忍的团队。采用前应先验证三件事：一是跑一遍 `pnpm aisoc:demo` 确认本地栈能起来，二是阅读 `docs/trust/data-flows.md` 确认伪匿名化符合你的合规要求，三是用 `npx aisoc triage --demo` 感受一下确定性评分引擎的输出是否满足你的告警量级。AiSOC 的价值不在于它多智能，而在于它的决策过程可以被回放和审计，这一点在开源 SOC 工具里是稀缺的。
社区笔记