大模型服务审计与权限治理：6项指标降低数据暴露风险

大模型服务的风险不只来自模型回答错误，也可能来自谁能调用服务、服务能读取哪些数据，以及事后能否查清一次调用。做好大模型服务审计、访问控制与敏感数据保护，应把这些环节拆成可验证的指标，而不是只检查模型本身。

可用客服问答、会议纪要整理或代码辅助等场景开展检查：分别观察用户身份、输入内容、模型请求和外部工具调用。测试应使用虚构或已脱敏数据，并避免把真实敏感信息复制到测试环境。

六项指标：从“谁访问”到“留了什么记录”

指标	核查重点	风险降低方式
1. 身份可归属	请求能否关联到具体用户或服务身份；共享账号是否被限制。	区分人员账号、应用身份和管理员身份，发现异常时才能定位责任范围。
2. 权限范围可解释	每个身份可调用哪些模型、数据源和工具，授权是否有负责人和用途。	按最小权限配置，定期复核不再需要的授权，减少凭据泄露后的可达范围。
3. 敏感数据有边界	输入、检索内容和输出是否按数据分级处理；是否识别个人信息、密钥等内容。	在进入模型前过滤或遮蔽不必要字段；对输出设置检查，避免敏感内容被直接返回。
4. 工具调用受约束	模型能否调用网页、文件、邮件或业务接口；调用参数和结果是否经过校验。	只开放必需工具，并在应用端校验参数、限制可执行操作，不能把模型生成内容直接当作可信指令。
5. 审计记录够用	是否记录请求时间、调用身份、模型版本、策略结果和工具调用状态。	保留调查所需的元数据；只有确有必要时才记录提示词或完整输出，并先评估其中的敏感信息。
6. 日志访问与保留受控	谁能查看、导出和删除日志；保存期限是否有明确依据。	限制日志读取权限并记录导出行为，按业务、合同和适用法规确定保存周期，到期后安全删除。

六项指标不宜只看“是否开启”。例如，日志记录很完整但任何员工都能导出，反而扩大暴露面；权限范围看似狭窄，却允许模型调用未校验的外部工具，也仍可能产生越权影响。数据分级、最小权限和审计日志需要一并设计。

画出调用路径。从用户端到模型服务，再到检索源、文件存储及外部工具，标明每一段传递的数据和身份。
建立权限清单。为每类身份列出允许的模型、数据范围与工具，写明授权负责人和复核日期；移除用途不清或长期未使用的权限。
用合成数据做负向测试。检查未授权身份是否会被拒绝、敏感字段是否按规则遮蔽、提示注入是否能诱导工具执行不允许的操作。OWASP Top 10 for LLM Applications 将提示注入列为需要关注的应用风险，但具体测试应结合自身系统设计。
核对审计链路。模拟一次正常调用和一次拒绝调用，确认记录能说明身份、策略判断与工具结果；检查日志查看、导出和删除权限。
设定复核节奏。权限可按业务变化定期复查；服务、数据源或模型版本发生变更时，也应重新验证六项指标。发现问题后记录责任人、修复期限和复测结果。

这套对照适合做上线前检查、变更评审和日常抽查，不能替代专业安全测试或适用法规评估。NIST SP 800-53 等安全控制目录可用于补充访问控制与审计治理思路，但具体控制项应按组织环境选择。大模型服务审计、访问控制与敏感数据保护的关键，是让每次调用有边界、每项授权有依据、每条记录有明确用途。

不一定。完整内容有助于排查问题，也可能包含个人信息、商业秘密或凭据。优先记录必要元数据；确需保存内容时，应限制访问、明确用途和保存期限。

应确认当前服务确实没有连接检索、文件处理或其他外部能力，并在配置变化后重新核对。功能边界会随集成调整，不宜仅凭产品名称判断。

先识别不必要的身份、数据范围和工具权限，再通过受控测试确认业务流程仍可运行；保留变更记录，避免一次性删除必要授权。

没有适用于所有系统的固定期限。应依据调查需要、合同约定、适用法规和存储风险确定，并配置到期清理及例外审批。