限制智能体的权限

授予访问权限前先描述任务

读取代码的智能体与部署服务的智能体，需要不同权限。不要因为同一产品支持两种操作，就同时授予两组权限。

用三个部分定义权限：操作、资源和条件。对于虚构的报表修复任务，智能体可以在任务有效期间写入一个功能分支，可以读取获准的代码仓库文件，但不能修改生产数据或代码仓库保护规则。

具体约束方式取决于工具。如果令牌无法表达分支限制，就使用额外的代码仓库控制措施或执行服务。如实记录仍然保留的权限。

在模型之外落实限制

提示词不是访问控制系统。执行组件必须根据当前权限，检查请求的操作和目标资源。不能仅因模型声称已有批准，就接受该说法。

AWS 建议为适当的工作负载采用有限权限和临时凭据。OWASP 也将类似的最小权限原则用于智能体及其工具。这些原则必须在实际身份和执行系统中落实。参见 AWS IAM 指南和 OWASP 智能体指南。

在支持的情况下使用短期凭据。不要将无关秘密信息放入环境。只读代码仓库任务不应从开发者的 shell 继承生产数据库密码。

将批准绑定到实际操作

批准准备修改，不等于批准部署。部署决定应明确制品、目标环境和相关条件。如果这些内容改变，之前的决定可能不再适用。

设想智能体提出安全的数据库读取操作，却在获批后执行了另一条查询。有效的批准机制会检查实际运行的操作。如果目标未明确，笼统的“继续”消息可能掩盖这种差异。

也要区分身份与能力。记录由哪个人或工作负载发起运行。操作发生时，验证发起身份仍有权限。撤销某人的访问权限后，应明确它对排队工作的影响。

测试拒绝与中断

不要只验证成功路径。在隔离测试环境中，尝试操作获准范围之外的资源。确认执行系统会拒绝。检查审计事件，但不要记录凭据。

然后测试取消或凭据到期。确定哪些工作立即停止，哪些操作可以完成。停止按钮不一定能撤销已经到达其他系统的操作。

随任务保留一份简短权限记录，包含负责人、批准范围、实际控制措施、拒绝测试和到期条件。这样，后续审查才能足够具体，有助于改进工作流。