内容来源：https://blog.n8n.io/building-an-ai-powered-incident-response-workflow-in-n8n/

内容总结：

标题：n8n联合推出AI安全自动化框架，破解安全运维三大痛点

【报道】近日，企业自动化平台n8n的客户成功负责人Viraj与安全自动化专家Dmitry联合发布一套开源安全事件响应自动化框架，旨在解决安全运营中心（SOC）面临的三大顽疾：事件平均解决时间（MTTR）攀升、攻击处置成本居高不下、分析师因 burnout 导致的高离职率（部分SOC人员流失率达10%-25%）。

该框架的核心思路是“复用而非重建”，通过三个技术支点实现：

1. 自动捕获并复用历史处置经验
传统事后复盘报告鲜少被二次查阅，而分析师离职会带走关键知识。框架利用检索增强生成（RAG）管道，自动将每次安全事件的处置逻辑、根本原因等知识向量化存储。当新事件发生时，系统能从历史数据库和剧本库中精准匹配最相关的处置方案，无需分析师额外操作。

2. 释放分析师精力，聚焦创造性工作
框架自动接管事件处置中的重复性劳动，如检索Slack历史记录、翻阅旧处置笔记等，让分析师专注需要人工判断的关键决策。

3. 构建审慎、可控的AI使用边界
考虑到企业对误报、数据泄露的担忧，框架设计了多层安全机制：所有建议均标注来源（剧本/历史案例/外部情报/通用知识），低置信度匹配会自动标记；输出数据需通过结构化校验才写入数据库，避免“幽灵建议”；同时支持完全本地化部署，敏感数据无需经过第三方云服务。

技术架构解析

• 数据层：使用Supabase向量数据库存储剧本和已处置事件。
• 检索层：新事件触发三条并行检索——最优匹配剧本、相似历史案例、实时威胁情报（通过Tavily网络搜索）。
• 合成层：由LLM（默认Claude Opus 4.5）整合三路结果，生成包含立即行动、遏制步骤、IOC指标、置信度等字段的结构化处置手册。同时输出Markdown版本直接用于战情文档。

部署要点
团队需准备好：1）高频事件的参考剧本；2）包含完整处置记录的历史事件数据；3）建议添加MITRE ATT&CK标签以提升检索质量。框架预置13个测试事件（覆盖勒索软件、钓鱼、暴力破解等场景），从部署到跑通约30分钟。

未来演进方向
团队计划进一步开发：低风险自动化（如自动发送异常登录通知邮件）、需人工确认的处置子流程（如隔离端点、封锁IP）。目前框架已在GitHub开源（含完整部署文档），并支持一键导入n8n工作流模板。

参考数据：Critical Start调查报告显示，50%-90%的机构正“探索”或“计划”在SOC中使用AI。

中文翻译：

Viraj曾负责n8n的客户成功部门，帮助电信、政府、金融及其他行业的企业客户采用n8n，并在关键部门成功推广落地。他与网络安全领导者有大量合作经验，并在下文分享了这些心得。

Dmitry是一位安全自动化与检测工程师，在检测工程、SecOps自动化及云安全方面拥有丰富背景。他曾在蓝队领域深耕多年，负责构建和审查跨云环境的安全工具，并作为合著者将这些经验融入其中。

事件响应团队正面临一系列问题，这些问题很少会主动发出预警。它们会在后台悄然积累，直到在最致命的地方爆发：

• 平均修复时间（MTTR）不断攀升
• 那些本应在发现后几秒内就被制止的攻击，造成了越来越高的经济损失
• 身心俱疲的分析师选择离职，导致员工流失率居高不下

本文介绍了一个为应对这些挑战而构建的自动化框架，同时为注重风险的网络安全工程经理提供了一种在其自动化工作流中利用人工智能的方法。根据我们的经验，许多经理对这种方式一直持谨慎态度。

我们是围绕在与众多安全运营中心（SOC）合作过程中反复遇到的三个核心目标来构建这个框架的：

1. 缩短捕获并复用以往成功经验的时间。
   目前，当事件得到解决后，修复措施背后的推理过程很少能被以有助于应对下一次事件的方式捕获下来。事后总结报告会被撰写，但当几个月后类似事件发生时，几乎没有人会去翻阅这些报告。而且，考虑到一半的SOC中分析师流动率高达10%至25%（来源1），当人员离职时，这些知识也随之流失。该框架利用检索增强生成（RAG）流程来自动捕获这些推理过程，并在分析师最需要的时候将其呈现在他们面前，且无需他们付出任何额外努力。

2. 让分析师重获注意力，专注于那些真正需要人类创造力的工作。
   在应对实时事件的过程中，埋头处理管理检查清单恰是最不合适的时机。通过将机械性的工作——例如搜索Slack聊天记录、翻阅旧的解决方案记录——从分析师的工作清单中移除，该框架释放了他们的精力，使其能专注于只有人类才能做出的关键判断。

3. 让人工智能在真实的SOC工作流程中安全可用。
   兴趣显而易见——调查不断报告称，50%至90%的组织正在“探索”或“计划”在SOC中使用人工智能（来源2）。难点在于如何将其转化为团队在应对实时事件时能够信赖的工具，这通常归结为几个担忧：

   • 将真实威胁错误地标记为误报，代价高昂。
   • 缺乏明确边界的人工智能可能浪费时间，或将分析师引向错误方向。
   • 工单数据通常过于敏感，无法通过第三方云端发送。

这些问题并非纯粹的技術问题，但部分解决方案在于技术层面。下面的资源库正是基于此构建的：自动化重复性、非创造性的工作，将有价值的上下文信息贴近分析师，并让团队根据自身的风险承受能力以及他们希望人类参与的程度，来调节人工智能的使用范围。

• 使用此前端生成并发送一个测试事件载荷（需要OpenRouter密钥）
• 在您自己的n8n环境中设置Github上的工作流。
• 在此联系我们，获取个性化演示。

工作流的功能
工作流在n8n中创建的Webhook地址处接收一个JSON格式的载荷。这种格式类似于来自您的SIEM（例如Elastic）或工单系统（例如Jira）的事件或工单。
载荷被接收后，会触发三个并行的检索过程：最匹配的参考剧本、历史记录中类似的已解决事件、以及来自网络的当前威胁情报。
一个合成代理会将这三者整合，生成一个结构化的行动手册：包含即时行动、遏制步骤、入侵指标、明确的假设前提以及低确定性情况下的置信度级别。
其原则是每次复用而非重新发明，从而更快地解决重复发生的事件。您是让LLM整理您团队已有的知识，而不是让其基于通用训练数据生成响应计划。
支撑这一切的是一个同样使用n8n构建的RAG流程，它负责将您的剧本和过去的事件进行分块，并存储在Supabase向量数据库中，以备主工作流使用。我们也提供了相关说明，以便将新解决的工单或剧本持续集成到这个向量数据库中。

架构详解
让我们更仔细地看看每个检索通道：

• 剧本检索。参考剧本被分块并存储在Supabase中。新事件会针对剧本库执行语义相似度搜索。检索出最匹配的条目。如果匹配质量较低，则会进行标记——代理不会在未找到强匹配时默默地进行处理。
• 威胁情报丰富。出于演示目的，这是通过Tavily基于告警类型、相关TTP、近期公告进行的网络搜索。在生产环境中，您会接入您的生产环境TIP或威胁情报工具的组合。
• 历史事件检索。已解决的事件会经过相同的向量化流程。同一个数据库，不同的表。相似度搜索会提取最相关的历史案例及其完整上下文：发生了什么，如何遏制的，哪些措施有效，哪些步骤比预期耗时更长。

来自所有三个通道的结果会合并到一个单一的合成代理中。该合成代理将合并后的信息块连同原始事件数据一起处理，最终生成行动手册。

技术栈：

• Supabase：向量存储和关系型存储。一个数据库处理两种任务。
• Gemini嵌入模型：用于数据摄入流程和检索。可以通过在n8n中简单地更改节点，替换为您选择的嵌入模型。
• OpenRouter：LLM路由。默认模型为Claude Opus 4.5。
• Tavily：为威胁情报通道提供网络搜索。
• n8n：工作流编排。

LLM是即插即用的。当有更强的模型发布时，您只需更改一个配置值，工作流的其余部分无需改动。对于那些无法将事件数据发送到云端AI供应商的团队——这在许多企业环境中是一个现实的限制——任何兼容OpenAI接口的端点都可以直接接入，包括用于完全本地推理的Ollama或vLLM。工作流不关心模型部署在哪里。

数据摄入流程与运行时工作流是分离的。您只需运行一次摄入流程来填充向量表——剧本、已解决事件、测试事件——并且只在将来需要向数据库添加新数据块时才再次运行。运行时工作流永远不会触碰它。

工作流同时产生两种输出。如果您有特定的输出格式偏好，可以移除其中一个以节省LLM输出令牌成本。

• 结构化JSON——一个包含离散字段的已校验模式：事件摘要、即时行动、遏制指导、提取的IOC、假设前提和置信度级别。每个字段都可以在下游流程中被独立寻址。可以将其输入到工单系统以预填充字段，馈送到SIEM规则，或触发下游的n8n工作流，而无需解析自由文本。
• Markdown格式的行动手册——相同内容的格式化文档。这是发布到Slack、写入作战室文档、以及事件期间供人类阅读的版本。源标签是内联的，因此无需打开JSON即可看到归因信息。

两者来自同一次合成运行。JSON是权威输出；Markdown由其生成。如果您只需要人类可读的版本，忽略JSON即可。如果您正在构建集成，请解析结构化字段并忽略Markdown。

前提条件
在基于真实数据运行工作流之前，需要将三件事准备妥当。

1. 参考剧本。至少需要涵盖您的组织面临的高频事件类型。它们不必很长——覆盖检测标准、初始分类步骤、遏制选项和已知误报模式的剧本就足够了。检索质量与特异性成正比。一个通用的“恶意软件响应”剧本只会返回通用的指导。而为您的EDR勒索软件检测专门编写的剧本，则会返回可用的内容。
2. 已解决事件历史。历史检索通道需要包含在“补救措施”和“经验教训”字段中有实际内容的记录。模板化的条目只会增加噪音。那些记录了具体发生了什么、涉及哪些系统、以及实际解决了问题的记录，才能提高输出质量。随着时间的推移和历史数据的增长，工作流会变得越来越有用。
3. 在工单上标记MITRE ATT&CK信息。这不是严格必需的，但数据摄入流程会利用战术和技术字段来丰富检索结果。附件中已有一个配套的n8n MITRE映射工作流可以为您完成此操作。

有些团队会先运行其SIEM的AI分组功能——将相关的告警合并成一个单一的、内容丰富的工单——然后将这个复合事件传入。这是一种受支持的模式，并且比输入原始的单条告警能产生更好的检索结果。

实施这个框架的一个理想副作用是，它将引导您逐步提升您组织的整体安全态势。

可追溯性与更多细节
合成提示词强制要求明确的源归因。行动手册中的每一条建议都带有一个标签：

• （来源：剧本）——来自匹配的参考剧本
• （来源：内部先例——[事件ID]）——来自特定的历史事件
• （来源：外部情报）——基于Tavily检索结果
• 【通用知识——非来源于输入】——不存在组织或外部来源

第四条可能需要解释一下。代理不会被指示抑制那些可能使输出变得不那么有用的通用知识。它被指示要诚实地标记出来。这样读者就能知道哪些是组织的先例，哪些是模型自行填充的内容。

此外，还有明确的“无匹配”处理机制。如果没有足够匹配的历史事件，行动手册会明确说明这一点。它不会凭空产生高置信度的指导，并隐瞒这一事实。

在写入数据库之前，输出会经过结构化模式验证。必需的键必须存在且非空。模式验证失败→发送错误通知。不会无声无息地写入格式错误的行动手册。

亲自尝试
测试这个框架最简单的方法是使用我们构建的用户界面：https://incident-response.deployed.engineer。这允许您向工作流（我们托管在n8n云上）发送JSON载荷。每次请求会产生LLM成本，因此我们要求您从OpenRouter获取一个密钥用于LLM调用。每次运行的成本大约在一两美元。

该工作流可作为n8n上的一个模板使用，供您在自有实例上设置。您需要四种凭据：Supabase、Google AI Studio（用于Gemini嵌入模型）或类似服务、OpenRouter或类似服务，以及可选的Tavily。所有这些都有免费层级。详细的文档可在Github上找到。

使用我们的示例数据进行设置大约需要30分钟，其中大部分时间是等待数据摄入。示例数据中包含13个测试事件，涵盖了勒索软件、网络钓鱼、暴力破解、S3错误配置和内部威胁。test-ransomware_detection-001是最佳的起点，因为它有很强的剧本匹配和很强的历史匹配，并会生成一个标记清晰的行动手册，您可以进行端到端检查。
→ 导入工作流模板

未来展望
今天介绍的框架旨在帮助中小企业和企业级SOC快速解决其在提升自动化水平方面最紧迫的优先事项。但我们相信这仅仅是个开始。在像您这样的贡献者和真实世界测试的帮助下，我们相信框架将朝以下方向演变：

• 自主丰富。代理可以自主运行的低风险丰富化和通知工作流。例如，当检测到可疑登录地点时向用户的经理发送电子邮件，或执行VirusTotal哈希查询。低风险的丰富化工作流使用n8n的“来自AI”功能自动运行。这些丰富化工作流本质上是确定性的，只有是否调用它们以及向工作流传递哪些（被锁定的）参数的决定是由代理做出的。
• 补救与通知工作流——由人工或AI触发。另一方面，任何会产生实际世界后果的操作都需要人工批准。离散的子工作流——例如隔离端点、在防火墙上阻止IP——通过行动手册“即时响应清单”中的Webhook链接触发。分析师进行审查，如果同意则点击执行，n8n随后执行。严格的人类决策边界，通过确定性工作流实现更快的补救。

核心框架已就绪，供您尝试：

• 在此处使用UI进行快速演示
• 在Github上查看详情，获取在您的环境中实施的详细说明

我们欢迎您通过此处的Github问题提交贡献、进行讨论和反馈。如果您是网络安全分析师或管理者，希望获得更贴心的服务，可以在此联系我们。

参考文献：
(1) https://www.msspalert.com/news/criticalstart-findings
(2) 略

英文来源：

Viraj led Customer Success at n8n where he helped enterprise customers in telecoms, government, finance and other industries adopt n8n and roll it out successfully across key departments. He spent a lot of time working with Cybersecurity leaders and draws on this experience below.
Dmitry is a Security Automation and Detection Engineer with a background in detection engineering, SecOps automation and cloud security. He has spent several years on the blue team side of the stack building and reviewing security tooling across cloud environments and draws on this experience as co-author.
Incident response teams are dealing with a set of problems that rarely announce themselves. They build up in the background until they show up where it hurts:

• a climbing mean time to resolution (MTTR)
• an increased dollar cost from attacks that should have been shut down seconds after detection.
• burned-out analysts head for the exit - high employee turnover
  This post introduces an automation framework built to address these challenges, while offering risk-conscious Cybersecurity Engineering Managers a way to leverage AI in their automation workflows. Something which from our experience, many managers have been rightly cautious about doing.
  We built it around three aspirations we kept running into across the SOCs we worked with:
  1. Reduce the time to capture and reuse what worked last time.
     Right now, when an incident gets resolved, the reasoning behind the fix is rarely captured in a way that helps with the next one. Post-mortems get written but almost never read when a similar incident lands months later. And with analyst turnover at 10–25% in half of SOCs (1), that knowledge walks out the door when people do. The framework uses Retrieval Augmented Generation (RAG) pipelines to capture that reasoning automatically and put it back in front of analysts at the moment they need it, with no extra effort on their part.
  2. Give analysts back their attention for the work that actually needs human creativity.
     Grinding through an admin checklist during a live incident is exactly the wrong time to be doing it. By taking rote work off the analyst’s plate — Slack-thread hunting, digging through old resolution notes — the framework frees up the headspace for the judgment calls only a person can make.
  3. Make AI safe to actually use in real SOC workflows. The interest is obvious — surveys keep reporting that 50–90% of organizations are "exploring" or "planning” AI use in the SOC (2). The hard part is turning that into something teams trust during a live incident, which usually comes down to a few worries:
• mislabeling a real threat as a false positive is a costly mistake
• AI without clear boundaries can waste time or steer analysts the wrong way
• ticket data is often too sensitive to send through a third-party cloud
  None of these are purely technical problems, but part of the fix is. The repository below is built around that: automate the repetitive, non-creative work, keep useful context close to the analyst, and let teams dial AI up or down based on their risk tolerance and where they want humans in the loop.
• Use this front-end to generate and send a test incident payload (OpenRouter key required)
• Set up the workflow found on Github on your own n8n environment.
• Getting in touch with us here for a personalized demo.
  What the workflow does
  The workflow receives a JSON payload at a webhook address created in n8n. This format is typical of an incident or ticket from your SIEM (e.g. Elastic) or ticketing tool (e.g. Jira).
  The payload is ingested and triggers three parallel retrievals: the closest matching reference playbook, similar resolved incidents from your historical record, and current threat intelligence from the web.
  A synthesis agent combines all three and produces a structured runbook: immediate actions, containment steps, IOCs, assumptions stated explicitly, confidence levels where certainty is low.
  The principle is reuse, not re-invention, each time and resolve repeated incidents faster. You're asking the LLM to organize what your team already knows, not to generate a response plan from general training data.
  Underpinning this is a RAG pipeline, also built using n8n that chunks your playbooks and past incidents and stores them in a Supabase vector database ready for the main work flow. Instructions are provided to continuously integrate new resolved tickets or playbooks into this vector database.
  Architecture walk-through
  Let’s look at each of the retrieval lanes more closely:
• Playbook retrieval. Reference playbooks are chunked and stored in Supabase. A new incident runs semantic similarity search against the playbook library. Top match retrieved. If match quality is low, that gets flagged — the agent doesn’t silently proceed as if it found a strong match.
• Threat intel enrichment. For demo purposes this is a web search via Tavily based on the alert type, associated TTPs, recent advisories. In production, you would plug in your production TIP or a combination of threat intel tools.
  Historical incident retrieval. Resolved incidents go through the same vector pipeline. Same database, different table. Similarity search pulls the most relevant past cases with full context: what happened, how it was contained, what worked, what took longer than expected.
  Results from all three lanes merge into a single synthesis agent. The synthesis agent takes that block plus the original incident data and produces the runbook.
  The stack:
• Supabase: vector store and relational store. One database handles both.
• Gemini embeddings: ingestion pipeline and retrieval. This can be swapped out for the embeddings model of your choice using a simple node change in n8n.
• OpenRouter: LLM routing. Default model is Claude Opus 4.5.
• Tavily: web search for the threat intel lane.
• n8n: orchestration.
  The LLM is plug-and-play. When a stronger model ships, you change one config value and the rest of the workflow stays untouched. For teams that can't send incident data to a cloud AI vendor — which is a real constraint in a lot of enterprise environments — any OpenAI-compatible endpoint works as a drop-in, including Ollama or vLLM for fully local inference. The workflow doesn't care where the model lives.
  The ingestion pipeline is separate from the runtime workflow. You run ingestion once to populate the vector tables — playbooks, resolved incidents, test incidents and only when you want to add new chunks to the database in the future. The runtime workflow never touches it.
  The workflow produces two outputs simultaneously. If you have a desired output format, you can remove one to save LLM output token costs.
• Structured JSON — a validated schema with discrete fields: incident summary, immediate actions, containment guidance, extracted IOCs, assumptions and confidence levels. Each field is addressable downstream. Pipe it into a ticketing system to pre-populate fields, feed it to a SIEM rule, or trigger a downstream n8n workflow without parsing free text.
• Markdown runbook — the same content as a formatted document. This is what posts to Slack, what goes into a war room doc, what a human reads during the incident. Source labels are inline so attribution is visible without opening the JSON.
  Both come from the same synthesis run. The JSON is the authoritative output; the markdown is generated from it. If you only need the human-readable version, ignore the JSON. If you're building an integration, parse the structured fields and ignore the markdown.
  Pre-requisites
  Before running the workflow on real data, three things need to be in reasonable shape.
  Reference playbooks. At minimum for the highest volume incidents your organization faces. They don't need to be long — a playbook covering detection criteria, initial triage steps, containment options, and known false positive patterns is enough. Retrieval quality scales with specificity. A generic "malware response" playbook returns generic guidance. A playbook written for your EDR's ransomware detections returns something usable.
  Resolved incident history. The historical retrieval lane needs records with actual content in the remediation and lessons-learned fields. Templated entries add noise. Records that document what specifically happened, which systems were involved, and what actually resolved it are what improve output quality. The workflow gets more useful over time as the history grows.
  MITRE ATT&CK mappings on your tickets. Not strictly required, but the ingestion pipeline uses tactic and technique fields for retrieval enrichment. There's already a companion n8n MITRE Mapping workflow that can do that for you.
  Some teams run their SIEM's AI grouping first — combining related alerts into a single enriched ticket — and pass that composite incident in. That's a supported pattern and produces better retrieval results than raw single-alert inputs.
  One of the desirable side effects of implementing this harness is that it will guide you through levelling up your organization’s security posture.
  Traceability & finer details
  The synthesizer prompt enforces explicit source attribution. Every recommendation in the runbook carries a label:
• (Source: Playbook) — from the matched reference playbook
• (Source: Internal precedent — [incident ID]) — from a specific historical incident
• (Source: External intel) — grounded in Tavily retrieval
• [General knowledge — not sourced from inputs] — no organizational or external source exists
  The fourth might merit explanation. The agent isn’t instructed to suppress general knowledge that would make the output less useful. It’s instructed to label it honestly. The reader knows what’s organizational precedent and what the model filled in.
  There’s also explicit no-match handling. If no historical incidents match closely enough, the runbook says so. It doesn’t produce high-confidence guidance from a blank slate and omit that fact.
  Before the database write, output goes through structured schema validation. Required keys must be present and non-null. Schema fails → error notification. No silent write of malformed runbooks.
  Try it yourself
  The easiest way to test this is using the UI we have built: https://incident-response.deployed.engineer. This allows you to fire JSON payloads at the workflow (which we have hosted on n8n cloud). There is a LLM cost per request so we ask that you get a key from OpenRouter which is used for the LLM calls. Each run will cost a dollar or two.
  The workflow is available as a template on n8n to set up on your own instance. You will need four credentials: Supabase, Google AI Studio (for Gemini embeddings) or similar, OpenRouter or similar, and optionally, Tavily. All have free tiers. Detailed documentation is available on Github.
  Setup takes about 30 minutes with our demo data, most of which is waiting for ingestion. 13 test incidents are included in the sample data covering ransomware, phishing, brute-force, S3 misconfiguration, and insider threat. Test-ransomware_detection-001 is the best starting point it has a strong playbook match, strong historical match, and produces a well-labeled runbook you can inspect end-to-end.
  → Import the workflow template
  What’s next
  The framework presented today has been built to enable SMB and enterprise SOCs to quickly address their most pressing priorities for levelling up automation. But we expect that this is just the beginning. With the help of contributors like you and real world testing, this is how we believe the framework will evolve:
  Autonomous enrichment. Low-risk enrichment and notification workflows the agent can run . Examples would be sending an email to a user’s manager when a supicious login location is detected or executing a VirusTotal hash lookup. Low-risk enrichment runs automatically using n8n’s ‘From AI’ function. The enrichment workflows remain deterministic in nature, only the decision on whether to call them and what (locked-down) parameters to pass to the workflow is taken by the agent
  Remediation & notification workflows - human or AI triggered. On the other hand, anything with real-world consequences requires human approval. Discrete sub-workflows — isolate-endpoint, block-ip-on-firewall — triggered from a webhook link in the runbook's Immediate Response Checklist. Analyst reviews, clicks if they agree, n8n executes. Strict human boundary, faster remediation with a deterministic workflow.
  The core framework is ready for you to try:
• Here for a quick demo using the UI
• On Github with detailed instructions for implementation in your environment
  We’re welcome to contributions, discussions and feedback using Github issues here. For a white-glove treatment, if you are a Cybersecurity Analyst or Manager, you can get in touch here.
  References: (1) https://www.msspalert.com/news/criticalstart-findings