大模型服务一旦接入业务系统，安全问题就不只在模型本身：谁发起请求、能调用哪些工具、输入输出是否含敏感信息，都需要有记录和边界。做好大模型服务审计、访问控制与敏感数据保护，宜先盘点身份、权限和日志，再逐步纳入数据处理规则，而不是先追求复杂的平台配置。
先把调用身份分清楚
至少区分三类身份：普通用户、运维或安全管理人员，以及代表应用调用模型的服务身份。服务身份不应与员工个人账号共用；员工离职、应用下线或密钥泄露时，才便于单独停用和追查。身份认证可以接入组织现有的单点登录体系，服务之间则使用独立凭据，并设置负责人和轮换流程。
盘点时逐项记录身份来源、用途、负责人、凭据存放位置和停用方式。不要把密钥写进源代码、提示词模板或共享文档；应放在具备访问限制的密钥管理设施中。身份无法对应到负责人，或凭据长期无人维护的调用入口，应先限制或暂停，再确认归属。
权限按任务拆分，不按方便放大
模型服务的权限不只是“能不能调用模型”，还包括可选模型、可访问的数据源、可调用的外部工具，以及能否查看请求记录。按照最小权限原则，为每种任务设置必要范围。例如，知识问答服务只需读取经过授权的文档时，就不应同时获得修改文档或访问无关系统的权限。
可执行的权限检查
- 列出服务会调用的模型、检索库、插件和业务接口，并标明数据读写方向。
- 按用户或服务身份逐项验证允许与拒绝的操作，特别检查跨用户、跨项目访问。
- 为管理权限和日常调用权限分开设置审批与使用流程，紧急授权注明原因和到期时间。
- 每当业务用途、数据源或人员职责变化时复核权限；发现不再需要的授权及时撤销。
授权方式要与环境相符：小型服务可以从少量、明确的权限规则起步；多个团队共用平台时，应进一步按应用、数据范围和管理职责隔离。规则越集中，越便于审查，但配置错误可能影响更多调用，因此要保留变更审批和回退办法。
日志要能追责，也要避免制造新泄露
审计日志应回答几个实际问题：哪个用户或服务发起调用、何时调用、请求经过了哪些策略检查、使用了哪个模型或版本、是否调用外部工具、最终结果是允许还是拒绝。可同时记录请求关联标识、策略版本和错误类别，便于把一次调用与应用侧事件对应起来。日志访问本身也应受限，并记录谁查看或导出了日志。
默认不必把完整提示词和模型回答复制到普通日志。原文可能包含个人信息、访问令牌、合同内容或未公开资料。确有调查需要时，可将必要证据存入单独受控的记录区，设置审批、访问审计和到期清理规则；日常日志保留事件摘要及受控引用。留存期限应依据适用法规、合同义务和调查需要确定，不宜对所有数据一刀切。
把敏感数据保护放在请求前后
例如，内部知识问答可能同时接收员工问题并检索共享文档。应先确认用户有权读取被检索内容，再检查输入中是否包含不必要的个人信息或凭据；返回结果前，还要验证模型回答没有越过用户的数据权限。数据脱敏可以减少非必要暴露，但不能代替访问授权，也不能保证模型不会从上下文复述敏感内容。
- 明确哪些数据不应进入模型请求，优先在应用端拦截密钥、身份证件号码等高风险字段。
- 限制检索范围，并对文档设置与原系统一致的访问权限，避免用共享服务身份绕开用户权限。
- 核对服务商关于数据用途、保存和删除的条款与实际配置；不要仅凭产品名称推断请求是否用于训练。
- 用合成或已获授权的数据测试拒绝、脱敏和权限边界，再逐步开放真实业务流量。
将上述措施连成闭环，才能让大模型服务审计、访问控制与敏感数据保护落到日常操作：身份可追溯、权限可验证、事件可调查、数据有边界。先建立清晰台账和最小可行规则，再按风险补充自动检测与复核机制，通常比一次性堆叠功能更容易维护。
常见问题
是否应该记录完整提示词和回答？
不宜默认记录。先确定调查目的和必要字段；只有在确有业务或合规需要时，才受控保存原文，并限制访问和留存时间。
模型调用密钥多久轮换一次？
没有适用于所有环境的固定周期。应结合凭据风险、组织政策和服务能力设定；发生泄露疑虑、人员变更或用途终止时，应立即撤销或更换。
如何检查检索数据有没有越权？
用不同权限的测试账号查询同一类问题，检查检索结果和最终回答是否都遵循源文档权限；同时测试撤权后旧权限是否失效。
小团队从哪里开始？
先登记所有调用身份与负责人，收紧不必要权限，记录调用和策略决策，并明确敏感字段处理及日志访问规则。定期复核比单纯增加工具更重要。
