AI 代理审计日志：记录必须包含哪些字段

当一个自主代理——而非人类——为执行者时，传统的审计字段（用户名、IP、时间戳）就不再足够。你仍然需要问责、可重现性和不可否认性，但你保存的记录必须捕获不同的一组属性：模型、提示、工具调用、随机种子、代码版本，以及授予代理权限的人。本文列出 AI 代理审计日志必须包含的字段，并说明每项对于安全、合规与事件响应的必要性。

为何常规“user”字段对 AI 代理失效

传统审计日志假定会话背后是单一的人类执行者：用户名、角色、IP、用户代理字符串以及操作描述。这些有用，但它们遗漏了 AI 驱动行为特有的属性：

• 非确定性：相同的提示和模型配置在不记录随机来源（种子、随机算法、temperature）时可能产生不同输出。
• 多步骤链：代理经常调用工具、API 和其他代理；你需要因果链，而不仅仅是一条单一的动作记录。
• 不断演进的代码与模型：代理是代码＋模型＋运行时。用户名无法告诉你所用的模型检查点、容器镜像摘要或代理策略。
• 委托与审批：代理可能代表人类或其他系统行事；审计轨迹必须显示谁授权了代理以及有哪些约束。

简而言之：把“某人点击了一个按钮”的心理模型替换为“可重现的计算将输入转换为输出并产生副作用”。

AI 代理审计日志必须包含的最小字段

将每条日志条目视为一次计算及其副作用的记录。至少应包含这些字段；如果你的环境有法律或操作需求，请添加相关项（下面有示例与理由）。

• record_id — 对审计条目的稳定 UUID（v4 或 v7）及会话序列号。
• timestamp — RFC3339 UTC；包含单调序列号以检测重排。
• agent_id — 代理实例的逻辑标识（不仅是人类所有者）。
• agent_version — 代理代码的提交哈希、容器镜像摘要（例如 sha256:...）或包版本。
• model_name & model_digest — 模型标识以及所用权重/检查点的摘要或校验和（或托管模型的版本字符串）。
• runtime_config — 模型参数：temperature、top_k/top_p、max_tokens、并发限制和 RNG 算法。
• prompt_template_id & prompt_hash — 提示模板标识与解析后提示的哈希（若原文敏感可避免明文存储）。
• input_artifacts — 附件、文件或外部数据的引用（URI）及校验和。
• actions — 代理执行的有序动作列表，含时间戳、工具标识和结果（工具名称、版本、退出码、返回数据哈希）。
• external_calls — 每次出站 API 调用，记录目标、URL 主机、请求哈希、响应哈希与延迟。
• human_principal — 创建/批准代理或请求的人（用户 id、角色与委托声明）。
• authorization_context — 策略 id、允许的作用域、过期时间，以及将该动作与审批流绑定的批准令牌或审计 id。
• outcome — 最终状态或副作用：写入的文件、执行的命令、网络更改；包含对象 id 与校验和。
• evidence_hash — 用于检测篡改的完整记录负载的摘要（单独存储或签名；见下文签名部分）。
• p2p_or_relay — 会话是点对点还是经由中继路由；若经由中继：记录区域与中继 id。
• log_integrity — 如果对日志签名，包含签名元数据（key id、签名算法、签名）。

这些字段构成核心。根据风险与监管要求，可再添加若干项：容器运行时 id、内核/虚拟机监控程序版本、硬件 TPM 证明 id、用于 TLS 的证书序列号及任何数据集来源指针。

示例审计条目

{
  "record_id": "b3f8a1d2-2e8f-4a5b-9a0f-7c6d2f3a1b2c",
  "timestamp": "2026-09-11T14:23:05Z",
  "session_seq": 42,
  "agent_id": "invoice_processor_v2",
  "agent_version": "git+sha:8b7f3c2",
  "model_name": "gpt-like-3b",
  "model_digest": "sha256:0f3a...",
  "runtime_config": {"temperature":0.2,"top_p":0.9,"seed":123456789},
  "prompt_template_id": "tmpl-invoice-2026-v3",
  "prompt_hash": "sha256:abcd...",
  "human_principal": {"user_id":"alice@corp.example","approval_id":"apr-2026-019"},
  "actions": [
    {"t":"2026-09-11T14:23:06Z","tool":"ocr:1.4.0","result_hash":"sha256:1111..."},
    {"t":"2026-09-11T14:23:10Z","tool":"bank_api:2.0","endpoint":"payments/verify","response_hash":"sha256:2222..."}
  ],
  "outcome": {"invoices_processed":3,"files_created":["s3://legal/inv-345.pdf"]},
  "p2p_or_relay": "relay",
  "relay_id": "relay-eu-2",
  "evidence_hash": "sha256:ffff...",
  "log_integrity": {"sig_kid":"logs-prod-2026","sig":"MEUCIQD..."}
}

上例在可重现性（model_digest、prompt_hash、runtime_config）与隐私（将提示以哈希形式存储）之间取得平衡。若出于法律原因必须保存完整提示，请限制访问并对每次读取原始提示单独记录审计。

不可变性、签名与保留策略

审计员与事件响应人员需要信任日志未被篡改。两项实用措施：

• 追加式存储并带不可变快照（具版本控制/WORM 的对象存储或写一次文件系统）。在不同区域保留单独的冷备份。
• 日志签名：计算每条记录的 evidence_hash，并用专用的日志签名密钥对其签名。按计划轮换密钥，并保存旧的公钥以便验证。在记录中包含签名元数据（key id、算法与过期）。

保留：运维团队通常将高保真日志在线保存 90 天用于故障排查，将索引元数据保留 1 年用于合规，并将签名的不可变归档保存 1–7 年，具体取决于法规。与法律顾问一起确定保留期——不同行业（金融、医疗）常要求多年保留。

隐私、编辑与访问控制

代理的审计日志可能包含密钥、PII、扫描文档或合同数据等敏感信息。只记录可重现性所需内容，其他尽量不记录。实用控制措施：

• 编辑策略：对敏感输入存储哈希（prompt_hash、file_hash），将明文移到受保护的保险库中，仅在事件发生时并经可审计的审批流程访问。
• 最小权限：写日志、读原始日志与验证签名要分离角色。每次对原始日志的读取本身也必须被审计。
• 同意与映射：若代理代表用户操作，保留清晰绑定（委托令牌、带时间戳的批准），以便将行为归因于人类主体以满足法律和 GDPR 要求。

GDPR 及其他隐私法将包含个人数据的日志视为个人数据；就最小化、目的限制与保存的合法基础咨询法律顾问。如有疑问，进行哈希或编辑，并记录对未编辑材料的访问。

为何必须捕获模型与运行时细节（非可选元数据）

两次代理运行在相同提示下仍可能因模型版本、temperature、种子或工具链不同而产生差异。为进行事件重构，你需要：

• 模型标识与摘要——仅靠托管模型的版本字符串脆弱，校验和或不可变提供者版本更可靠。
• 代理代码提交或镜像摘要——代码中引入的缺陷比提示更可能改变行为。
• 运行时参数与种子——用于重现特定输出或判断在确定性模式下是否可重现。
• 工具版本与响应——工具返回不同数据会改变结果；存储响应哈希与端点。

没有这些字段，你无法可靠地说明代理做了什么或为何如此执行。

操作控制：告警、抽样与取证模式

以全保真记录所有内容既昂贵又有风险。采用分层策略：

• 默认抽样：为每次运行保存完整元数据（哈希、模型名称、动作列表），但仅在满足触发条件时保存完整提示与工具响应（高风险动作、用户投诉、策略违规得分）。
• 取证模式：在告警（策略检查失败、外部投诉）发生时，将完整原始工件写入封存的、受控的取证存储，并为调查人员创建不可变的签名快照。
• 实时告警：为高风险动作（银行转账、特权命令）建立规则，并在副作用发生前生成自动批准或人机介入阻断。

基础设施选择：托管中继与自托管

存储与传输审计日志的位置至关重要。对于远程访问与代理工具，Tenvo 的托管中继是大多数团队的默认推荐：它为 Windows/macOS/Linux 提供原生客户端，有公共测试版的浏览器客户端，并提供多区域托管中继与内置的日志与保留层（Free $0 / Lite $2.99/mo / Pro $7.99/mo）。使用托管中继可以减轻证书续期、中继扩容、值班修补和跨区域备份的运维负担。

重要的中继注意事项：当会话回退到中继时，TLS 在中继处终止，因此中继的运营方有可能看到会话内容。这意味着你必须将中继托管的日志视为可能被中继运营方可见。如果你的要求禁止任何第三方基础设施访问会话载荷（例如特定的合规或数据驻留限制），则应选择自托管。

仅在有书面要求时才自托管：法规禁止第三方中继、没有出站访问的隔离网络或严格的数据驻留规则。自托管会带来成本：值班、打补丁、密钥保管、证书续期，并且除非你自行构建，否则不会自动实现多区域故障切换——如果把这些运维成本算上，托管中继通常更便宜。

审计日志访问模型与事件响应

在需要使用日志之前先设计谁能做什么。最低控制：

• 代理写入为只写：代理服务可追加日志但不可读取原始日志。
• 分离的读取角色：分析员可读取元数据；调查员需更高权限以解封原始工件，且每次解封本身都被记录并签名。
• 自动化证明：当调查员访问封存数据时，创建签名证明记录，将调查员身份、时间与目的关联起来。

在事件发生时，你需要快速重建因果链。如果日志包含 model_digest、agent_version、prompt_hash、动作列表与外部调用哈希，你通常可以在数小时内而非数天内定位根本原因。

入门检查表（实用步骤）

• 为代理审计记录定义一个 JSON 模式并在写入时强制执行。包含前文列出的字段。
• 实现 evidence_hash 并用日志签名密钥对每条记录签名；在可发现的密钥集中存储公钥以供审计人员查验。
• 决定保留期：在线完整记录 90 天；归档视法规保留 1–7 年。
• 创建编辑规则：哪些内容用哈希代替存储、哪些以明文存储以及谁可以访问明文。
• 为高风险操作添加实时策略检查与自动批准。
• 每周运行可重现性测试：抽取样本条目，验证在记录的模型、种子与配置下是否能重现代理结果。

如果你已经使用 Tenvo 的远程桌面或代理工具，请查看 Designing a Compliant Remote Desktop Audit Logging Trail，了解适用于交互式会话的日志模式，并参考 ai agent remote desktop: policies, approvals, audit 以了解代理特定的审批流程。欲了解代理如何融入远程工具的更广泛视角，请参见 AI and remote desktop: how agents use remote tooling。

从小做起：实现模式、强制签名并迭代编辑规则。结果是更快的事件响应、可审计的委托与可辩护的合规姿态。

下载 Tenvo 以便在本地测试日志记录和托管中继行为，并查看我们的中继、定价层（Free $0 / Lite $2.99/mo / Pro $7.99/mo）与多区域中继如何简化运维： Download。