密码共享的最小权限原则，核心不是“把密码安全地发给别人”，而是让每个协作者只获得完成当前任务所必需的访问范围，并在任务结束后能够及时收回。权限应当围绕人员、账号、用途和时间边界进行设计，而不是围绕“方便登录”进行设计。

先拆分账号，再讨论共享

最危险的做法，是多人长期共用主邮箱、域名管理、收款平台或密码管理器主账号。一个账号一旦同时承载管理、恢复和财务权限，任何一次共享都可能扩大整个业务的攻击面。

更稳妥的方式是为协作者创建独立账号，或使用单独的低权限业务账号。例如，设计师只需要访问素材平台，开发者只需要处理网站后台，财务协作者只需要查看指定服务。不要因为对方需要完成一项工作，就直接交出整个系统的管理权限。

共享范围还应与项目隔离。客户项目账号、公司核心账号和个人账号不应放在同一个默认保险库中。分类的意义并非整理得更好看，而是降低误用、错发和越权访问的概率。

临时权限必须有退出机制

共享密码后，风险并不会在项目结束时自动消失。协作者可能已经将密码保存在浏览器、笔记或其他设备中，因此“删除共享记录”不等于真正收回访问权。

临时协作者完成任务后，应立即检查成员权限、旧设备和相关授权；对于无法单独撤销权限的共享账号，应及时修改密码，并确认双重验证和恢复信息仍由业务所有者控制。若共享已经成为固定流程，就不应继续依赖聊天工具或普通文档传递凭据，而应考虑支持共享保险库、成员权限和集中回收的团队方案。

工具只是执行载体

Bitwarden 的开放性、可控性以及相关自动化能力，适合愿意自行设计权限结构的用户；1Password 更强调分类、共享流程和使用体验。无论选择哪一款，工具都不能替代权限模型。

判断方案是否合适，可以只问三个问题：谁能访问，能访问什么，什么时候必须失效。只要其中任何一项无法明确回答，密码共享就仍停留在“便利优先”，而不是最小权限管理。