AI Agent工具权限设计：为什么限制要设在提示词之外

给AI Agent配置工具时，大多数人的第一反应是在提示词里写清楚"不要做X""只能做Y"。但巴黎全栈开发者Amine Affif提出了一个截然相反的思路：把限制设在进程启动的那一刻，而不是写在提示词里。

提示词是请求，不是约束

Affif的核心判断很直接：提示词本质上是一个请求。模型可以选择忽略它，也可能被恶意文本扭转方向——尤其是当Agent需要读取它无法控制的外部内容时。

这与传统软件工程中对第三方依赖的态度一致：不信任，但隔离。你不会因为在一个依赖库的文档里写了"请勿访问网络"就放心，你会在运行时层面切断它的网络权限。Affif认为Agent的工具权限也该用同样的逻辑处理。

他自己构建的Agent采用了封闭式工具清单：预先允许十二个读工具，拒绝十五个写工具。结果是，这个Agent无法写文件或发送消息——即使它"想要"这么做。

运行时隔离的三层补充

除了工具清单的硬性开关，Affif还叠加了三项保护措施：

反注入提示段。 因为Agent会读取不受控的文本，提示词中专门设置一段用于对抗注入攻击的内容。这并非万能药，而是在模型层面增加一道干扰门槛。

强制对抗性检查。 每次输出前，Agent必须经过一轮对抗性审视，类似于让模型"自己攻击自己"，以暴露潜在问题。

人工验证。 任何内容在发布之前，都需要人工确认。这一层看似低效，但它把最终决策权留在了人类手中。

说个细节，这三层保护与运行时隔离并不互相替代。提示词层的防护可以被绕过，运行时隔离才是兜底的那道墙。

提示注入（Prompt Injection） 指攻击者将恶意指令隐藏在Agent会读取的外部内容中（如网页、文档、邮件），诱导模型偏离原定任务。它之所以危险，是因为模型难以区分“数据”与“指令”——一段被读取的文本可能在模型看来与系统提示具有同等效力。这与传统SQL注入有相似之处：都是把不可信输入当成了可执行命令。防御思路通常分两层——模型层的检测与过滤（如反注入提示段），以及系统层的权限收窄（如运行时隔离），后者不依赖模型判断，因而更可靠。

对抗性检查（Adversarial Checking） 借鉴了对抗样本研究的思路：让另一个模型实例或同一模型以“攻击者视角”审视输出，寻找逻辑漏洞、事实错误或安全隐患。常见实现包括自我批判（self-critique）、红队提示（red-teaming prompt）以及多轮辩论。它属于概率性防护，能提高问题暴露率，但无法保证穷尽所有风险，因此适合作为运行时隔离之外的补充层，而非替代品。

能行动的Agent，服从的是环境而非礼貌

Affif给出的理由值得反复咀嚼：一个能行动的Agent，做的是环境允许它做的事，而不是被礼貌请求做的事。如果某个动作在物理上不可能，就不存在需要"信任"的空间。

这句话点出了当前Agent安全讨论中一个常见的误区：把可靠性问题当成对齐问题来解决。写更长的系统提示、加更多的"请勿"条款，本质上是在用概率手段对抗确定性风险。而运行时权限控制直接把不可能的动作变成不可执行的动作——不需要模型配合，不需要它"理解"。

运行时隔离（Runtime Isolation） 与提示词约束的本质区别在于执行位置：前者在进程、容器或系统调用层面切断能力，后者仅在Token层面表达意图。常见的工程手段包括：用最小权限原则配置进程可访问的文件系统与网络；用seccomp、AppArmor等机制限制系统调用；用容器或沙箱隔离执行环境；以及通过工具白名单/黑名单在框架层直接拒绝未授权调用。其核心优势是确定性——无论模型输出什么，越权动作在物理上都无法发生。代价是灵活性下降，需要在设计阶段就想清楚Agent真正需要哪些能力。

速度不是重点，可控才是

Affif在文中坦言，他关心的不是工具带来的速度提升，而是如何约束这些工具。这种约束能力才是让人敢于快速推进的前提——否则你就是在把未经阅读的代码拖进仓库。

这个视角对工程团队有实际参考价值：当Agent被赋予写权限时，代码审查的边界在哪里？当Agent能发送消息时，谁为消息内容负责？运行时隔离给出的答案是——不要让这些问题发生，而不是发生后去追责。

对正在把Agent接入生产环境的开发者来说，Affif的做法提供了一个轻量但清晰的范式：先划定Agent能触碰的工具边界，再谈提示词优化。顺序反过来，风险就失控了。