企业权限与数据治理官

要解决的问题

在多数团队里，权限问题不是"有没有管"，而是"能不能看见"：账号散落在多个系统，人员的入职、转岗、离职时间点和权限变更常常对不上；离职未撤权、长期无人使用的孤儿账号、超出岗位基线的超权项，往往要等到审计或安全事件才暴露。更麻烦的是治理材料本身：已确认事实、主观判断和猜测混在一张表里，待补证项没有责任人也没有时限，报告写完之后没人复核，撤权动作也没有证据链。

技能如何工作

这个技能按四个模式运行：入职开通审查、转岗权限审查、离职撤权审查和定期治理。信号同时命中多个模式时，按固定优先级择一为主：在用高风险权限与离职未撤权 > 敏感数据暴露 > 审批证据缺失 > 账户整洁；仍无法判断时只问一句"是具体人员的入转调离审查，还是跨系统定期治理"，不擅自猜测。

执行顺序固定且可复核：

1. 读取 references/execution-rules.md，从四个模式中选择主模式；
2. 读取 references/quality-boundaries.md，先确认高影响动作和人工审批边界；
3. 读取 references/methodology.md，只取当前模式需要的方法卡；
4. 按 references/output-contract.json 与 assets/output-template.md 生成新的 Markdown 执行件；
5. 运行 python3 scripts/validate_output.py --check-output，失败时修正内容，不删除检查也不放宽规则。

输入先过闸门：人员身份、雇佣或合作状态、岗位、经理与有效期限，系统账号、角色、权限项、来源与认证方式，岗位最小权限基线、例外审批和敏感数据分级，以及入转调离日期和撤权证据。信息被分成已确认事实、我的判断、还缺证据三栏，每个待补证项都带责任人和日期。人员身份、系统账号或系统责任人三者任一完全缺失时，只输出资产盘点和证据补齐计划，不给出权限开通或撤销建议。

最低交付包括审查范围与数据截止点、人员—账号—权限—敏感数据关系及最小权限差异、入转调离与例外审批中的缺口和风险、以及带责任人和复核日期的整改动作。

适用边界

• 不输出真实密码、令牌、密钥、个人敏感数据或完整权限导出；
• 不直接创建、提升、禁用或删除账号，不绕过系统所有者审批；
• 不把"未使用"直接等同于"可删除"，先核对业务、保留和取证要求；
• 机器校验通过只代表治理材料完整，不等于技术整改已执行或审计已完成。