Skip to main content
在审计目标和范围足够明确、其他运营人员能够判断有效发现标准之后,再运行审计。

运行并检查

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

运行前准备

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

审查运行结果

从运行状态、会话覆盖情况以及模型分析是否已执行开始审查。随后逐条检查每项发现的严重程度、描述、证据会话、支撑查询及建议的预防路径。 使用发现状态功能对其进行确认、静默、驳回、解决、重开或分配处理。即便驳回某项发现,也应保留其证据;这些证据能说明当初做出该决定的原因。

解读空结果或延迟运行

当分析未能运行时,since_last 类型的审计会将未分析的窗口保留至下次成功运行。现有发现不会被自动关闭,因为跳过分析并不能证明故障已消失。

了解失败通知

运行失败或模型分析步骤失败时,系统将使用该审计配置的邮件收件人。若审计未配置邮件渠道,Failproof AI 将回退至组织级别的 alerts.email_default_recipients 设置,以确保静默故障的审计仍有上报路径。 组织必须已启用邮件功能且配置了 SMTP,否则失败事件仅会被记录日志,无法发送邮件通知。运行失败不会影响审计的固定计划锚点。 每次运行还会为每个代理使用的确切代理上下文存储一份合约快照。后续编辑不会更改早期运行所记录的证据标准。
不要直接根据未经验证的发现部署拦截策略。请先打开所引用的追踪记录,确认该规则能够将不安全行为与正常工作区分开来。