审计日志

审计日志会记录组织内每一次状态变更操作——包括角色分配、引擎编辑、API 密钥签发和计费变更——并以可搜索、可筛选的时间线形式呈现。该功能随 Enterprise 方案提供，并与 角色与权限 一并可用。

这份日志在数据库层面是仅追加的：应用连接无法更新、删除或截断审计记录。写进去的内容，就会一直保留。

记录内容#

每个事件都会记录操作者、操作、目标，以及该请求到达时的 HTTP 上下文。

涵盖的操作#

事件会按类别归组，与仪表板中的筛选项保持一致。

如何访问日志#

只有在你的组织启用了相应权益后，组织侧边栏中才会显示 审计日志 入口。进入后，你会看到：

• 可筛选列表——可按操作者、操作类别、目标类型和日期范围缩小结果。系统会阻止未来日期，且结束日期始终 ≥ 开始日期。
• 无限滚动——最新事件优先显示；向下滚动时会加载更早的事件。
• 详情面板——点击任意一行，即可查看完整元数据、请求 ID、IP 和用户代理。
• 刷新——拉取最新事件，同时保留当前筛选条件。筛选器和当前打开的事件也会同步到 URL，因此任何视图都可以分享。

谁可以查看#

访问该页面需要同时满足两道条件：

1. 权益——必须为组织启用 audit-logs 功能（Enterprise 方案）。
2. 权限——查看者的 角色 必须包含 org:view_audit_logs。预置的 Full Access 角色默认包含该权限；Owner 始终拥有此权限。

没有该权限的成员看到的将是“无访问权限”页面，而不是时间线。若组织未启用该权益，成员则会看到付费墙。

可察觉篡改#

审计日志不只是做记录——它在事后也具备相当强的抗篡改能力。

• 数据库层面的仅追加。 安装该表的迁移会对 API 角色执行 REVOKE UPDATE, DELETE, TRUNCATE。无论是未来新增的代码路径、bug，甚至 SQL 注入，只要试图修改行，都会在生效前被 Postgres 直接拒绝。
• 单调递增序列。 每一行都带有一个严格递增的 seq 列。审计人员检查这条序列时，可以通过缺口识别删除行为。

这已经足以满足 SOC 2 风格的控制要求。但它无法防御持有生产数据库直接凭据的攻击者——如果你需要更强的防护方案（独立 owner 角色、WORM 镜像），我们也可按需提供。

保留期限#

默认情况下，审计事件会永久保留。Enterprise 支持自定义保留周期——通常为 1 年、3 年或 7 年。如果你因合规或安全问卷需要特定的保留策略，请联系我们。

未涵盖的内容#

以下是 v1 版本中几项有意设定的边界：

• 尽力写入，而非事务性写入。 事务性写入已列入近期路线图。审计事件会在其描述的操作完成后写入——而不是与该操作处于同一个数据库事务中。在极少数故障场景下（操作成功，但随后审计写入失败），可能会出现操作已发生、却没有对应事件的情况。
• 某些操作类型尚未接入。 引擎成员变更、集成的连接 / 更新 / 断开、模型配置编辑、计费订阅变更，以及批量内容操作（CSV 上传、createMany / updateMany / deleteMany）目前还不会生成事件。相关操作词汇已预留，因此一旦接入，它们会出现在现有筛选类别下。
• 读取操作不会被审计。 查看审计日志本身、浏览引擎请求日志或下载词汇表，都不会生成事件。只有状态变更操作才会被记录。
• 暂不支持导出。 目前审计数据仅通过仪表板展示。CSV 导出、SIEM webhook 和 S3 镜像已在路线图中——如果你需要这些能力，请告诉我们。
• 没有引擎范围视图。 组织内所有审计事件都汇总在同一条时间线上。你可以按目标类型或目标 ID 进行筛选，以缩小范围。
• 没有实时尾流。 列表仅会在手动刷新或点击 刷新 时更新——不提供 WebSocket 流。

后续步骤#