一个团队在周五发布了一个支持工单分类代理。它在两周内运行良好——读取收件邮件、起草回复、创建工单。随后，一次提示词回归漏洞随部署溜入生产环境，导致该代理错误分类了一个邮件线程，并开始对所见的一切内容进行回复。数小时内无人察觉，因为该代理使用的凭证与整个平台共用，其邮箱与其他三个机器人共享，且没有针对单个代理的配额限制来触发警报。事后分析报告的第一句话写道：我们无法区分哪个代理执行了哪些操作，也没有任何机制能够阻止它们中的任何一个。
这并非大语言模型的问题。这是一个访问控制问题，而解决方案则是安全领域最古老的理念：最小权限原则——即每个代理拥有独立的身份、独立的作用域以及独立的配额。
事件背后的模式
代理集群往往从单一的概念验证项目发展而来，而概念验证阶段的临时捷径逐渐固化为架构：一个拥有完全访问权限的应用程序接口密钥、多个代理共享的一个邮箱、仅存在于系统提示词中的能力边界。每一个捷径都扩大了故障影响范围。奈拉斯人工智能代理安全指南对第一点直言不讳——应用程序接口密钥授予对所有连接账户的完全访问权限，因此应像对待数据库根密码一样对待它，将其保存在秘密管理器中，绝不要放在代码或任何可能被记录日志的提示词上下文中。
邮箱共享这一捷径则更为隐蔽。每次奈拉斯应用程序接口调用都限定于特定的授权范围，代理只能访问其持有标识符的授权数据。这种范围限定提供了免费的隔离性——但前提是每个代理都拥有自己的授权。如果共享同一个授权，你就将所有代理的读取权限、发送历史记录和故障模式合并到了一个池中。
使访问权限与任务相匹配
在配置任何资源之前，先写下每个代理实际执行的任务，然后仅授予相应的权限：
| 如果代理... | 它需要... |
|---|---|
| 总结收件箱内容 | 仅读取电子邮件——无发送、无删除权限 |
| 安排会议 | 读取日历、创建事件——无电子邮件访问权限 |
| 起草供审核的回复 | 仅创建草稿——由人类点击发送 |
| 充当全能助手 | 读/写权限——需发送确认 |
在两个层面强制执行此策略：系统提示词（设定意图但可能被颠覆）和工具表面（不可被颠覆）。如果你正在使用模型上下文协议，请仅启用代理所需的工具——一个没有发送工具的总结器无法通过提示词注入被诱骗发送消息。
用策略而非承诺来强制执行限制
系统提示词仅是指导；策略才是强制手段。对于代理账户（目前处于测试阶段），策略、规则和列表将边界完全移出了模型的控制范围。策略捆绑了一系列限制——每日发送配额、存储上限、附件大小和数量、保留窗口期——以及带有 spam_sensitivity 调节旋钮的垃圾邮件检测功能，该旋钮的范围从 0.1 到 5.0。所有限制都是可选的，默认值为你所在套餐的最大值，因此你只需指定希望更严格限制的方面：
curl --request POST \
--url "https://api.us.nylas.com/v3/policies" \
--header "Authorization: Bearer $NYLAS_API_KEY" \免责声明：本文内容来自互联网，该文观点不代表本站观点。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，请到页面底部单击反馈，一经查实，本站将立刻删除。
