为访问令牌选择角色之前，还要先确定授权范围。Vault 授权适合一组由同一服务维护的内容，Item 授权则把自动化限制在一条记录。两者不是文件夹显示方式的区别，而是服务端授权和客户端密钥范围的区别。

固定秘密优先授权 Item

如果部署脚本只需要一个数据库密码、Webhook Secret 或 API Key，选择对应 Item 即可。客户端只会收到这条 Item 的密文、附件和必要历史，不能看到同一 Vault 中其他条目的密文载荷。

Item 授权适合边界稳定、依赖很少的任务。即使选择 editor，程序也只能修改这一条 Item，不能在同 Vault 中创建新的记录。

一组持续变化的配置使用专用 Vault

如果服务需要读取多条配置、以后还会增加新条目，逐条维护大量 Item 授权容易遗漏。这时可以建立一个用途单一的专用 Vault，把属于同一自动化边界的内容放进去，再授予 Vault 权限。

不要直接授权包含个人密码、财务账号和其他生产系统的通用 Vault。Vault 授权会覆盖其中现有和后续可见的 Item，因此它的内容边界必须先整理清楚。

不同服务不要共用一个“大自动化 Vault”

支付、部署、监控和客服机器人即使都运行在同一服务器上，也可能属于不同负责人和风险等级。为它们建立独立 PAT，并按需要使用不同 Item 或专用 Vault，可以在单个服务失陷时缩小影响范围。

一个 PAT 可以拥有多条授权，但授权越多，审查和轮换越困难。若清单已经说不清用途，通常应该按应用拆分令牌，而不是继续给同一个 PAT 增加目标。

人员权限不会自动变成 PAT 权限

PAT 创建时默认零权限，需要当前用户在已解锁客户端明确包裹目标密钥。自动化也不会因为创建者后来加入某个 Group，就自动获得那个 Group 的全部 Vault。

成员离职、Vault 移交或服务下线时，应分别检查人的访问路径和 PAT 授权。撤销一个 Group 成员不能代替撤销自动化令牌；删除 PAT 也不会改变其他成员对 Vault 的权限。

实际选择可以归纳为一句话：边界固定且只有一个秘密，用 Item；需要维护同一服务的一组秘密，用专用 Vault；不要为了省一次配置，把无关数据一起交给自动化。