一种系统级提示注入防护方法：在LLM代理中分离指令通道与数据通道 [P]

Reddit r/MachineLearning 论文
prompt-injection llm-agents system-level safety middleware token-based-authorization

摘要

本文提出Sentinel Gateway中间件层，通过强制分离可信指令通道与不可信数据通道来缓解LLM代理中的提示注入攻击，使用签名运行时授权令牌，并提供审计日志记录功能。

提示注入已成为使用工具的LLM系统中最持久的故障模式之一，尤其是在模型与外部数据源交互的代理工作流中。大多数缓解策略侧重于输入过滤或模型对齐，但由于核心问题是结构性的，这些方法难以奏效。我探索了一种系统级缓解策略，通过引入中间件层（Sentinel Gateway）强制执行以下通道的严格分离： - 指令通道：可信的运行时发出的命令 - 数据通道：不可信的外部输入（网页、文件、API） 该系统并非试图对恶意输入进行分类，而是确保： - 所有代理操作都需要一个签名且限定范围的运行时授权令牌，从而有效将观察与执行解耦。 **实现** - FastAPI中间件层用于代理工具调用 - 基于令牌的授权用于执行请求 - Streamlit界面用于检查与调试 - 代理决策及工具使用的审计日志 - 支持多代理集成模式（例如基于Claude的会话） - 本地或Postgres支持的持久层 - 仓库 https://github.com/cmtopbas/Sentinel-Gateway **讨论问题** 我感兴趣的反馈： - 指令/数据分离是否是代理安全故障模式中的有意义的抽象 - 基于令牌的执行门控与其它代理安全或沙箱方法在概念上的比较
查看原文

相似文章

## Prompt injection stopped being a content problem — and most agent stacks haven't caught up 提示注入早已不再是一个“内容层面”的问题——但大多数 Agent 技术栈仍未跟上这一变化。

Reddit r/AI_Agents

文章认为，在智能体（agent）技术栈中，提示注入（prompt injection）已经从一个内容过滤问题，演变为一个来源（provenance）/授权问题：不可信的读取输出可能悄无声息地驱动特权写入工具的参数，也就是所谓的「混淆代理」（confused deputy）问题；因此防御手段必须将授权与用户的原始意图绑定——通过信任标签、签名的意图摘要（signed intent digests）、只读子智能体以及范围受限的授权，而非依赖逐个工具的白名单。