模型调用审计如果只记录时间、接口和模型名，发生越权或错误动作时仍无法回答“谁代表谁做了什么”。企业调用链中可能同时出现用户、应用、服务账号、Agent和工具执行身份，某一跳还会发生权限转换。审计落地必须把主体关系、必要字段和业务影响串起来，同时控制敏感内容采集与查询权限。

治理边界：审计为了复盘与追责保留必要事实，不默认记录完整提示、响应、凭证或无关业务数据。

一条请求可能包含多层主体关系

用户在应用中发起请求，应用用服务账号调用模型，Agent根据模型建议调用工具，工具又以另一身份访问目标系统。最终动作看似来自工具账号，真实业务意图来自用户，权限授予和执行责任则分布在应用、Agent和目标系统之间。

审计要区分发起主体、代表关系、执行主体和批准主体。用户提出需求不等于批准所有后续动作；Agent决定调用工具也不等于拥有目标系统权限；工具执行成功更不代表动作符合业务规则。每一跳都应能说明身份来源和权限边界。

服务账号共享会增加追责难度。若多个应用共用一个凭证，底层日志只能看到同一主体。平台需要顺利获得受信任的应用标识、请求上下文和目标系统记录补充关系，同时防止上游伪造用户身份。身份传递必须有校验，不能只信任普通请求字段。

主体链比一条请求日志更重要

下图把用户、应用、Agent、工具和目标系统画成接力链，旁侧字段带记录每一跳的身份、版本、策略与结果。审计重点是关系，不是把所有文本堆到一条日志里。

主体链中任何一次代理都应有授权依据。例如应用是否被允许代表该用户调用模型，Agent是否能选择该工具，工具是否能执行写操作，目标系统是否再次校验资源权限。上游顺利获得不能替代下游授权。

企业Agent的工具与权限边界可参考 企业Agent上线生产边界 。模型调用审计需要进一步保留这些边界在实际请求中的判定结果，让事后能够区分“模型建议”“工具请求”和“系统已执行”。

能还原主体关系，才有资格讨论责任；只有技术账号，追责通常会停在系统边界。

审计字段按身份、对象、策略、结果和影响分组

身份组记录发起用户或服务、应用、租户或项目、Agent和执行账号的受控标识。应优先使用稳定内部ID，展示时按权限解析名称。避免在所有日志中复制姓名、邮箱等个人信息。

对象组记录模型、提示或配置、工具、目标资源和必要数据范围。字段要能关联版本，但不必保存全部内容。对于知识检索，可以记录索引或数据域标识；对于工具动作，记录工具版本与目标资源类型。

策略组记录身份验证、授权、内容策略、配额和人工确认等结果。只写“被拒绝”不够，需要说明由哪类策略在何处作出决定，同时避免泄露可被绕过的敏感规则细节。

结果组记录调用状态、错误类别、模型或工具返回状态和最终业务动作。影响组说明是否产生写入、通知、费用、数据变更或外部传播。一个模型响应成功但工具执行失败，两个状态必须分开。

字段设计不追求一次覆盖所有场景。先从高风险应用建立最小集合，再根据复盘需要扩展。每次新增字段都要确认来源、可信度、权限和留存责任。

入口、网关与目标系统各自保存不同事实

模型入口或AI网关通常掌握调用身份、模型路由、配额、策略和服务结果。入口治理可结合 AI网关入口治理 理解，但网关看不到应用内部业务意图，也不一定知道工具最终是否执行。

应用层掌握用户场景、会话、提示编排和业务判断。它应生成可传递的请求标识，并记录必要的用户授权与人工确认。应用不能将敏感内容无边界复制给网关，只传递诊断和审计所需的字段。

目标系统掌握最终资源权限和变更结果。即使上游Agent已经判断可以执行，目标系统仍应按自己的权限规则校验，并记录执行账号、对象和结果。追责时三处证据顺利获得请求和业务动作标识关联。

不存在单一系统拥有所有真相。审计平台的价值是建立索引与关系，而不是把所有原始数据集中到一个风险更大的仓库。证据真源和查询入口要在设计中写清。

模型建议与实际动作必须分开记录

生成模型可能提出建议、生成工具参数或请求调用，但业务影响通常由工具和目标系统产生。审计若只记录最终结果，会误以为模型直接执行；若只记录模型输出，又无法确认动作是否真正发生。

对于读操作，应记录访问对象和授权结果；对于写操作，应增加人工确认、策略批准或业务流程标识；对于高风险动作，应允许在执行前阻断。模型建议、工具请求、策略判定、人工批准和执行结果构成完整时间线。

重试和补偿也要可见。工具超时后Agent可能再次调用，目标系统可能已经完成第一次动作。没有幂等或状态查询时，重复执行会造成额外影响。审计记录要帮助事件人员判断每次尝试，而不是只保留最终成功。

异步动作同样需要关联。模型调用结束后，任务可能进入队列稍后执行；入口请求与后台任务必须保持关系。否则用户会话中看不到最终影响，后台日志也找不到业务来源。

查询权限、脱敏和留存决定审计是否可持续

审计数据可能包含身份、业务对象、风险标签和运行信息，本身就是敏感资产。日常运维、应用排障、安全调查和正式审计需要的范围不同，不能给所有角色相同权限。高权限查询和导出也要被审计。

完整提示和响应是否保存，要依据场景和制度决定。可以默认记录元数据、哈希、长度、类别和受控样本标识；确需查看原文时，顺利获得审批进入原系统或受保护存储。凭证、令牌和密码不得进入审计日志。

留存期限要结合调查、业务、合同和适用制度确定，不存在所有企业通用的时间。到期后执行删除或归档，并验证索引、备份和导出副本同步处理。只清理主库而保留无限备份，仍然违背最小化原则。

审计证据还要防止无痕修改。可采用权限隔离、变更记录、完整性校验和受控导出等方式，具体实现以企业架构为准。本文不把某种存储技术写成唯一方案。

用越权和异常工具调用演练追责链

第一类场景是用户无权访问某数据，应用或检索层应阻断。审计要显示用户、应用、目标数据域和策略结果，不记录不应暴露的内容。若请求仍到达模型，也要看到在哪一层失守。

第二类场景是Agent尝试调用超出范围的工具。平台应记录模型或编排产生的请求、工具权限判定和最终未执行状态。仅保存“工具失败”无法区分安全阻断与技术错误。

第三类场景是工具超时后重复调用。审计人员从最终业务变更反查每次请求、重试和批准，确认是否重复产生影响。演练在隔离环境或无副作用对象上进行，并设置停止条件。

演练结束后，让未参与现场的安全或审计人员根据记录复盘。如果仍需向开发者口头询问主体、版本或动作，说明字段和关系不完整。若复盘必须查看过多敏感原文，则要优化最小证据设计。

追责不是找一个人承担所有问题

责任判断应基于控制范围。用户可能提出不当请求，应用可能错误传递权限，Agent编排可能选择错误工具，平台策略可能缺失，目标系统也可能未执行最小授权。审计给予事实，管理和专业角色根据事实判断责任。

因此报告应区分事件事实、控制缺口和改进责任。把所有问题归给模型会掩盖系统设计，把所有问题归给用户又会忽略平台保护义务。多方责任可以同时创建，并对应不同修复动作。

审计的最终价值是改进控制：补充身份映射、缩小工具权限、增加人工确认、修复重试、更新运行手册或调整留存。若记录只用于事后问责而不反馈系统，问题仍会重复。

下一步建议

选择一个具有工具调用的低风险应用，从用户发起到目标系统执行画出主体链。为每一跳填写身份来源、授权、版本、策略、结果和影响，删除无法说明必要性的敏感字段。再演练一次越权和一次重复调用，让独立人员根据记录复盘。复盘断点就是下一轮审计建设需求。

常见问题

模型调用审计是否必须保存全部对话内容？

不必须，也通常不应默认这样做。全部对话可以帮助某些质量调查，却会扩大个人信息、商业数据和内部知识的暴露与留存。多数审计问题先需要的是主体、版本、策略、工具、状态和影响；原文只在必要且有权限时受控回查。

企业可以按场景分层：低风险测试环境保留已授权样本，生产默认保留元数据和风险标签，高风险事件顺利获得审批调取脱敏或原始证据。任何层级都不记录凭证和密钥。保存范围、用途和期限应可解释，并在系统退出或到期时执行清理；清理后还要核对索引、导出和备份副本，避免原文从主库删除却在旁路长期留存。

Agent代表用户调用工具时，责任归谁？

不能只按最终技术账号判断。需要查看用户是否提出该目标、应用是否正确传递身份、Agent是否在授权范围内选择工具、是否需要人工确认，以及目标系统是否执行了自己的权限校验。每个控制点由不同角色负责，事件可能有多方责任。

设计上应让Agent使用受限身份或短期授权，保留代表关系和批准证据。高风险动作不应仅凭模型输出执行。审计系统给予事实链，最终责任由企业制度、合同和专业判断确定，不能由日志字段自动宣判。复盘后还要把失效的授权或确认点转成控制改进，并重新演练。

已有API网关日志，还需要专门的模型调用审计吗？

取决于网关日志是否覆盖所需对象。API网关通常能记录身份、路由、状态和流量，对模型入口很重要；它可能看不到提示或配置版本、Agent工具关系、模型质量策略和最终业务动作。若能顺利获得扩展字段与其他系统关联，没必要重复建设一套日志。

评估时从真实事件反查：能否识别用户和应用，能否看到模型与策略，能否关联工具执行和目标资源，能否按权限查询与导出。缺失的是字段、关系还是流程，应分别补齐。不要因为产品名称不同就重复采集同一份敏感数据。补齐后用越权和重复调用各复验一次，确认日志关系不是只在正常请求中创建。