每日论文精读 #059：别让LLM直接执行命令——封闭意图词表+护栏代理把注入攻击挡在信任边界外

📌 系列导航：🔥 日报 · 📚 周报 · 📡 技术雷达 · 📄 论文精读 · 📮 情报站

论文信息

一句话总结

论文提出一个"受限动作"双层架构：让LLM安全运营代理只能输出封闭意图词表中的动作（封IP、杀进程等），再由NeMo-Guardrails代理双向过滤提示注入和数据泄露，开箱即用把注入召回率从25.0%拉到94.5%（FPR仅0.1%）。

解决什么问题

安全运营中心（SOC）面临告警洪流与分析师短缺的矛盾，LLM代理被视为自动分诊和响应的答案。但这种部署天然危险，论文归纳了三个一等公民威胁：

1. 输入天然敌对：模型读的日志和告警payload部分来自攻击者本身——HTTP body里的指令、SSH日志里的Base64提示词、告警元数据中的同形字，都可能劫持模型推理。
2. 输出驱动特权动作：一条"封禁IP"建议可能在所有端点执行，幻觉参数或攻击者诱导的选择会变成自我DoS；在OT/关键基础设施场景，错误动作可能断开传感器、跳闸继电器，把运维bug升级为安全事故。
3. 模型本身是机密边界：日志携带凭据、内网IP、连接串，原样转发给托管LLM或回传下游都是数据外泄风险。

核心方法

架构分两个咬合的层：

第一层：动作受限的SIEM/XDR控制平面（源自Wazuh/OSSEC模式）

• 端点代理通过mTLS注册、TLS WebSocket上报事件，manager关联成带MITRE战术标签的事件结构
• SOC分析代理跑有界的ReAct循环（本地14B开源模型、低温度），关键设计是它不输出shell命令，只输出封闭意图词表中的意图：{封IP、杀进程、隔离文件、删文件、禁用用户、模板化自定义脚本}
• “聪明的manager、瘦身的agent"分工：manager把意图翻译成OS特定的参数化模板命令，LLM提供的参数是命令中唯一受攻击者影响的量，必须通过类型级校验（如严格的IPv4/IPv6正则）
• 端点agent再过二进制白名单和shell元字符扫描。三道检查（意图在词表内、参数满足schema、渲染命令通过扫描）全过，命令才离开信任边界

第二层：NeMo-Guardrails LLM代理

• OpenAI兼容端点，SOC分析服务只需把provider指向代理，零代码改动
• 三条rail：输入rail用LLM分类器区分"描述安全事件的日志"与"含攻击者指令的日志”（前者放行后者拦截）；输出rail筛查PII、内网IP、MAC地址、连接串等基础设施数据；话题rail拒绝闲聊保持任务专注
• 论文刻意使用默认rail配置、不针对评测集调优，保证基线的公平性

实验结果

• 注入防御：在自发布的SOC对抗语料上，裸LLM注入召回率25.0%，加上默认配置的NeMo代理后提升至94.5%，FPR仅0.1%
• 红队演练：跨三条MITRE ATT&CK攻击链的实测确认，封闭意图词表+参数校验器在命令越过信任边界之前就拦截了观测到的两种LLM失败模式——目标不精确（target imprecision）和意图漂移（intent drift）
• 延迟画像：rail延迟使inline控制不可行，建议human-in-the-loop或延迟执行模式

深层洞察

这篇论文最重要的思想是纵深防御中"动作收窄"优先于"输入净化"。输入护栏哪怕漏掉5.5%的注入，攻击者能触及的也只是一个被策略引擎限定的动作集合，而非模型的全部能力——即使注入成功，损失也被词表封顶。这把NIST SP 800-82r3和IEC 62443中"自动化响应限定为运维员审批动作"的工业标准，实例化到了LLM驱动回路。它没有试图让模型更聪明或更难被骗，而是让"被骗了也无所谓"成为架构性质。

局限性

• 仅为架构适配验证，尚无真实OT环境的实测部署数据
• rail延迟使实时inline控制出局，只适合人在回路或延迟执行
• 评测的注入语料是自建语料，默认rail虽未与之共调优，但泛化性仍待外部验证
• 网络/身份遥测源（NDR/ITDR）在控制平面上未实际演练

工程实践启示

• 让LLM选意图，别让它写命令：封闭意图词表+模板渲染是agentic系统执行层安全的通用范式，可直接迁移到运维自动化、代码执行等场景
• 参数是唯一攻击面：对模型推导的每个参数做类型级严格校验（正则/schema），是投入产出比最高的防线
• 护栏代理零侵入：用OpenAI兼容代理包住模型调用，业务代码一行不改就能加双向过滤
• 审计留痕：每条命令、LLM理由、执行结果按事件持久化，事后可完整回放责任链
• 限流防洪水：按周期批量上限和按(规则,目标)冷却，防止突发告警下的动作风暴