Skip to main content
在审计目标和范围足够明确——即另一位操作员能够判断什么是有效发现——之后再运行审计。

运行并检查

  1. 前往 Analyze → Audits,打开审计,选择 run now。排队响应表示调度器即将启动该审计。
  2. 打开新的运行记录,查看其状态、时间窗口、持续时间、发现数量和报告。
  3. 选择一个证据会话以打开精确的追踪记录。
  4. 返回审计页面以编辑设置、禁用计划,或查看历史运行记录。 审计详情页面,展示已开放的发现、上次和下次运行状态、扫描窗口、上下文、立即运行控件以及按排名显示的发现。

运行前准备

  • 确认所选时间窗口内存在会话。
  • 验证环境和 Agent 过滤条件。
  • 检查参考上下文是否为最新版本。
  • 确保目标描述的是一种故障模式,而非预期结论。

审查运行结果

首先检查运行状态、会话覆盖范围,以及模型分析是否已执行。然后逐一检查每条发现的严重程度、描述、证据会话、支持性查询以及建议的预防路径。 使用发现状态来确认、静音、忽略、解决、重新开启或分配工作。即使发现被忽略,也应保留证据;它记录了做出该决定的原因。

解读空结果或延迟运行

当分析未能运行时,since_last 审计会将该未分析的时间窗口保留至下一次成功运行。现有发现不会被撤销,因为跳过分析并不能证明故障已消失。

理解失败通知

运行失败或模型分析步骤失败时,系统会使用审计配置的邮件收件人。如果审计未配置邮件渠道,Failproof AI 将回退到组织的 alerts.email_default_recipients 设置,以确保静默失败的审计仍有升级路径。 组织必须启用邮件功能,且必须配置 SMTP,否则失败信息仅会被记录,无法发送邮件。运行失败不会改变审计的固定计划锚点。 每次运行还会将各 Agent 使用的精确 Agent 上下文 存储为合约快照。后续编辑不会改变早期运行中记录的证据标准。
不要直接根据未经核实的发现部署阻断策略。请打开引用的追踪记录,确认该规则能够将不安全行为与正当操作区分开来。