一人公司最容易忽略的安全环节，不是授权，而是回收。临时协作者完成任务后，如果仍能访问域名管理、云服务、支付网关或客户数据平台，原本短期的合作就可能变成长期暴露。凭据回收机制的目标，不是“记得删掉一个账号”，而是让每次授权都具备范围、期限、触发条件和验证结果。

先建立可回收的授权台账

每项外部访问都应记录四类信息：使用者、访问对象、权限范围和失效条件。协作者只应获得完成任务所需的最低权限，不能直接共享整个密码库。业务凭据可按个人账户、业务账户和临时协作者凭据分开管理；域名、支付网关、邮箱等高危账户必须单独标记，API密钥则应记录对应项目和用途。

失效条件不能只写“项目结束后处理”，而应绑定具体事件，例如交付验收、合作终止或权限用途消失。对于无法设置自动期限的访问，至少在台账中预先登记回收日期，并把回收任务放入固定检查流程。

回收不等于删除邀请

项目结束时，应按凭据类型执行不同动作。密码管理工具中的共享保险库或协作者邀请要立即撤销；子账号应停用或删除；API密钥应重新生成；协作者曾经接触过的共享密码则必须更换。仅删除对方在密码管理工具中的访问，并不能证明其没有复制密码、截图或保存密钥。

高风险账户尤其需要“撤销后验证”：从协作者视角确认旧账号无法登录，从管理端检查活跃会话、共享记录和访问权限，再将结果记入台账。无法确认是否被复制的凭据，应按已泄露处理，而不是依赖对方口头承诺。

把恢复能力纳入回收设计

凭据回收不能导致经营者自己失去业务控制权。主密码、恢复码和双重验证应有可执行的备份方案；业务账户的恢复邮箱、手机号和恢复码要定期确认仍然可用。独立的双重验证工具能降低密码与验证码同时暴露的风险。

每季度盘点一次账号，删除不再使用的服务，并检查临时授权是否仍有必要。对于高频合作的一人公司，还可以约定统一的“授权—使用—回收—验证”流程。只有回收动作能够被触发、执行并留下验证记录，凭据管理才真正形成闭环。