Permission Envelope：让 AI 权限自动过期的安全控制机制
提出「权限信封」概念，通过短期、范围受限且会自动过期的授权来控制 AI Agent 权限，防止长期权限被滥用，适合企业内部 AI Agent 安全治理。
完整中文译文
大多数团队一旦赋予 AI agent 某项能力，就再也不会收回。
那不叫同意。那叫一份没有到期日的永久授权书。
模型请求日历访问权限、CRM 写入权限或部署令牌。有人点击了允许。三周后相同的授权依然有效——面对的是不同的任务、不同的租户上下文，以及一位早已忘记自己批准了什么内容、身心俱疲的工程师。出问题时，日志显示"已授权"，却不会显示人类上次真正意图授权的时间。
我把这个缺失的控制机制称为 Permission Envelope（权限信封）：一种短期的、限定范围的授权，除非人类主动续期，否则就会消亡。过期不是官僚主义。过期是审计日志，它证明在工具触发时，同意仍然是新鲜的。
背景
一个平台团队上线了一款内部"发布助手"。它可以读取 PR、起草发布说明，并且在打开一个开关后，还能在生产环境创建部署工单并通知值班频道。 staging 演示用的是长期有效的服务账号，所以每次运行都不需要重新认证。
什么出错了
两个 sprint 后，一个嘈杂的告警链导致 agent 为错误的服务创建了部署工单，并通知了错误的值班轮次。之前为金丝雀发布批准的"创建工单 + 通知"授权从未过期。没有任何重提请求，没有任何 TTL，没有任何日志行说明"上次人类同意是 19 天前针对一个不同的变更"。安全团队认定这是"已授权"操作。运维团队认定这是一次险情。
修复方案（Permission Envelope）
- 限定授权范围——"为服务 X 创建部署工单 + 通知轮次 Y"，而非"任何工单、任何频道"
- 绑定目的——一个变更 ID / 一个发布窗口；授权不能被复用于不同的 PR
- 设置短 TTL——不可逆操作分钟到小时；只读操作可以几天
- 过期时重新请求——禁止静默续期；重新进入的唯一路径是全新的人类意图
- 记录同意，而非仅记录认证——谁批准了、他们看到了什么、何时过期、以及哪项操作消耗了授权
同一个 agent，同一个模型，不同的爆炸半径。下一次错误服务的工单通知永远停留在草稿状态。
Permission Envelope 不是为了不信任模型。它是为了拒绝让昨天的"是"来授权今天的不可逆操作。
为什么永久授权会悄然失效
Auth 回答的问题是：这个身份是否被允许调用该工具？
Permission Envelope 回答的问题是：人类是否仍然意味着这个特定操作、用于这个特定目的、就在此刻？
这是两个不同的问题。大多数 agent 架构只问第一个。
服务账号和 OAuth 令牌在重启后存活能力很强。它们极不擅长记住人类点击"允许"是为了金丝雀发布，而不是为了以后每个星期二。永久授权优化的是更少的点击次数。生产环境优化的是凌晨 2 点更少的意外。
Permission Envelope 架构（五层）
把授权当作一个系统来构建，而非settings里埋没的复选框。
1. 范围（什么）
精确命名工具表面：哪些写端点、哪些租户、哪些频道。优先采用默认拒绝。"CRM 更新"不是能力——"仅在账户 A 上更新工单状态，字段限于 status + note"才是。
如果你不能用一句话向一位初级工程师解释清楚这个能力是什么，这个授权就已经过宽了。
2. 目的（为什么 / 哪一个）
将授权绑定到一个具体的工作项：PR 编号、变更工单、事件 ID、客户案例。当目的发生变化时，信封就消亡。跨任务复用会导致"已授权"变得毫无意义。
3. 有效期（多久）
选择能让工作流完成的最短 TTL：
- 不可逆写操作（发送、部署、扣费、删除、通知）——分钟到几小时
- 变更草稿（创建工单、起草邮件）——几小时，然后重新请求
- 只读操作——可以稍长；但仍然要过期，避免被遗弃的会话持续存在
自动延期是一种坏味道。如果任务需要更多时间，人类应该知道。
4. 新鲜同意（谁 / 何时）
过期必须强制一次真正的重新请求：再次展示爆炸半径，获得明确的批准，冻结已批准的负载。不允许模型在点击后重新生成操作。不将"仍然登录"视为"仍然同意"。
重新请求是团队一直在跳过的审计字段——也是监管机构和事后复盘真正关心的字段。
5. 消费日志（证明）
每个使用信封的工具调用都记录：
- Grant ID + 范围 + 目的
- 审批人身份 + 时间戳 + 他们当时看到的内容
- 过期时间 + 本次调用是消耗还是续期
- 结果（成功 / 拒绝 / 飞行中过期）
如果你只记录"token 有效"，你无法重建同意。你只能重建希望。
这如何映射到你已有的东西
- 5 层 agent 架构 — Tools 获取带类型的范围；Guardrails 拒绝信封外的调用；Traces 携带 Grant ID；当被消耗的授权出错时 Rollback 仍然重要
- Ship Gate — 威胁模型命名"过时同意"；人工override就是重新请求；可观测性就是消费日志
- Smoke evals — 添加授权过期、目的不匹配或范围过宽的场景；如果 agent 仍然触发写操作，CI 应该失败
Permission Envelope 不能替代 Ship Gate。它让 gate #4（人工 override）在首次批准后——以及此后每个小时——变得真实。
在下一个 agent 写工具上线之前，问自己一个问题：
对于每一个不可逆操作，我们能否展示：谁同意了、同意了什么样的范围、用于什么目的、以及该同意何时过期——以及当这些信息缺失或过时，工具是否会拒绝？
如果任何一半答案是"否"，你仍然在交付的是永久授权书。
我是 Wasim Sheikh —— AI 架构师。我构建的系统是团队信任并依赖组织运行的：不是 demo，不是概念验证——而是生产级系统。
如需进一步行动，请考虑屏蔽此人和/或举报滥用