大模型安全学习专题（4）：供应链风险——LLM API 调用链的全局可观测性

https://github.com/heidsoft/heidsoft-nids

heidsoft-nids 是一个轻量级、高性能的网络入侵检测系统（NIDS），核心由 C 语言编写，主打跨平台（支持 macOS、Linux），兼顾实时性、扩展性和易用性，适用于中小型网络环境的入侵检测与安全监控。

核心定位

以轻量级设计实现企业级 NIDS 核心能力，无需复杂部署，可快速落地；同时通过模块化设计支持规则扩展、威胁情报集成、机器学习异常检测，平衡性能与检测能力。

前言

在前三篇文章中，我们讨论了 LLM 安全的技术层面——Prompt Injection 的检测、TCP 分包问题、绕过与对抗的工程方法。这些都是"点"上的问题，是单个请求或单次攻击的检测技术。

但 LLM 安全还有另一个维度的问题，它不是"点"，而是"面"——这就是供应链安全。

供应链安全的本质是：你依赖的外部组件越多，你的攻击面就越大。

在 LLM 领域，这个道理同样适用。当你的企业把 LLM 接进业务流程时，你实际上依赖了一条长长的供应链：LLM 模型、API 服务商、提示词工程、工具链框架、RAG 知识库。任何一环被攻破，都可能危及整个系统。

这篇文章，我们从"全局可观测性"的视角，系统性地讨论供应链风险的网络侧检测。

第一部分：重新理解 LLM 供应链的边界

1.1 传统供应链 vs LLM 供应链

在讨论 LLM 供应链之前，我们需要先理解传统供应链安全在说什么。

传统软件供应链安全关注的是软件开发、构建、分发过程中的风险：依赖库被投毒、CI/CD 环节被篡改、分发渠道被植入后门。这套体系的核心特征是发生在软件交付之前——在软件真正运行之前，威胁就已经被植入了。

LLM 供应链则完全不同。LLM 的"依赖"不再是静态的代码库，而是动态的数据流和模型本身：

模型本身是供应商托管的。你使用的 GPT-4、Claude、Llama 等模型，权重托管在 OpenAI、Anthropic、Meta 等公司的服务器上。你无法审计这些模型的权重，无法确定它们是否被篡改，无法知道它们的训练数据是否包含恶意内容。

API 服务商是你的数据处理器。当你调用 ChatGPT API 时，你的 prompt 数据会经过 OpenAI 的服务器。服务商的基础设施安全、数据保留策略、合规认证，都直接影响你的数据安全。

提示词工程是你的"输入供应链"。System Prompt、few-shot examples、RAG 知识库……这些是你喂给 LLM 的原材料。一旦这些原材料被污染或泄露，LLM 的输出就会受到影响。

工具链框架是你的能力延伸。LangChain、LlamaIndex、AutoGen……这些框架帮你快速构建 LLM 应用，但它们也可能成为攻击向量。

外部数据源是你的知识基底。RAG 系统依赖的内部文档、向量数据库，一旦被攻击者利用，可能成为数据泄露的源头。

因此，LLM 供应链是一个运行时与数据流混合的复杂系统，与传统软件供应链有本质不同。

1.2 LLM 供应链风险的分类框架

从网络侧可观测性的角度，我们可以把 LLM 供应链风险分为四个层次：

第一层：身份层风险

这一层的核心风险是凭证泄露和身份伪装。API Key 被盗用、Token 被外带、攻击者冒用合法身份访问 LLM 服务。这些风险的共同特征是：攻击者伪装成合法用户出现。

第二层：数据层风险

这一层的核心风险是数据在 LLM 处理过程中的意外暴露。敏感信息被发送到 LLM 服务商、LLM 响应中包含不应外带的数据、知识库内容被诱导外泄。传统 DLP 在这里面临新的挑战：因为 LLM 本身就是一个合法的数据处理器。

第三层：调用链层风险

这一层的核心风险是 API 调用模式异常。短时间高频调用、异常时间段的活跃行为、跨境调用、单一来源的多账号调用……这些都可能是攻击的信号。

第四层：模型输出层风险

这一层的核心风险是 LLM 输出的内容安全。恶意代码生成、钓鱼内容输出、DGA 类域名……当 LLM 被用于生成恶意内容时，它就成了攻击者的工具。

在这四层中，身份层和数据层是网络侧最容易直接观测到的，也是检测系统能够最高效介入的地方。

第二部分：身份层风险——凭证泄露与 Token 外带

2.1 为什么 API Key 泄露是网络安全问题

很多团队把 API Key 泄露当作"代码审计问题"——是开发者在代码里不小心把 Key 提交到了 GitHub，是代码审查没做好。但实际上，API Key 泄露在网络侧有非常明显的特征。

让我从攻击者的视角描述一下 Key 泄露后的典型攻击场景：

攻击者拿到了你的 OpenAI API Key。他的第一步不是立刻大规模使用——那样太明显了。他的第一步是探测。他会用这个 Key 少量调用几次 API，确认 Key 是否还有效、账户是否还有配额、调用是否有频率限制。

但这个探测行为，在网络侧是清晰可见的：

探测行为特征

正常的 LLM API 调用，通常来自你注册的网关 IP，目的地址是你指定的 API 服务商域名。但攻击者的探测行为会有异常：

• • 调用源 IP 不对。如果攻击者从自己的服务器发起调用，这个 IP 通常不在你的白名单内。
• • 调用时机不对。大规模探测通常发生在深夜或凌晨——正常业务不会在这个时段有高活跃度。
• • 调用模式不对。正常用户调用 API 通常有自然的间隔和会话特征，攻击者的自动化工具有明显的机械感。

大规模利用行为

确认 Key 有效后，攻击者会开始大规模利用。这个阶段的行为特征更加明显：

• • 调用频率突增。原本一天调用 1000 次，突然变成每小时 10000 次。
• • 流量方向异常。原本只消耗配额，现在开始把 Key 用于批量处理、自动化任务。
• • 配额快速耗尽。账户余额以异常速度下降。

如果在任何一个阶段能在网络侧检测到这些异常，就能及时发现 Key 泄露事件，而不是等到配额被耗尽才发现。

2.2 API Key 泄露的网络侧检测方法

Key 出现位置的检测

API Key 出现在请求中是正常的——这是它被使用的方式。但 Key 出现在异常位置则是可疑的：

• • Key 出现在 GET 请求的 URL 参数中。正常的 API 调用通常用 POST body 传输 Key，URL 参数中的 Key 可能是泄露到公开场合的信号。
• • Key 出现在非加密流量中。HTTPS 流量里的 Key 被截获的概率很低，但 HTTP 流量里的 Key 则危险得多。
• • Key 出现在日志或监控流量中。如果监控系统捕获了 API 流量，Key 可能被一并记录。

Key 目的地异常的检测

Key 出现在请求中是正常的，出现在异常目的地才是问题。这里的"异常"需要结合上下文判断：

• • 调用了未知的 API 端点。攻击者可能不是在用你的 Key 调用官方 API，而是调用了钓鱼服务。
• • 目的端口不是标准的 443。正常 API 调用走 HTTPS 端口，异常端口可能是攻击者搭建的接收服务。

Token Pumping 的检测

Token Pumping（令牌泵送）是 Key 泄露后最典型的滥用模式：攻击者用盗来的 Key 快速消耗配额，在数分钟到数小时内把账户余额或额度用尽。

从网络侧检测 Token Pumping 的关键是追踪时间窗口内的调用频率：

如果一个 API Key 在过去 5 分钟内发起了数百次调用，而历史平均每小时的调用次数只有几十次，这就是明显的异常。

更精确的检测需要建立基线行为模型。每个 API Key 都有其正常的调用模式：调用频率、时段分布、平均每次调用的 token 消耗量。当实际行为偏离基线超过一定阈值时，应该触发告警。

2.3 内部威胁的特殊挑战

API Key 泄露不一定是外部攻击者造成的，也可能是内部威胁。

内部威胁的独特之处在于：攻击者使用的是真实的合法身份，行为特征与正常用户高度相似。

一个内部威胁的典型场景是这样的：

某公司员工想要把积累的内部知识打包带走。他不会像外部攻击者那样大规模快速调用——那样太明显了。他会伪装成正常使用：每天下班后调用几次 API，每次只请求少量数据，看起来跟正常的技术研究没什么区别。

但累积起来，这个员工在一个月内就把公司积累的核心知识库内容全部外带了。

这种内部威胁，单从单次调用无法检测，需要长期的基线偏差分析才能发现。

第三部分：数据层风险——敏感数据外带与知识库泄露

3.1 LLM 数据外带的独特挑战

传统 DLP（数据泄露防护）针对的是"数据从内网到外网"的场景，规则相对明确：数据库到外部 FTP、文件到网盘、邮件到外部域……这些场景的共同特征是：数据不应该出现在那个目的地。

LLM 数据外带的挑战在于：LLM 本身就是一个合法的数据处理器。

员工向 ChatGPT 发送内部代码讨论技术问题，向 Claude 咨询业务决策建议——这些是正常的工作场景。DLP 不能简单地把"内网到 api.openai.com" 的流量阻断，那样业务就彻底没法开展了。

这意味着 LLM 数据外带的检测不能靠简单的目的地规则，而需要更细粒度的上下文判断。

3.2 数据分类与风险分级

在网络侧，我们能做的是对流量进行分类和分级评估：

公开数据（Level 1）

不包含任何敏感信息的数据，可以自由地与外部 LLM 服务交互。例如，准备公开的博客文章、技术文档的草稿。

内部通用数据（Level 2）

公司内部通用的代码、文档、架构图等。这些数据外带不会直接造成重大损失，但应该被记录和审计，便于事后追溯。

敏感数据（Level 3）

用户个人信息、财务数据、业务指标等。这些数据外带可能违反合规要求（如 GDPR、个人信息保护法），需要告警并启动调查。

机密数据（Level 4）

核心商业机密、员工身份凭证、数据库连接字符串、私钥等。一旦外带可能造成严重后果，需要立即阻断。

网络侧的检测逻辑需要结合数据类型和目的地两个维度综合判断。例如：

• • Level 3 数据发往已知的 LLM 服务商 → 记录审计
• • Level 3 数据发往未知目的地 → 告警
• • Level 4 数据发往任何外部目的地 → 立即阻断

3.3 知识库外带的检测

RAG（检索增强生成）是企业 LLM 应用的主流架构：用户提问 → 系统检索内部知识库 → 把检索结果注入 prompt → 调用 LLM → 返回答案。

知识库外带的风险在于：攻击者可能通过精心构造的问题，诱导 RAG 系统检索到敏感的内部文档。

一个典型的攻击场景：

1. 1. 攻击者（可能是外部入侵者，也可能是内部威胁）开始向 RAG 系统提问
2. 2. 问题看似正常，但实际上是在系统性地探测知识库的不同部分
3. 3. 每一次回答都可能包含一小段知识库内容
4. 4. 攻击者通过多轮对话，逐步拼凑出完整的知识图谱

从网络侧检测知识库外带的方法是：在 LLM 响应中寻找知识库特征。

知识库的特征可以是：

• • 内部域名（如 internal.company.com）
• • 内网 IP 段（如 10.0.x.x、192.168.x.x）
• • 机密标记（如 CONFIDENTIAL、INTERNAL USE ONLY）
• • 内部编号格式（如 employee-id:xxx、project-code:xxx）

当 LLM 的响应中包含这些特征时，应该触发告警——模型可能正在"不经意"地透露内部知识。

3.4 数据外带的时机与上下文

数据外带检测的另一个维度是时机。

正常的工作行为有明显的时序特征：

• • 工作时间（9:00-18:00）的活跃度最高
• • 周末和节假日的活跃度显著下降
• • 重大时间节点（如季度末、年末）可能有异常的数据处理需求

当数据外带行为发生在异常时段时，可信度会显著提升。例如：

• • 凌晨 3 点突然有大量 API 调用
• • 周末突然开始处理平时只在工作时间访问的敏感数据
• • 离职员工在离开前的最后几天异常活跃

结合时序特征的数据外带检测，能够大幅降低误报率。

第四部分：调用链层风险——全局视图的必要性

4.1 为什么单次请求检测不够

前三篇文章讨论的主要是"单次请求"的检测——Prompt Injection、编码绕过、跨包分片……这些威胁可以通过分析单个 HTTP 请求来检测。

但调用链层的风险有一个根本特征：异常不在单次请求里，在调用模式里。

举几个例子：

地理异常

某个 LLM 账号，平时所有的 API 调用都来自美国的 IP 地址。突然有一天，出现了大量来自东南亚的 API 调用。这个账号可能是被攻击者拿到了。

但如果你只看单次请求，每一条请求都是"合法"的——有有效的 API Key、有正常的请求格式、有预期的响应内容。只有聚合起来看，才能发现地理分布的异常。

服务商切换

某个员工平时只用 OpenAI 的 API。突然他开始频繁调用 Anthropic 的 API，同时还在用 OpenAI。这种多服务商同时使用的模式可能意味着：

• • 员工在测试不同的 LLM 服务
• • 攻击者利用该账号访问了多个服务
• • 企业在进行 LLM 服务的迁移或对比

时段异常

正常的技术团队有规律的工作时间。但一个异常账号可能在凌晨 3 点还保持着活跃的 API 调用——这个时段通常是系统维护和备份的时间，不应该有开发人员在用 LLM。

调用量突增

环比过去 30 天的数据，某账号的平均 API 调用量是每天 1000 次。今天突然变成了每小时 10000 次。这个数字在单次请求层面看不出异常，但在聚合分析中清晰可见。

4.2 全局视图的构建

要实现调用链层的异常检测，首先需要构建全局视图——把分散在网络各处的流量数据汇聚起来，形成完整的调用链路图。

全局视图需要包含：

源维度的聚合

• • 按源 IP 聚合：同一 IP 发起的所有 API 调用
• • 按账号聚合：同一 API Key 关联的所有调用
• • 按用户聚合：经过身份认证后，同一用户的所有调用行为

时间维度的聚合

• • 分钟级统计：捕捉短期的突增
• • 小时级统计：捕捉工作时段模式
• • 日级统计：捕捉长期趋势和周期性

目的地维度的聚合

• • 按 API 服务商聚合：OpenAI、Anthropic、Google 等
• • 按地理分布聚合：调用来源的国家/地区分布
• • 按端点聚合：不同的 API 路径和功能

4.3 异常模式的识别

有了全局视图之后，需要识别哪些模式是异常的。

基线偏差检测

这是最基本的异常检测方法：建立正常行为的基线，当实际行为偏离基线超过阈值时触发告警。

例如，如果某个账号过去 30 天的日均 API 调用量是 1000 次，标准差是 200 次，那么当某一天的调用量超过 1500 次（基线加 2.5 倍标准差）时，应该被视为异常。

周期性模式检测

正常的技术团队有规律的工作模式。例如：

• • 工作日活跃，周末沉寂
• • 每天的活跃高峰期在上午 10 点到 11 点、下午 3 点到 4 点
• • 节假日前后可能有特殊的调用模式

当实际行为违反这些周期性规律时，应该被视为异常。

关联异常检测

有些异常不能从单一维度看出来，需要关联多个维度：

• • 账号 A 平时只用 OpenAI，今天突然开始大量调用 Anthropic，同时出现了大量异常时段的调用
• • 员工 B 平时只用公司 VPN 下的 IP 访问 API，今天突然从家庭网络 IP 访问，同时调用量激增

这些关联异常比单一维度的异常更能表明真实的攻击。

第五部分：CI/CD 环境中的特殊风险

5.1 CI 环境的脆弱性

CI/CD 环境是 LLM 供应链中最脆弱的一环，原因在于它的安全模型与传统服务器有根本不同。

CI 通常有高权限 Token

GitHub Actions、GitLab CI、Jenkins 的 Token 通常关联了读仓库、写 artifact、部署到生产环境等权限。如果这些 Token 被泄露或滥用，后果比普通账号被盗严重得多。

CI 的网络通常是"出站全通"的

为了能够拉取各种依赖，CI 节点通常被配置为允许访问任意 HTTPS 目的地。这种开放的网络策略为攻击者提供了便利——他们的 C2 服务器可以是任何一个 HTTPS 域名。

CI 的日志可能被持久化

CI 系统的日志通常会被持久化存储，其中可能包含 API 调用的输入和输出。如果日志系统被攻破，攻击者可以直接获取敏感数据。

CI 的调用源 IP 是云服务商 IP

GitHub Actions 的 runner 托管在微软的 Azure 云上，GitLab CI 的 runner 可能托管在任何云服务商。这意味着你无法通过"IP 是否属于内部网络"来判断调用是否合法。

5.2 CI 环境的安全风险场景

场景一：Token 盗用后的大规模调用

攻击者通过某种方式获取了 GitHub Actions 的 Token。这个 Token 有权限读取代码仓库。攻击者利用这个 Token，在 CI workflow 中植入恶意代码，让 CI 节点在构建过程中调用 LLM API，消耗企业的 API 配额，同时可能收集构建过程中接触到的敏感信息。

场景二：异常目的地的 LLM 调用

正常的 CI 构建可能需要调用 LLM 来做代码分析、文档生成等任务。但这些调用的目的地应该是已知的 LLM 服务商。

如果 CI 节点开始向未知的外部地址发送 API 请求——特别是那些与 LLM 无关的地址——应该立即触发告警。

场景三：构建过程中的数据外带

CI 构建过程中会拉取代码仓库、执行测试脚本、生成构建产物。这个过程中可能接触到大量的内部信息。

如果 CI 过程开始向外部发送异常大量的数据——特别是包含代码、文档等可能包含敏感信息的内容——应该被视为严重的安全事件。

5.3 CI 环境检测的特殊考虑

针对 CI 环境的检测需要考虑以下特殊因素：

白名单机制

CI 节点访问的 LLM 服务应该是白名单化的。只允许调用经过审批的 LLM 服务商，不允许调用其他任何外部服务。

频率基线

CI 的 LLM 调用应该有可预测的频率模式。构建过程中的调用通常是批量进行的，而不是持续不断的。如果 CI 节点开始出现持续的高频调用，可能是被植入恶意代码的信号。

时间窗口关联

正常的 CI 构建是按需触发的，不会在深夜持续运行。如果 CI 系统在非工作时间持续活跃，应该触发告警。

第六部分：模型输出层风险——响应体的安全检测

6.1 为什么需要检测响应体

在前几讲中，我们主要讨论了请求体的检测——Prompt Injection、敏感数据输入等。但 LLM 的响应体同样存在安全风险。

一个简单的逻辑：攻击者可能利用 LLM 生成恶意内容。

这个恶意内容可能是：

• • 钓鱼邮件的正文
• • 恶意代码的片段
• • 欺诈文档的内容
• • DGA（Domain Generation Algorithm）类的域名

如果 LLM 被用于生成这些内容，攻击者就可以利用你的企业信用来实施下游攻击。从法律和声誉角度，这可能给你的企业带来严重后果。

6.2 恶意代码生成的检测

LLM 被用于生成恶意代码是一个真实存在的风险。研究显示，LLM 能够生成功能性的恶意软件、钓鱼页面、甚至漏洞利用代码。

在网络侧检测恶意代码生成的思路是：在 LLM 响应中寻找恶意代码的模式。

常见的恶意代码模式包括：

命令执行类

• • 反弹 Shell 相关的代码片段
• • 系统命令执行调用
• • 进程创建和网络连接代码

凭证窃取类

• • 键盘记录器代码
• • Cookie 窃取脚本
• • 密码提取工具

敏感信息外带类

• • AWS Access Key 格式的字符串
• • 私钥文件的特征内容
• • 数据库连接字符串模式

这些模式的存在并不意味着一定构成攻击——LLM 可能只是在正常地回答编程问题。但它们的出现应该被记录和审计，在特定上下文下触发告警。

6.3 钓鱼内容的检测

钓鱼攻击是网络犯罪最常见的手段之一。当 LLM 被用于生成钓鱼内容时，攻击者可以：

• • 生成看起来像正规公司的邮件正文
• • 制造逼真的登录页面内容
• • 编写有说服力的欺诈文档

检测 LLM 生成的钓鱼内容在网络侧是可行的，因为钓鱼内容通常有一些共同的特征模式：

• • 紧急感营造（"您的账户将在 24 小时内被关闭"）
• • 权威伪装（"来自安全团队的紧急通知"）
• • 异常链接模式（与声称的机构不符的 URLs）

当 LLM 响应中包含这些模式时，应该触发告警。

6.4 DGA 类域名的检测

DGA（Domain Generation Algorithm）是攻击者常用的一种技术：恶意软件定期生成大量伪随机域名，试图与 C2 服务器建立连接。这些域名的特征是：

• • 长度通常超过正常域名
• • 包含大量随机字母和数字
• • 不像正常的单词组合
• • 通常由恶意软件在受害主机上生成，而非来自 LLM

但如果 LLM 被诱导生成类似的域名字符串——即使是无意的——这可能表明系统存在被攻击的风险。

第七部分：供应链检测的系统整合

7.1 与现有安全体系的联动

供应链检测不是孤立的，它需要与现有的安全体系深度整合才能发挥最大价值。

与 SIEM/SOC 的联动

供应链告警应该能够进入现有的 SOC 流程：

• • 告警格式标准化，与 SIEM 的解析规则兼容
• • 告警包含足够的上下文信息（源 IP、目的、时间、置信度）
• • 告警自动路由到相应的处理队列
• • 处理结果自动反馈到检测系统，形成闭环

与防火墙/IPS 的联动

高置信的供应链告警应该能够触发自动响应：

• • API Key 泄露到非标准端口 → 立即阻断并封禁源 IP
• • CI 环境访问非白名单 LLM 服务 → 临时隔离 CI 节点
• • 大规模异常调用 → 自动限速并通知安全团队

但自动响应需要谨慎配置。误触发自动响应的代价可能是业务中断，必须确保告警的置信度足够高。

与 CMDB/资产系统的联动

供应链检测的价值在于知道"正常是什么"。这需要与 CMDB（配置管理数据库）整合：

• • 知道哪些 IP 是数据库服务器、哪些是开发人员工作站、哪些是 CI 节点
• • 知道哪些账号对应哪些业务系统
• • 知道哪些 API Key 属于哪个部门或项目

有了这些上下文，同样的检测信号可以有不同的风险评估结果。

7.2 告警级别的设计

供应链告警的级别设计需要考虑：

CRITICAL 级别

适用于高置信、必须立即处理的事件：

• • API Key 泄露到非标准端口
• • CI 环境访问非白名单 LLM 服务
• • 私钥模式出现在网络流量中

HIGH 级别

适用于有明显异常、应该快速响应的事件：

• • Token Pumping 检测
• • API 调用频率异常突增
• • 知识库内容疑似外带

MEDIUM 级别

适用于可疑但需要进一步确认的事件：

• • 多 LLM 服务商同时使用
• • 短时间内的流量突增
• • DGA 类域名生成

LOW 级别

适用于值得记录但不触发即时告警的事件：

• • 正常的服务商切换
• • 可解释的频率波动
• • 新出现的调用模式（需要建立基线）

7.3 持续运营的考量

供应链检测不是"一次建设、永久有效"的。需要持续运营和优化：

规则迭代

新出现的攻击手法需要新的检测规则。应该建立定期的规则审查和更新机制。

基线更新

业务在变化，基线也需要持续更新。例如，新的 LLM 应用上线后，原有的基线可能需要调整。

误报分析

定期分析误报案例，优化检测逻辑，减少噪声对运营团队的干扰。

第八部分：当前的检测边界与未来方向

8.1 当前的技术边界

供应链检测在网络侧面临一些根本性的限制：

加密流量的内容不可见

即使部署了 TLS 解密，LLM 响应体的部分内容可能仍然不可见。这限制了对模型输出层风险的检测能力。

语义级攻击难以检测

"请用自然语言描述如何绕过安全检测"这类请求，从字面上看是完全正常的。但它可能导致 LLM 输出敏感信息。这种语义级的攻击，在网络侧很难检测。

上下文缺失

同样的行为，在不同的业务上下文中可能有完全不同的含义。员工在下班后调用 LLM，可能是加班，也可能是数据外带。没有应用层上下文，网络侧的检测很难做出准确判断。

8.2 未来值得关注的技术方向

TLS 指纹识别

即使看不到 TLS 流量的内容，JA3/JA4 指纹可以帮助识别 LLM 服务商。这对于发现非预期的服务商调用非常有用。

mTLS 客户端证书

如果 LLM API 使用双向 TLS 认证，客户端证书可以成为身份验证的一环。异常的证书使用可能表明凭证被盗。

AI Firewall 的联动

在 LLM 网关层部署专门的内容检测，让 NIDS 专注于流量层面的异常检测，是更合理的分工。

威胁情报的整合

将公开的泄露 Key 情报、恶意域名情报等整合到检测系统中，可以提升检测的准确性和时效性。

结语

供应链安全不是"加几个规则"就能解决的事。

它需要多层次的检测——身份层、数据层、调用链层、输出层，每一层都有其独特的攻击向量和检测方法。

它需要上下文感知——知道正常是什么，才能判断什么是异常。这需要与 CMDB、资产系统、身份系统的深度整合。

它需要全局视图——单次请求看起来正常，聚合起来才看得到异常。这需要建立完善的流量汇聚和分析能力。

它需要与现有安全体系联动——NIDS 不是孤岛，只有与 SOC、SIEM、防火墙形成协同，才能真正实现可运营的安全能力。

这也是 NIDS 在 LLM 时代的独特价值所在：它站在网络层，看到的是全局流量，不依赖应用层的埋点，也不容易被应用层绕过。

当 LLM 安全从"应用安全"变成"供应链安全"，网络侧的可观测性就变得不可或缺。