模型接入企业系统后，风险重点不再只是“模型会生成什么”，而是“模型能接触什么、代表谁、执行什么”。因此，权限审计不能只检查员工是否使用了某个模型，而应围绕模型、智能体、API及其数据连接建立可追溯的控制链路，确认每一次调用都有明确主体、授权范围和责任人。
审计先看四类权限
第一类是身份权限：哪些员工、团队或外部应用可以调用模型，凭证是否仍在使用，是否存在共享账户。第二类是数据权限：模型能够读取哪些客户资料、代码、财务信息和内部文档，是否存在与岗位无关的访问。第三类是执行权限：模型能否发送邮件、发布内容、创建账户、修改数据或执行代码。第四类是传输权限：模型是否可以导出、转发或向外部系统提交输入和输出。
审计时应建立模型连接清单，记录调用主体、连接系统、可读数据、可执行动作、审批要求和责任人。不能因为模型能够读取资料，就默认它也可以修改、导出或转发；能够生成代码，也不意味着可以直接接触生产环境。API密钥、访问令牌和内部凭证不得出现在公开代码、共享文档或模型输入中，不再使用的凭证应及时撤销。
用实际链路验证权限
静态配置检查只能说明“理论上允许什么”，还要结合访问日志确认“实际上做了什么”。重点关注异常时间、异常地点或异常设备调用，数据读取量突然增加，新建应用拥有过高权限，以及模型访问与岗位无关的代码、客户或财务数据。日志至少应能回答：谁发起请求、使用了哪些数据、模型连接了什么系统、最终执行了什么动作。
涉及付款、账户变更、合同签署、敏感数据传输和对外发布时，模型输出不能直接视为授权指令，必须设置人工审批或独立渠道复核。出现异常后，应先暂停账户或连接、撤销相关凭证并保留日志，再判断是账户被盗、权限过宽、审核失效，还是人员受到社会工程诱导。
一次合格的审计，最终应形成可执行的权限台账，而不是一份泛泛的风险说明：哪些连接必须保留，哪些权限需要收缩，哪些动作必须人工确认，以及谁负责持续复核。