🧪 Beta — 能力已可用，接口契约可能微调。
审计与合规报告
读完本指南，你将能够：
- 从任意一条业务日志倒查回"最初是谁批准了这件事"
- 把 Agent 的授权与访问行为纳入你既有的合规报告流程
- 当场答上审计师最常问的三个问题
前置条件
三种查法
正查：从授权看后续
已知 audit_id 或 grant_id，看这次授权后面发生了什么——签发、兑换、访问、吊销、过期。用于复盘"这次授权被怎么用了"。
倒查：从业务日志追回授权
已知一条可疑的业务操作（你的日志里带着 audit_id），倒查回最初的授权：谁批准的、批准了什么范围、什么时候批的、现在还有效吗。
这是事故响应最常用的一条路径，也是"资源侧必须记 audit_id"的全部理由——少了它，链条到你的 API 边界就断了。
按主体查：某个人/某个 Agent 的全部活动
- 按
sub查：某个用户授权过哪些 Agent、各自什么范围 - 按
act.agent_id查：某个 Agent 代表过哪些人行动
用于定期巡检与离职交接——人走了，他授权过的 Agent 还在跑，这是最常见的治理漏洞。
一份合规报告需要什么
不同框架的措辞不同，但要素高度重合。把下面五项凑齐，多数审计场景都能应对：
| 要素 | 从哪来 |
|---|---|
| Agent 台账（有哪些、谁负责） | 注册记录与责任人（见 注册和管理你的 Agent） |
| 授权记录（谁批准了什么、有效期） | grant_id 维度的授权事件 |
| 访问记录（实际做了什么） | 你的业务日志 + 令牌里的 sub / act |
| 权限最小化证据（申请 vs 实际授予） | grantedScopes 与请求 scope 的对比 |
| 收权记录（撤销、停用、过期） | 审计链上的终止事件（见 吊销与应急处置） |
报告期与留存
审计数据的留存期限、访问权限、导出格式按你所在行业的要求配置。建议至少覆盖你最长的一个审计周期，并对导出操作本身也留痕。
审计师会问的三个问题
问：这个 Agent 是谁批准上线的？它现在还该存在吗？ 答：台账里有注册记录、技术负责人与业务归属人、审批记录。"还该存在吗"由业务归属人在巡检时给出决策——这就是为什么归属人是必填项。
问：上个季度它访问了哪些客户数据？以谁的名义？ 答：按 act.agent_id 查该 Agent 的全部活动，每条都带 sub（代表谁）与 audit_id（依据哪次授权）。业务细节在你的日志里，授权依据在审计链里，两者用 audit_id 对上。
问：如果它出问题，你们多久能停掉？ 答：分层回答，别给一个笼统的数字——停发新授权是即时的；已签发令牌以其有效期为准，而你们的策略是任务级只给分钟级有效期。完整口径见 吊销与应急处置。这个问题上诚实比漂亮重要：说得比实际能力好，POC 现场会被当场验证。
常见问题
审计数据能导出到我们自己的 SIEM 吗？ 审计事件可按 API 拉取后送入你的日志平台。建议以 audit_id 为关联键，与你的业务日志做联合查询——这样一次检索就能同时看到"授权依据"和"业务后果"。
用户能看到自己授权过什么吗？ 建议在你的应用里提供"我的授权"页面：列出该用户当前有效的授权（Agent、范围、到期时间）并提供撤销入口。数据来自按 sub 的查询。
Agent 的行为记录和人的操作记录会混在一起吗？ 不会混淆——只要令牌里的 act 被记录下来，就能区分"张三本人操作"与"某个 Agent 代表张三操作"。这正是双主体设计的价值（见 Token 与 Claim 参考）。
下一步
- 审计与追责链 —— 链条的构成与字段。
- 保护你的 API：资源侧集成 —— 把链条接进业务日志。
- 吊销与应急处置 —— 查清之后怎么止损。