[Paper] LLM 驱动的应用需要系统级威胁监控

发布: 3天前 (2026年2月23日 GMT+8 21:48)

7 分钟阅读

原文: arXiv

Source: arXiv - 2602.19844v1

概述

大型语言模型（LLMs）如今已被嵌入到无数应用的核心逻辑中——从代码助手到自主代理。虽然这释放了强大的新功能，但也带来了传统软件测试根本捕捉不到的可靠性和安全性问题。作者认为，系统级威胁监控——对异常或恶意行为进行持续、运行时检测——是安全大规模部署 LLM‑驱动软件的关键缺失环节。

Threat‑monitoring paradigm shift – 将 LLM 相关的安全风险视为 预期的运行条件，需要实时事件响应，而不是罕见的边缘案例。
Taxonomy of LLM‑specific attack vectors – 识别并归类新出现的威胁（提示注入、模型泄漏、幻觉驱动的利用等），这些威胁仅因 LLM 充当推理引擎而产生。
Design principles for runtime monitoring – 概述一套系统层面的需求（可观测性、上下文感知、来源追踪以及安全失效机制），以适应 LLM 输出的非确定性特性。
Blueprint for an incident‑response loop – 引入基于反馈的工作流，将异常检测与自动化缓解（例如请求限流、模型沙箱或人工介入升级）相结合。
Positioning of monitoring over model‑centric defenses – 主张仅靠护栏和提示级别的清理不足以保障安全；持续监控是部署后安全的关键。

论文采用 系统工程视角 而非经验评估。作者：

调研了现有防御措施（prompt sanitization、fine‑tuning、sandboxing），并指出它们在动态、生产级环境中的盲点。
绘制了 LLM 攻击面，通过分析真实部署（代码生成工具、聊天助理、自治代理）并提取出常见的失效模式。
推导监控需求，通过威胁建模练习，重点关注可观测性（记录模型输入/输出）、上下文（用户意图、系统状态）以及响应延迟。
提出了架构草图，将 Threat Detection Engine（利用统计异常检测、策略检查和轻量级 LLM 审计器）集成到应用栈中，并将警报发送至 Incident Response Orchestrator。

该方法故意保持高层次，以便让需要可操作指导而非深度形式化证明的开发者更易理解。

这些发现共同支持核心论点：有效的系统级监控是可信 LLM 应用的前提条件。

对开发者	对组织
对代码进行仪器化 – 记录提示、模型响应和下游操作，以创建用于实时分析的数据管道。	与现有 SIEM 集成 – 将 LLM 遥测数据输入安全信息与事件管理（SIEM）工具，以利用现有的警报和事件响应工作流。
采用轻量审计器 – 部署次级“看门狗” LLM 或基于规则的引擎，在主要模型输出影响关键资源之前进行审查。	规划平滑降级 – 当监控层标记高风险活动时，设计回退路径（例如切换到基于规则的子系统）。
定义明确的策略 – 确定何为异常行为（例如意外的文件写入、特权 API 调用），并将其编码为可执行规则。	持续改进循环 – 利用检测到的事件对模型进行再训练或微调，更新防护措施，并完善检测启发式规则。

简而言之，本文促使开发者将 LLM 视为 运行时服务，需要与其他关键组件相同的可观测性、日志记录和事件响应支撑结构。

未来的研究方向包括构建用于 LLM 威胁检测的基准套件、在大规模上评估检测算法，以及集成隐私保护遥测以遵守用户数据法规。