Agent需要使用凭据来完成工作，人却未必需要看到那串凭据。把这两种需求混在一起，团队就容易陷入两难：担心影响执行而放宽展示，又或者为了隐藏内容而误以为必须停止使用。
Vault的价值，要放在实际运行关系中理解。凭据在哪里被使用、由什么运行环境承接，以及人什么时候需要查看，分别影响不同的决定。界面没有展示值，并不足以解释整个使用过程；能查看值，也不是每次任务执行的前提。
把运行和查看分开之后，才更容易安排日常协作。团队可以围绕任务需要判断运行条件，再单独处理人的查看需求，避免为了排查一个问题，让敏感内容出现在更多本来不需要看到它的地方。
同名配置按三层覆盖
当前Cloud界面提供User defaults、Space overrides和API key overrides。解析优先级从高到低为API key覆盖、Space覆盖、用户默认；某层没有这个名称时，回退到下一层。
Session认证使用用户默认和当前Space覆盖；API key认证再叠加匹配的key覆盖。即使新Space设定了值，特定key上的同名覆盖仍可能成为实际来源。反过来，新Space没配置某名称，就可能继续使用用户默认。
| 层级 | 排查问题 |
|---|---|
| API key overrides | 本次认证key是否有同名覆盖？ |
| Space overrides | 当前Space是否设定该名称？ |
| User defaults | 上层缺值时会回退到什么来源？ |
模型中保留的Base、Agent和Tool作用域不能当成当前Cloud界面已经提供的覆盖层。排查以实际可配置范围为准，不凭想象增加一层。
先区分托管运行与外部Agent
Vault说明明确，Busabase Cloud在服务端认证后解析运行值。REST、SDK和MCP客户端不会直接拿到秘密，也没有公开的GET Vault秘密端点。
所以要先定位代码在哪里执行。Busabase托管代码使用服务端上下文；你自己机器上的Agent进程和脚本，其环境变量另行配置。不能因为连接了Busabase，就认为Vault会自动注入任何本地Agent。请求目标的账户和Space选择，可参照CLI账户配置，但它与运行值解析不是同一件事。
名称相同，类型和权限也要核
Secret用于API key、签名密钥、token等敏感值，界面默认遮罩；Variable用于提供方、模型、区域、账户别名等非敏感配置。名称使用大写字母、数字和下划线。非敏感账户别名有助于核对，但不能替代正式目标身份。
每项有Runtime、Reveal、Edit、Share能力。Runtime允许托管执行使用值；Reveal允许授权用户在界面显示秘密；Edit用于修改或删除；Share为共享和委托工作流保留。需要运行某项，不等于应该给人查看秘密的权限。排查来源也不应默认要求Reveal。
Busabase审计创建、更新、删除、显示秘密和运行读取。应利用可用的配置元信息与审计定位来源，而不是把值打印到日志证明“确实读到了”。
用不含秘密的清单定位来源
在Account Settings的Vault里，分别检查用户、Space和key作用域的同名条目。记录配置名、Secret或Variable、适用作用域、是否存在、预期来源、相关权限和待确认人，不记录Secret值或可逆片段。
由有权限的人对照本次认证方式与目标Space核验。若缺少查看元信息的权限，明确缺哪一层依据，不通过导出或调试代码绕过遮罩。
需要委托Agent时，可以这样描述任务
只读核对这次托管运行的认证类型、目标Space及指定配置名的作用域。返回同名条目的存在情况、覆盖来源和权限缺口，不显示Secret值，不请求Reveal，不修改Vault，不调用外部业务服务。外部Agent环境另列为独立检查项。
这是建议的排查清单，工具权限决定Agent能读什么，不能把聊天指令当成额外授权。
改配置之前，先明确影响范围
定位后再决定修改哪一层。用户默认可能影响多个Space；Space覆盖服务于该工作区；key覆盖跟随指定认证key。把预期影响、负责人和回退安排写清楚，避免为一条任务修配置时改变其他运行。
不要为验证而发送真实邮件、轮换密钥或更改业务账户。可在获准环境用非敏感Variable核对预期覆盖，Secret只核使用结果所需的最小依据，验收输出不含值。具体测试和外部操作仍需单独授权。
若需要长期追踪，可复用配置维护Base，存名称、作用域、负责人、预期来源、最后检查与缺口；秘密仍留在Vault。建表不自动同步Vault，也不改变任何权限。
“值不对”与“没有权限”要分别定位
来源排查要回答两个独立问题：按认证上下文会选择哪一层，以及该运行是否有权使用该项。Runtime未获允许时，不应靠申请Reveal来绕过；能显示一个Secret，也不证明当前执行读到的就是这一层。先核名称和作用域，再核具体能力。
变更前列出受影响运行。改User defaults可能触及多个Space，改key覆盖则影响使用那个key的请求。为单个工作区修正配置时，应先评估是否需要该Space的明确覆盖，而不是直接改掉所有任务共同依赖的默认值。具体修改由有权限的人执行。
让方法可复用，配置来源可说明
Skill中写明需要哪些名称、由哪个运行环境读取、缺少时如何停止。工作区差异留在正确配置层，不把秘密硬编码到方法、日志或交付文档。
一次合格排查应该能说清楚：这次执行在哪个上下文里，为什么选择了这个配置来源，以及由谁确认修正。它不需要泄露那串秘密本身。