项目验收往往是一段很忙的时间。业务确认上线结果，交付团队整理文档，运维开始接管日常支持。就在这个阶段，最容易被放到后面的常常是临时账号、接口白名单和测试环境权限。它们在项目期间确实必要，项目结束后却可能继续存在数月，直到一次审计或异常登录才被重新发现。
权限遗留并不说明企业没有身份系统。很多时候，正式员工账号管理得很严格，问题发生在临时协作边缘：外部实施人员的堡垒机账号、用于联调的服务账号、短期开放的数据库只读权限、为排障放开的网络访问。它们分散在不同系统中，项目经理以为运维会收，运维则不一定知道哪些是项目特例。
把权限回收放在验收后的某一天，很容易落空，因为那时团队已经进入下一项目。更稳的办法，是把回收动作前置到交付清单里。每一项临时访问在申请时就标明所属项目、责任人、有效期和回收条件；项目进入验收阶段时，系统自动生成待确认清单，而不是依赖项目群里的一句提醒。
这里也要保留现实弹性。部分账号在验收后确实还要支持观察期，不能简单一刀切关闭。关键是把观察期变成有终点的授权：谁批准延长、延长到什么时候、到期后由谁复核。没有有效期的临时权限，本质上不是临时，而是未被治理的长期权限。
在安全运维与服务中心能力中，项目权限应与工单、资产和身份台账关联起来。这样运维接管时能看到每个例外为什么存在，项目结束时也能按清单回收，而不是逐个系统回忆。
建议从最近一个验收项目开始做回看：能否列出所有外部账号、服务账号、接口密钥和网络例外，并确认每项都有当前负责人和失效时间。若还要分别向项目、开发和运维询问，说明系统集成已经交付，权限治理却没有随应用协同一起收尾。更多运维实践可见新闻栏目。