AI 自动化接入更多系统后，先查权限和重复执行

文档中的小变化，可能影响既有授权判断

AWS DevOps Agent 的更新记录中，10 月 29 日条目提到 Operator App 访问相关托管策略新增 SearchAssets 与 ListWebhooks。这里需要特别小心：不能因为新增条目涉及读取动作，就把整份策略概括成只读。实际可执行范围仍要回到当前 IAM 权限说明，结合角色、资源范围与关联条件检查。

我们关注这件事，并不是据此评判某项产品安全与否，而是它揭示了一种日常管理任务：首次接入时同意的权限，不应在此后永久免于复核。对于希望把自动化交给服务器持续运行的团队，权限变更、连接过期和异常回调都属于运营成本，不能只看首次搭建所花的时间。

Basis [1] Amazon Web Services · [2] Amazon Web Services

先分清读取、建议与执行三种能力

假设团队希望 AI 每天整理订单异常。读取订单、归纳可能原因、给客服生成回复草稿，与实际退款、修改收件地址、重新发货，是不同程度的动作。我们建议先让系统在较小范围完成读取和建议，把会改变资金或履约结果的动作单独设定审批与责任人。这是一个自拟工作流建议，不是 AWS 产品功能清单。

权限也应围绕真实任务收窄：只需要某个业务范围的数据，就不默认扩大到整个账户；只需要生成草稿，就不顺手授予发送权限。若某接口无法按所需粒度授权，应把这个限制记录下来，再决定是否采用替代流程。不能把“模型应该知道什么能做”当作访问控制本身。

真正的验收，要故意让它遇到重复和失败

在隔离环境里，可以主动设计几种情况：同一个事件发送两次，外部接口暂时超时，权限被撤销，数据只返回一半，以及任务执行成功但确认回执丢失。验收重点是系统能否说明哪些步骤已完成，哪些仍未知，是否会把已经完成的业务动作再做一遍。本文没有实际执行这些测试，列出的是建议验收项目。

对于需要写入的步骤，建议使用稳定的业务标识、执行记录和去重检查。出现不确定结果时，先查询外部状态，再决定是否重试；对无法安全确认的动作，进入待人工处理的队列。这样做未必让演示更华丽，却能让经营负责人知道：系统遇到模糊结果时会停在哪一层，而不是继续猜测。

服务器定时运行之后，仍然需要维护责任

定时器只回答何时启动，不回答输入是否可靠、权限是否过期、上一次是否已经执行。一个值得保留的运行记录，应包含核查时间、输入范围、实际动作、外部回执和失败原因。尤其是会收费或影响客户的步骤，不能用“任务已运行”代替“业务已完成”。异常恢复后，还要确认是否需要补跑，以及补跑范围是否会重复。

我们的投入排序是先做有边界、可恢复的小流程，再逐步增加连接和动作。若团队能够用真实运行记录证明重复事件不会重复写入、失败会停在明确位置，而且权限定期复核有效，就有理由扩大使用。若现阶段只有一次成功演示，更合适的结论仍是试点通过了某条路径，而不是已经可以无人值守接管业务。