系统:运行中
← 返回所有攻击
DEFENSE MEDIUM NEW

提示词不是企业智能体的强制执行层

2026 年 7 月的一项研究表明,提示词指令无法可靠地强制执行企业智能体的输出与追踪契约——只有围绕模型的代码级强制执行同时保住了安全性与完整效用。

2026-07-13 // 5 min affects: enterprise-llm-agents, rag-assistants, hosted-llm-apis, agent-frameworks

这是什么?

2026 年 7 月 9 日,一篇题为 “From Prompts to Contracts: Harness Engineering for Auditable Enterprise LLM Agents” 的预印本发布于 arXiv(2607.08028)。它提出了一个几乎贯穿所有企业智能体部署的问题:当一个 LLM 应用最初只是由提示词驱动的原型,随后要带着真实需求上线——来源边界、实体路由、回答契约、可复现的追踪——这些保证中,哪些真正能靠写进提示词来强制执行,哪些必须由围绕模型的代码来执行?

论文的回答毫不含糊。仅存在于提示词指令中的保证会泄漏:违规内容会抵达读者。而同样的保证,一旦迁移到围绕模型的代码级强制执行层,就能守住。这是一项架构层面的发现,而非漏洞利用——但它对任何依赖系统提示词把智能体约束在边界内的团队都有直接的安全后果。

工作原理

作者描述了一个执行框架(harness):确定性行为被从提示词中抽离,移入代码——清单、模式(schema)与验证工件——围绕一个组合边界进行组织,该边界即 LLM 真正生成回答的可替换点。有来源支撑的论断在运行时仍是回答的权威,但关于回答如何被塑造的规则(接地、路由、格式、允许的措辞)从提示词中礼貌的请求,变成了可由机器校验的契约。

他们在五个企业集团(25 家上市公司)的公开数据切片上实例化了该方法,并测试了五项契约:来源接地、实体路由、追踪、输出卫生与推荐性措辞。一个故障注入对照会刻意破坏每项契约,以确认验证器确实会触发,而不是默认放行一切。

核心实验固定模型,仅改变强制执行层

强制执行层                追踪泄漏 / 推荐性措辞 契约
------------------------  ------------------------------------------------
仅提示词指令              违规内容抵达读者
外挂式外部护栏            拦截违规,但过度拒绝(效用 88/120)
代码级执行框架            拦截违规,效用完整(120/120)

无需任何攻击载荷即可说明要点,这里也不复现任何载荷。该发现关乎控制”住”在何处,而非某条巧妙的字符串。

为何重要

两个数字支撑起整篇论文。首先,在模型固定的情况下,仅凭提示词指令会让推荐性措辞与内部追踪泄漏的违规内容抵达读者,而代码级执行框架将其完全拦截。对企业智能体而言,内部追踪泄漏可能暴露推理过程、检索到的上下文或用户本不该看到的系统细节,而被禁止的”推荐”措辞在受监管环境中可能构成真正的合规问题。二者都无法靠往提示词里加文字来修复。

其次,这些契约在模型替换下依然成立:在三个托管模型上,执行框架的检查在全部 270 次组合边界运行中均通过;当模型生成的一侧失败时,失败会被捕获并记录,而非无声地交付。这种稳健性很重要,因为团队会不断更换基础模型,而一个暗中依赖某个模型行为的保证,并不是保证。

过度拒绝这一结果是诚实的反面砝码。外挂式的外部护栏同样拦截了违规,但它把效用拉低到 88/120,而执行框架保住了完整的 120/120——这正是过于宽泛、拒绝过多的过滤器所收取的常见”税负”。只有范围明确、代码级的强制执行,才同时保住了安全性与可用性。

这与业界反复重温的一课高度吻合。微软安全团队在 2026 年 5 月明确指出:LLM 不是安全边界,任何模型能够影响的工具参数都必须被当作受攻击者控制的输入来对待。关于保护智能体免受提示词注入的设计模式文献给出了相同的结构性论证:在模型周围部署确定性控制,而不是要求模型自我监管。

防御

面向部署企业 LLM 智能体团队的具体要点:

  1. **把提示词当作行为塑造,而非强制执行。**任何必须成立的保证——来源接地、无内部追踪泄漏、输出格式、允许的措辞——都属于代码:应放在组合边界的模式与验证器中,而不是系统提示词里的句子。

  2. **在模型输出与用户之间放置一道经过验证的边界。**在放行前,用可由机器校验的契约检查每一条由模型生成的回答,并在违规时以”失败即关闭”方式处理。

  3. **让强制执行独立于模型。**如果更换基础模型会改变某项契约是否成立,那么该契约并未真正被强制执行。在每次模型替换时都重新运行你的契约检查。

  4. **相较宽泛的外挂护栏,优先选择范围明确的代码级检查。**外部过滤器以过度拒绝为代价换取安全。针对特定契约的验证器在拦截违规的同时保住了效用。

  5. **对控制工件进行版本化与归档。**清单、模式、验证器与追踪都应像代码一样进行版本管理,以便审计能够精确重建:为何某条回答被允许抵达读者。

  6. **加入故障注入测试。**在测试中刻意破坏每项契约,确认验证器会将其标记出来。一个你从未见其失败过的护栏,是一个你无法信任的护栏。

状态

项目参考日期备注
执行框架工程预印本arXiv:2607.080282026-07-09代码级契约 vs 仅提示词强制执行
模型替换测试论文2026-07-09270/270 次组合边界运行通过,3 个托管模型
仅提示词强制执行论文2026-07-09追踪泄漏与推荐性措辞抵达读者
执行框架 vs 外部护栏论文2026-07-09执行框架效用完整(120/120);外挂护栏过度拒绝(88/120)
行业背景Microsoft Security2026-05-07”你的 LLM 不是安全边界”

这是一项基于公开财务披露数据切片的单一案例研究,作者已归档参考实现与评估工件——仍有待更广泛的独立复现。但其方向值得现在就吸收内化:随着智能体不断深入受监管的企业工作流,能够存活下来的保证,是那些你能在代码中指认的,而非你请求模型去记住的。

Sources