这个项目的起点很朴素：SOC 从来不缺告警，缺的是把告警变成判断所需的时间、上下文和一致性。

WAF 看到请求特征，RASP 看到运行时调用栈，HIPS 看到主机行为，NDR 看到网络连接，SIEM 再把其中一部分拼成事件。数据并不少，但字段、时间线、证据强度和处置口径各不相同。高峰期里，分析师最耗精力的工作往往不是发现一个从未见过的攻击，而是重复完成以下步骤：理解厂商日志、补齐证据、寻找相似事件、写研判意见、列处置项，再确认哪些动作需要审批。

Defensive AI Agent 想解决的正是这一段工作。它不是替代安全设备，也不是给日志系统加一个聊天窗口；它更接近一个位于检测产品与响应流程之间的“研判网关”：统一接入证据，让模型承担归纳、关联和假设生成，再用确定性代码、人工复核与审批系统约束模型能把事情推进到哪里。

AI 正从回答问题走向参与流程

过去两年，安全领域使用大模型的方式已经有了一次明显迁移。最早的需求大多是解释一条日志、生成一段查询语句或总结一份报告；现在更有价值的方向，是让模型在受控工具和明确状态机中持续工作：读取 Case、提出调查计划、补查证据、修正假设，最后生成可执行但尚未执行的响应方案。

这个变化也带来新的工程要求。模型一旦从“回答者”变成“流程参与者”，问题就不再只是答案是否准确，还包括它看到了什么、调用了什么、是否越权、失败后告警去了哪里，以及一条错误经验会不会污染后续判断。

NIST Cyber AI Profile 的初步草案把 AI 与网络安全的交叉点概括为三个方向：保护 AI 系统、用 AI 增强防御、应对 AI 增强的攻击。Defensive AI Agent 主要落在第二个方向，但要真正用于安全运营，前两个方向的控制也必须同时进入设计。换句话说，不能一边让 AI 帮忙防御，一边把它本身做成新的高权限入口。

OWASP 对 Agentic AI 的讨论则更直接：工具误用、身份与权限滥用、目标劫持、记忆与上下文污染，都是 Agent 获得行动能力以后才会被放大的风险。Excessive Agency把根因归纳为功能过多、权限过大和自主性过强。我们的设计几乎是反着这三点展开的：工具做窄、权限只读、高影响动作交给独立审批。

真正难的不是接一个模型 API

第一版原型很容易做：收到 JSON，拼出 Prompt，请求模型，再把结果显示在页面上。真正进入联调后，难点很快从模型调用转向了系统工程。

项目由此形成了四条一直没有妥协的原则：事实与模型意见分开保存；概率分析与确定性门禁分开实现；调查与执行分开授权；模型故障时可以延迟处理，但不能悄悄换一种分析口径。

当前架构

线上环境目前是一套单机形态：Caddy 提供 HTTPS 边界，Gateway 与 Vector 运行在 Docker 中，Vector 接收安全产品的 Syslog，Gateway 负责 HTTP API、研判编排和工作台，SQLite 保存事实、状态和审计记录。模型通过企业 LLM Gateway 调用，不直接暴露在公网入口。

这套形态适合联调、演示和小规模 PoC。它完整展示了控制链路，但还不是高可用的生产集群，这个边界会在后文单独说明。

1. 接入先解决“能不能可靠留下来”

系统同时支持 HTTP JSON 和 Syslog。WAF、HIPS、NDR、RASP、SIEM 分别使用独立的产品路由；单机部署中，Vector 监听 15140 到 15144，正式接入优先使用 TCP。对调用栈较长的 RASP 日志，帧上限被提高到 2 MiB，避免沿用 Collector 较小的默认缓冲造成静默截断。

厂商原始日志不会被要求提前改成系统内部格式。Mapping Profile 负责字段路径、类型转换和产品语义映射，也支持从脱敏样本推断候选映射并执行 dry-run。内置的内容指纹还能识别常见产品格式；无法确认来源、又不符合标准告警契约的数据会被拒绝，而不是含糊地送进模型。

映射完成后，告警先写入 durable_alert_inbox，提交成功才返回 202。远端模型暂时不可达时，记录进入 deferred，等待恢复后释放；鉴权失败、错误端点或响应契约错误属于需要人工修复的配置问题，会进入 DLQ。队列达到条数、字节或磁盘保留水位时，入口返回 429，把压力传回 Vector 的磁盘缓冲。

这里有一个看似细小、实际很重要的约束：alert_id 是不可变告警实例的幂等键。相同 ID、相同内容可以安全重投；相同 ID 携带不同时间、字段或证据时返回 409 alert_id_conflict。系统宁愿让上游显式处理身份冲突，也不覆盖已经进入审计链的事实。

2. 模型看到的是证据投影，不是原始数据仓库

每条告警在本地保存两种主要形态：RawAlert 保留原始事实，NormalizedEvent 保存供分析使用的实体、证据引用、敏感标签和规范化语义。RASP 场景还会记录原始日志字节数、Syslog 消息字节数、两层 SHA-256、items[] 数量、hook_data 与 stacktrace 状态。

这套设计最有用的地方，不只是“做了脱敏”，而是把字段状态也保留下来：

• present 表示上游确实提供了内容；
• empty 表示字段存在，但按协议语义为空；
• missing 表示源数据没有提供；
• 摘要值表示原始内容仍可在本地复核，但不会完整进入模型上下文。

如果只把值替换成星号，模型很容易把“已脱敏”误判成“没有证据”。显式状态让它能够区分 GET 请求本来没有 Body、上游采集缺失，以及网关为了数据最小化没有展示明文。

3. 五个产品 Agent 共用框架，但不共用判断模板

网关根据产品选择 WAF、HIPS、NDR、RASP 或 SIEM Agent。它们遵守同一份结构化输出契约，但关注点不同：

• WAF Agent 更关注请求特征、规则命中与误报条件；
• RASP Agent 关注输入是否抵达危险调用点、调用栈、Hook 数据和 RASP 动作；
• HIPS Agent 关注进程、文件、账号和主机行为；
• NDR Agent 关注连接、方向、频率和网络时间线；
• SIEM Agent 负责多来源 Case 的融合与证据缺口。

模型输出包括分类、置信度、证据、缺失证据、研判说明和分阶段响应建议。Case 层再按资产、规则和时间窗做聚合，避免同一活动的七条告警生成七套审批。跨产品关联目前使用受限时间窗与实体匹配，目的是提供调查线索，不会把“时间接近”自动升级成同一攻击链。

4. Validator 不相信模型，包括“自我检查后的模型”

Agent 返回结果后，会进入独立的确定性 Validator。它不调用 LLM，而是逐项检查：

• 分类与置信度是否满足结构化契约；
• 高风险结论是否有不可变证据引用；
• Agent 返回的证据是否与归一化事实一致；
• 输出是否泄露敏感字段或疑似凭证；
• 外部日志中是否含提示注入文本；
• 推荐动作是否被正确标记为只读或需要审批；
• 当前 Skill 是否显式禁止生产执行能力。

最终状态只有 passed、review 和 blocked。其中 passed 的含义是“这次分析输出通过了证据与权限门禁”，不是“告警已被证明为攻击”，更不是“模型判断一定正确”。这一区分在工作台上必须清楚，否则绿色状态很容易被误读成安全结论。

对于提示注入，系统保留原始 Validator 结果。只有当唯一问题是外部日志中的注入文本、其他确定性检查全部通过时，分析师才能写明复核依据并把它继续送往审批；记忆自动写入仍被抑制。这样既不会因为日志里出现一句“忽略之前指令”就丢掉整条安全事件，也不会让它直接污染后续流程。

5. 记忆不是更长的 Prompt，而是一类治理对象

系统把记忆分为 Case 短期记忆、产品长期记忆、资产画像、组织知识和只读证据引用。新的误报经验不会因为模型说“以后忽略”就立即生效。它需要具备可追溯来源、明确范围、人工批准、过期时间和敏感信息检查，并把晋升、拒绝、隔离、恢复等动作写入独立事件流。

记忆匹配同时考虑结构化字段、语义相似度和检索键。更关键的是，它有否决条件：当前事件如果命中危险运行时调用链，历史误报记忆不能自动把恶意信号压低。线上配置目前仍关闭自动应用和自动注入模型，只保留候选评估与治理界面。这是一种有意的保守状态，因为在没有稳定 Golden Set 之前，“记得更多”不一定比“犯错更慢”更重要。

6. Response Agent 只负责调查，不拥有生产执行权

Response Agent 把一次性建议扩展为可暂停、恢复和审计的调查会话。模型可以在固定白名单中选择下一项只读工具，控制器负责锁定 Case 范围、规范化参数、限制轮次和工具预算，并持久化步骤、观察、结果哈希和证据引用。

它能读取 Case 快照、证据清单、原始告警分块、时间线、受治理记忆和响应状态，也会检查 Web 请求、运行时、端点进程、文件完整性、网络边界、身份认证、持久化、云与容器等取证覆盖。对于入选的原始证据，控制器要求从字节偏移 0 连续读取到末尾，并复算完整哈希；跳读、断档、来源变化或摘要不一致都不能通过报告门禁。

模型不能提交 SQL、表名、数据库路径、Shell、任意 URL 或设备凭据。它可以生成带成功条件和回滚条件的候选方案，但破坏性动作会统一升级为 approve_required。调查完成并不等于执行开始。

代码中已经实现了 Response Automation、Playbook、执行核验和回滚状态机，当前线上策略仍为关闭，且没有配置生产 Connector。也就是说，系统现在能展示一条完整的治理路径，但不会因为有人在页面上批准了建议就真的去封禁地址或隔离主机。这不是功能缺失的包装，而是当前试点阶段的安全边界。

一个 RASP Case 如何被处理

当前数据中有一条内存马相关的 RASP Case，很适合说明这套边界为什么必要。

请求是一次指向测试应用内存马接口的 GET。RASP 规则 cloudrasp_memShell_105 命中，调用栈经过 Spring MVC 的 MappingRegistry.register、registerMapping，再进入测试代码中的 HandlerMethodShell.addShell。从运行时可达性看，这比 WAF 仅匹配 URL 强得多：它证明注册逻辑确实走到了受监控的调用链。

但证据同时存在几个限制：RASP 动作为 log，不是阻断；hook_data 为空；没有主机侧类加载、驻留或后续执行证据；路径与类名又明显带有靶场特征，而系统没有拿到本次测试的授权记录。

Agent 最终给出 suspicious、置信度 0.5，结论是“需人工复核”。建议先核对授权、Tomcat 与业务日志、JVM 中的动态映射，再决定是否临时白名单或隔离来源。观察和取证项保持只读；涉及白名单、封禁和清除内存马的建议被标记为 approve_required。Validator 的所有确定性检查通过。

这个结果并不戏剧化，却比“检测到内存马攻击成功”更有价值。系统确认了危险调用链已经触达，同时诚实保留了从“规则命中”到“主机失陷”之间缺少的证据。安全分析最怕的不是答案不够响亮，而是把不确定性藏起来。

2026 年 8 月 7 日运行快照

以下数字来自写作时的线上健康接口与 Case 数据库，只用于说明当前联调状态，不应当被解释为检出率或独立攻击次数。

运行环境为 Ubuntu 24.04，Gateway 数据库 Schema 为 v22。Caddy、Gateway、Vector、持久队列和 Response Agent Worker 均通过健康检查，模型调用经配置的企业 Gateway 完成，当前熔断器处于关闭状态。这里的“健康”描述的是组件和队列状态，不代表未来容量与高可用要求已经完成。

我认为最值得保留的几个设计

回看整个研发过程，真正有复用价值的并不是某个 Prompt，而是以下几个工程选择。

第一，证据连续性优先于上下文长度。 完整原文、规范化证据、模型运行、验证、审批和审计分别保存并通过 ID 关联。模型上下文可以截断，事实身份不能含糊。

第二，让失败显式进入状态机。 模型不可达、永久配置错误、队列容量不足和人工待复核是不同问题，应该分别进入 deferred、DLQ、回压和 review，而不是统一显示“处理失败”。

第三，把概率能力包在确定性控制面里。 模型负责它擅长的语义归纳、关联假设与报告表达；证据一致性、敏感输出、权限、审批和执行边界由代码决定。

第四，记忆必须可撤销。 经验有来源、范围、信任级别、批准人和过期时间，高危证据还能否决错误记忆。这比简单向量检索慢一些，但更接近安全运营对白名单和例外规则的真实要求。

第五，调查 Agent 不等于自主处置 Agent。 只读工具同样可以完成很深的调查。先把 Case 范围、原始证据和报告质量做好，再讨论开放执行权限，比从一开始给模型接上 SOAR 更稳妥。

这些取舍也与 NIST AI RMF 的生成式 AI Profile强调的测量、治理和全生命周期风险管理相吻合；响应流程本身则参考了 NIST SP 800-61 Rev. 3将事件响应融入 CSF 2.0 风险管理活动的思路。标准没有替我们设计产品，但提供了一个很实用的校验问题：系统是否只展示了模型能力，还是也能说明它如何被管理。

还没有完成的生产化工作

当前系统适合受控试点，不应该因为功能链路完整就跳过基础设施建设。

数据面仍是单 Gateway、单 Vector 和 SQLite。生产化需要把 Case 与治理状态迁移到 PostgreSQL，把告警流交给 Kafka、Redpanda 或 RabbitMQ，把大体积原始证据放入对象存储，并将接入层和分析 Worker 拆开扩容。

Collector 还需要双实例、来源网络白名单、mTLS Relay、发送端确认与故障演练。RASP 已以 TCP 为正式链路，迁移兼容的 UDP 入口最终应当移除。身份侧则需要接入企业 SSO/IAM、Secret 管理、证书生命周期和职责分离审计，而不是长期依赖独立 Token。

模型质量也不能只用“真实 Case 跑通”来证明。下一阶段需要基于脱敏现场样本建立私有 Golden Set，覆盖真实攻击、误报、证据不足、提示注入和跨产品关联，再持续测量准确性、证据引用质量、LLM P95、最老等待时间、失败类型、模型与规则版本漂移。

最后才是执行闭环：把批准结果对接工单和 SOAR，保留双人审批、最小权限、TTL、成功条件、执行回写和回滚。只有当这些控制能被演练和审计时，自动响应才是能力；在那之前，它只是额外风险。

结语

做完这一阶段，我对 Defensive AI Agent 的定位反而更克制了。AI 的价值不是替分析师按下最终按钮，而是把分散证据整理成一个可复核的 Case，把隐含的不确定性写出来，把重复调查变成有状态、可恢复的工作流，并让每个建议都带着来源和边界到达审批人面前。

当系统能够回答“为什么这样判断、还缺什么、谁批准、失败后在哪里、能否回滚”时，模型才真正进入了安全运营。否则，无论回答多流畅，它仍然只是另一个需要被研判的信号源。

参考资料

• NIST IR 8596 (Initial Preliminary Draft): Cybersecurity Framework Profile for Artificial Intelligence
• NIST AI 600-1: Artificial Intelligence Risk Management Framework, Generative Artificial Intelligence Profile
• NIST SP 800-61 Rev. 3: Incident Response Recommendations and Considerations for Cybersecurity Risk Management
• OWASP Top 10 for Agentic Applications for 2026
• OWASP LLM06:2025 Excessive Agency