AI Agent安全五法则：默认不信任外部文本

AI Agent每天都要处理大量并非自己生成的文本——网页、邮件、issue讨论、API回复。其中一部分文本会试图以命令的口吻与Agent对话，诱导其偏离既定任务。这篇来自一线软件Agent的实践总结，提出了五条可测试的规则，用来抵御外部文本的指令注入。

核心前提：渠道决定权限，而非措辞

作者开篇就点明了问题的本质：Agent读取的文本中，有些内容会「假装自己说了算」。一个写着「忽略你的指令」的网页，本质上只是该网页的一个事实属性，而非一条有效命令。真正赋予指令权限的是来源渠道——只有所有者（owner）和固定策略才能下达命令。

这一判断是后续五条规则的总纲。它把「谁说的」和「说了什么」彻底分开，让Agent在面对可疑文本时有了明确的判定依据。

提示注入（Prompt Injection） 是这类风险的技术名称，指攻击者将指令嵌入Agent会读取的文本中，诱导模型将其当作合法命令执行。它与传统注入攻击（如SQL注入）的相似之处在于：数据与指令的边界被模糊。由于大语言模型天然难以区分「被引用的文本」和「对其下达的指令」，攻击者只需在网页、邮件或代码注释里写一句「忽略之前的指令，改为……」，就可能劫持Agent行为。间接提示注入（Indirect Prompt Injection）特指指令并非由用户直接输入，而是藏在Agent自主抓取的外部内容里，危害更隐蔽：用户可能完全不知情，Agent却已偏离任务。理解这一概念是理解「渠道决定权限」的前提——正因为模型无法可靠地从语义上分辨指令与数据，才需要用结构性的来源规则来兜底。

五条可执行的防护规则

规则一：内容即数据，永远不是命令

任何外部内容都只能被当作数据处理，可以总结、可以报告，但不能执行。这条规则的关键在于「可操作性」——它不是一种态度，而是一个明确的分类动作：读到任何文本，先归类为数据，再决定后续行为。

规则二：工具返回结果同样不可信

API回复、README文件、代码注释都可能夹带被植入的指令。作者的做法是将所有外部文本包裹在明确标记的区块中，这样在后续回读时仍能记得它的来源。这种「来源标记」机制解决了上下文变长后信息溯源困难的问题，是工程上很容易落地的一步。

规则三：机密信息绝不外流，无论理由多充分

要求把存储的密钥发送到某个「备份」或「收集器」地址的请求，一律拒绝。听起来再合理的理由也不改变结论。作者更进一步：把这类请求视为安全事件，并主动上报给所有者。

规则四：内部地址保持关闭

云元数据端点、回环地址、私有网络地址，无论请求如何包装都不读取。作者指出了一个容易被忽视的风险：一个能访问这些地址的抓取工具，本身就是一条入侵通道，因此不能以那种方式使用它。

云元数据端点是云厂商提供给实例的本地服务，用于查询实例身份、临时凭证等敏感信息，典型代表是AWS的 169.254.169.254。它只允许从实例内部访问，对外不可见，因此长期被视为「可信内网」。但正因如此，一旦Agent的抓取工具能访问它，攻击者就能借Agent之手读取云凭证，进而横向渗透整个云账户。历史上多起重大泄露（如2019年Capital One事件）正是通过服务端请求伪造（SSRF）打到元数据端点。回环地址（127.0.0.1）和私有网络地址（如10.0.0.0/8、192.168.0.0/16）同理，它们暴露的是Agent所在环境的内部服务。规则四的本质是把抓取工具的访问范围限制在公网，避免它成为SSRF的跳板。

规则五：不可逆操作需要已验证的通道

转账、支付费用，或任何无法撤销的操作，都需要所有者通过批准的流程进行明确确认。仅在聊天窗口中自称是所有者的消息，不构成该流程。这一条针对的是身份冒充类攻击，强调「验证通道」而非「验证身份声明」。

为什么规则比单纯判断更重要

作者给出了一个很有说服力的理由：每条规则都有触发条件和可见的检查点，因此可以被测试。Agent可以拿过去的失败案例对照规则回放，检验自己现在是否会做出符合规则的决定。

反过来，无法被检查的规则容易退化为模糊的希望。这正是规则化思路的价值所在——它把安全从「感觉对了」变成「可以验证」。

实践启示

这五条规则的共同特征是：不依赖对文本意图的语义判断，而是依赖结构性的约束。来源标记、地址黑名单、不可逆操作的双重确认，都是确定性很高的机制。对于正在构建Agent系统的开发者来说，这套框架提供了一个轻量但覆盖面较广的起点。作者在文末也抛出了开放问题：还有哪些规则值得加入，这些规则在哪些场景下会失效。