Agent 权限变更不能藏在后台设置里
Agent 权限变更记录，是团队在 Axon Agent 的工具、来源、外发、发布、覆盖或付费动作权限发生变化时，写下谁批准、范围是什么、什么时候过期、如何回退。很多自动化事故不是因为 Agent 一开始权限过大，而是因为某次临时授权后来没人收回。几周后，owner 发现 Agent 可以做的事比原来多，手动追查既耗时又低效，还容易遗漏真正的变更原因。
OWASP Top 10 for LLM Applications 提醒团队关注过度代理和不安全动作；NIST AI Risk Management Framework 也把治理和管理过程放在 AI 风险控制里。Axon 的判断是：权限不是后台开关，而是 Agent 工作流的一部分。权限变化必须能被 owner 看见。
这篇文章连接 Trust Mode 预检策略、Agent 审批队列、Agent 升级路径设计 和 Agent owner 操作说明。它讨论的是一个很小但关键的问题：当 Agent 能做更多事时，团队是否知道为什么？
权限变化要写成差异
不要只写“已授权”。这句话无法解释风险。更好的 Agent 权限变更记录要说明变化前后。
Agent: 每周客户反馈摘要
change_type: temporary_external_send
before: generate internal draft only
after: allow sending to customer success group after owner approval
reason: leadership requested Monday summary delivery
owner: customer operations lead
expires: 2026-07-31
rollback: return to internal draft only
related_artifact: workspace/artifacts/weekly-feedback-summary.md
这条记录让权限变化有边界。它也让审批队列更清楚：审批不是抽象地“允许继续”，而是允许一个被定义过的动作。
权限变更的核心不是谁能点开设置，而是谁愿意对变化后的 Agent 行为负责。
四类权限不要合并成一个开关
- 来源权限：Agent 能读取哪些 workspace sources 或外部页面。
- 工具权限：Agent 能调用哪些工具，是否允许重试。
- 输出权限：Agent 能生成草稿、覆盖 artifact、发布或外发。
- 恢复权限：Agent 失败后能否自动重跑、回退或继续。
把它们合并成一个“高级权限”会制造模糊。一个 Agent 可以有很宽的读取权限，但没有外发权限；也可以有稳定的生成权限，但覆盖 accepted artifact 必须审批。
临时权限一定要有结束方式
临时权限最容易变成永久权限。团队可以用很短的规则避免这个问题：
第一步：写清权限为什么临时开放。
第二步：写清开放后的范围和禁止动作。
第三步：写清到期时间或触发回收的事件。
第四步：到期后确认是否回退、延长或变成正式权限。
如果没有第四步，所谓临时权限就只是慢慢忘掉的权限。
FAQ
Q1：Agent 权限变更记录是不是每次小设置都要写？
不是。影响来源、工具、外发、发布、覆盖、付费动作或恢复方式的变化才值得记录。
Q2：权限变更由谁批准？
通常由业务 owner 批准。构建者可以执行配置，但不应替业务 owner 承担外发或发布风险。
Q3：权限变更和 Trust Mode 有什么关系？
Trust Mode 可以把高风险动作放在确认边界内。权限变更记录说明这个边界为什么改变。
Q4：如果权限缩小，也要记录吗？
要。权限缩小会影响 Schedule、下游 Workflow 和恢复策略，后续排查时需要知道原因。
Q5：权限变更记录保存在哪里？
最好和 Agent 的 workspace artifact、运行说明或 owner note 放在一起，而不是只存在后台设置里。
下一步
开始使用 Axon 管理重要 Agents 时，为每一次关键权限变化写 Agent 权限变更记录：before、after、reason、owner、expiry、rollback。了解更多时，不要只问 Agent 现在能做什么，也要问它为什么获得这些权限；开始使用时，先检查 recurring Agent 是否存在过期但未回收的临时权限。