AI 智能体中的提示注入与上下文安全

# 六周成为 AI 智能体工程师（完整课程）——第二部分

你的智能体在测试中运行完美。

然后有人把一个网页粘贴进去。

智能体读取了该页面，发现了其中隐藏的指令，并开始搜索用户的私人文件。

这不是假设。

这就是真实生产环境中的智能体被攻破的方式。

这是《AI 智能体工程师》系列的第二部分。

第一部分介绍了 LLM 的实际工作原理：词元、推理、温度、幻觉、RAG 和工具。

第二部分深入讲解提示工程与上下文安全——正是这些因素决定了你的智能体在生产环境中究竟是遵循指令，还是被不可信内容劫持。

保存这篇文章。每次构建智能体时你都会回来参考它。

**我们所处阶段的快速回顾**

第一部分奠定了基础。

第二部分在此之上继续深入。

既然智能体已经能够使用工具并执行真实操作，安全模型就彻底改变了。

聊天机器人被欺骗 → 给出错误答案。

智能体被欺骗 → 发送邮件、修改代码、读取私人数据、发起退款、删除某些内容。

问题从"如何阻止模型说错话"转变为"如何设计系统，使得即便模型被操控，它也无法超越用户的权限"。

让我们来构建这样的系统。

## **指令层级**

在讲攻击之前，你需要理解 LLM 是如何处理指令的。

并非所有指令都是平等的。

它们存在优先级顺序：

这意味着：

以下是工程师常犯的关键错误：

他们把指令层级当作安全模型。

它不是。

LLM 本质上是概率性的。层级有帮助，但无法提供保证。

仅凭"系统提示说不"作为唯一的安全控制，就像用注释来保护管理员 API：

而不是真正的授权机制。

**直接提示注入**

攻击者利用正常的用户输入渠道来覆盖你的应用指令。

攻击者试图通过用户输入渠道操控模型。

为什么模型不能直接忽略这些内容？

因为 LLM 是概率性的。

在训练过程中反复出现"忽略之前的指令"，意味着这些词语在模型学习到的模式中具有真实的权重。

防御措施：

授权应当在模型之外进行。

如果模型输出：

你的后端应询问：

然后允许或拒绝。

而不是：由 LLM 决定授权 → 执行。

这与普通的后端工程完全一致。AI 并不废除它。

## **间接提示注入——隐蔽的那种**

这比直接注入更危险。

恶意指令不是用户写的。

它来自智能体检索到的内容。

智能体获取页面后发现：

攻击路径：

用户从未看到恶意指令。他们只是要求做一个摘要。

这就是间接提示注入。

它对智能体如此危险的原因：

智能体会不断消费外部内容。

每一段外部内容都是潜在的攻击面。

想象一个代码智能体正在读取一个 GitHub issue：

第二段是 issue 内容中的文字。

不是经过授权的开发指令。

智能体必须被设计成能够区分两者的差异。

## **来源追踪——这是谁说的？**

这是防御的核心。

假设模型收到：

没有来源追踪，它们只是三个字符串。

有了来源追踪：

现在架构就能正确地对此进行推理。

如何在实践中实现来源追踪：

[外部 - 不可信]

这向模型发出信号，表明此内容是数据，而非命令。

重要说明：

标签有帮助。但它们并非完整的安全边界。

你仍然需要在LLM之外建立确定性控制。

## 混淆代理问题——你的智能体不应成为权限绕过工具

这个概念来自经典安全领域。

设想一下：

不良架构：

Alice没有薪资权限。

但她刚刚借助智能体的凭证读取了薪资数据。

智能体成了混淆代理——它拥有合法权限，却代表一个本不应拥有该权限的人行使了这些权限。

正确架构：

用户的身份和权限贯穿整个系统传播。

智能体永远不会获得任何人都可以通过它调用的"神级"凭证。

这是你本已熟知的后端授权原则。

AI并不改变这一原则。

## 最小权限——只赋予智能体所需的权限

这是最有效的单一控制手段。

如果智能体无法访问敏感数据，即便注入攻击成功，也无法将其泄露出去。

危险能力存在，而LLM是你唯一的关卡。

危险能力从未进入该智能体的可用工具集。

即便模型已被完全攻陷：

这正是工具选择不仅是性能决策，更是安全决策的原因。

读取与写入能力：

只读智能体的爆炸半径要小得多。

始终追问：这个智能体在当前任务中是否真的需要写入权限？

## 工具参数验证——这一步人人都会跳过

模型被允许调用 refund_order。

用户合法拥有订单123。

模型生成：

工具名称：已授权 ✓ 用户拥有该订单：已验证 ✓ 金额：一件49美元商品退款500,000美元

你需要在执行前进行完整验证：

完整验证链：

每一层的存在，都是因为前一层单独存在时并不充分。

## 数据泄露——没人想到的攻击

你的研究智能体可以：

攻击者在它检索的网页中放入如下内容：

攻击链：

问题不仅仅是"模型遵循了一条恶意指令"。

问题在于：系统允许不可信内容在敏感数据与外部出口之间建立了一条通路。

来源与出口——一种思维模型：

如果你的智能体既能访问敏感来源，又能操控强大的外部出口，请仔细思考不可信内容可能将二者连接起来的方式。

解决方法：

按能力拆分智能体。

无法对外写入的读取智能体，无法泄露数据。

无法访问敏感数据的写入智能体，同样无法泄露数据。

将两种能力合并于同一智能体，才是风险的根源。

## 高影响操作需要人工审批

并非每个操作都需要人工审批。那样会让智能体失去意义。

但有些操作确实需要。

针对任何操作需要追问的问题：

不可逆 + 高影响 + 对外 = 必须人工审批。

可逆 + 低影响 + 内部 = 通常可自动执行。

## 纵深防御——没有任何单一层次能解决所有问题

常见错误：将某一项控制措施视为完整的解决方案。

一个健壮的系统将所有层次结合在一起：

没有任何单一层次需要做到完美。

每一层都能捕获前一层遗漏的问题。

这就是纵深防御。

最后补充一点：不要依赖黑名单词组过滤。

你无法可靠地过滤掉"忽略之前的指令"。

攻击者会换一种说法。合法文档也会讨论提示注入。

这种防御是架构性的、确定性的，而非黑名单式的。

## 完整的生产级智能体安全架构

将所有内容整合起来。一个严肃的智能体系统应该是这样的：

注意授权层所处的位置。

在模型提出方案之后，在执行之前。

模型存在于架构之中。它并不拥有这个架构。

## 三个面试必备场景

这些是你在 AI 工程师岗位面试中会遇到的问题类型。

在阅读答案模式之前，先自己思考每一个场景。

场景一 —— 邮件智能体的间接注入攻击

你构建了一个 AI 邮件助手。

用户询问："总结我最新的邮件，并告诉我哪些需要处理。"

其中一封邮件包含如下内容：

问题：

1. 这是哪种类型的攻击？

1. 为什么"告诉模型忽略恶意指令"作为唯一防御手段是不够的？

1. 你会添加哪些架构级控制措施？

答案模式：

场景二 —— SaaS 中的混淆代理问题

你的 SaaS 系统中有 Alice（普通员工）和 Bob（CFO）。

AI 智能体持有可以读取完整薪资表的数据库凭证。

Alice 询问："Bob 的薪资是多少？"

LLM 调用了 get_salary("Bob")，数据库返回了结果。

答案模式：

场景三 —— 危险的工具组合

你的团队认为："每个工具单独来看都是安全的。搜索是安全的，读取文档是安全的，发邮件也是正常操作。"

该智能体拥有：search_web() + read_internal_documents() + send_email()

这种推理方式存在什么问题？

答案模式：

## 第二部分后的更新思维模型

第三部分的练习题

这些都是真实的面试题，请认真思考。

Q1 —— 爆炸半径思维

你有两个智能体：

智能体 A：search_web() + read_public_webpages()

智能体 B：read_customer_database() + send_arbitrary_http_requests() + send_email() + issue_refunds() + delete_accounts()

两者均遭受了成功的提示注入攻击。

对比它们的爆炸半径。这对智能体的设计方式有何启示？

Q2 —— 生产级邮件助手

你需要构建一个邮件助手，它能够：

- 读取用户的收件箱

- 起草回复供用户审阅

- 在用户明确确认后发送邮件

请设计其安全架构。每个组件拥有哪些工具？人工审批在哪个环节发生？什么内容需要被记录日志？

Q3 —— 含冲突文档的 RAG 系统

你的检索系统拉取了两份文档：

- 文档 A（版本 1，6 个月前）："退款窗口期：30 天"

- 文档 B（版本 2，最新版）："退款窗口期：14 天"

两份文档均被传入 LLM。

可能出现什么问题？谁负责防止这种情况？如何在检索层而非 LLM 层解决这个问题？

Q4 —— 工具参数注入

模型可以访问 transfer_funds(from_account, to_account, amount)。

一位经过合法身份验证的用户请求将 100 美元转入其储蓄账户。

但模型生成了如下输出：

哪些验证层能够捕获这个问题？请按顺序列出所有层级。

第三部分即将到来

下一期：工具调用与智能体架构。

核心智能体循环。ReAct 模式。规划器/执行器。状态机。工作流与智能体的区别。终止条件。

这是让你从"理解 LLM"迈向"构建真正可用的系统"的关键章节。

如果这些内容对你有帮助：

→ 转发给每一位正在构建智能体的开发者

→ 关注 @sairahul1 获取第三部分及系列后续内容

→ 收藏本文 —— 验证链与安全架构是你每次构建都需要参考的两件事

我专注于撰写 AI、产品构建以及在你休眠时仍能正常运转的系统。