xypass 创建访问令牌时会返回一次性凭据包，之后的列表只显示名称、状态、到期时间、最后使用时间和授权数量。这不是界面上的不便，而是为了让服务端和日常页面都无法重新导出完整秘密。
凭据包里有两种关键材料
auth_token 用于证明自动化客户端属于哪个 PAT；capability_key 留在客户端，用来解开该 PAT 获得的 Vault 或 Item 目标密钥。服务器保存认证摘要和被包裹的密钥，不持有可直接读取条目内容的 capability key 明文。
只有 auth_token 时，客户端不能完成数据解密；两者同时泄漏，并且令牌仍有效且拥有授权时，攻击者就可能以该自动化身份访问相应数据。因此整个凭据包都应按生产密钥处理，而不是把它当作普通配置 JSON。
优先使用专用 Secret Store
生产服务应把凭据放在 CI Secret、容器 Secret、操作系统 Keychain、硬件保护的凭据库或权限严格的密钥管理系统中。确实只能使用文件时，目录和文件只允许运行服务的账户读取，Unix 文件权限至少收紧到 0600。
不要把凭据放入以下位置：Git 仓库、Dockerfile、镜像层、公开环境示例、命令行参数、构建日志、错误追踪字段、工单附件或多人聊天。命令行参数可能进入 shell history 和进程列表，普通环境变量也可能被调试工具或子进程读取。
每个服务使用独立令牌
不要让多个项目共享一个“万能 PAT”。独立令牌可以使用不同目标、角色和到期时间，也能在单个服务出现问题时只撤销对应访问。多台 Runner 若属于不同信任边界，也应使用不同令牌，而不是复制同一份凭据包。
丢失和泄漏是两种处理
如果凭据文件丢失但没有泄漏证据，可以在 Web App 中续期，下载新的凭据并替换旧值。续期会立即让旧认证凭据和已有机器会话失效，同时保留当前授权。
如果怀疑凭据已经泄漏，应先撤销整个令牌，而不是只续期或结束当前会话。撤销不能召回客户端此前已经解密的数据；高风险情况下还需要轮换受影响 Vault 或 Item 的密钥和其中的第三方密码。
最后，选择明确到期时间并定期查看“最后使用”。长期从未使用、用途说不清或负责人已经离开的令牌，应当撤销，而不是无限续期。
