Hokutoman00/aegis-caseops-uipath

# Aegis CaseOps — 基于 UiPath Maestro 的受管安全事件修复 嘈杂的安全警报转化为受管、经人工批准的修复 —— 其裁决不可被任何 LLM 触及，且任何人都可以对其进行重审。 **UiPath AgentHack 2026 提交作品** · 赛道：Maestro BPMN ## 为什么 安全自动化的失败有两种方式：太慢，或者太容易草率触发。CaseOps 围绕四个声明的不可变量构建，使得 pipeline 足够可信以执行操作： 1. **未经人工批准不进行修复** — 需要批准的路径在结构上是进入修复的唯一 BPMN 路径。 2. **信息缺口原样传播** — 每个失败的富化工具都会被记录，并在接收、批准和复盘阶段原样展示。 3. **只有确定性核心编写裁决** — LLM 助手是只读的，通过三层进行强制执行（prompt/工具限制、BPMN 变量绑定、盲评重审）。 4. **统一的输入 schema** — 所有场景共享相同的警报契约。 ## 运营影响（说明性模型） *带有既定假设的说明性模型 —— 并非实测的生产数据。* 对于每周处理约 1,000 个警报的中型 SOC，假设其中约 60% 为可自动关闭的低危噪音，且每个警报需要约 15 分钟的手动分诊： - **每周约 150 个分析师工时**从复制粘贴式的分诊工作转移到真正的调查中（每周约 600 个低危警报通过确定性流程处理）。 - **高昂的失败模式被从设计上消除，而非依靠监管：** 单个不稳定的高置信度信号无法自动隔离生产服务器 —— 印证上限（单一信号 ≤ 0.55）在结构上无法自动升级，而修复*只能*通过人工批准关卡触发。 - **升级事件在提交时已准备好决策：** 推荐操作*和*明确的缺口已预先渲染，因此分析师可以基于完整的认知上下文进行批准，而无需重新构建上下文。 采用论点：CISO 可以部署此方案，因为裁决是确定性的、可重审的，并且 LLM 被证明被排除在决策之外 —— 这三点通常正是阻碍自动化介入事件响应的障碍。 ## 架构 ``` alert JSON ──▶ API workflow ──▶ Maestro BPMN process │ [task_triage] caseops-agent (deterministic, no LLM) │ XOR gateway ┌──────────────┬───────────────┬──────────────────┐ low_risk_close request_more_ confidence_gap_ escalate_for_ │ evidence review containment │ │ │ queue: caseops-approval │ (human approves with │ evidence AND gaps) │ │ │ remediation-stub (mock) └──────────────────┬─────────────────────────────┘ postmortem-agent ──▶ markdown (gaps included) side channel: M4 analyst assistant (Agent Builder + Context Grounding) — explains cases with citations; cannot write the verdict ``` ## 组件 | 路径 | 描述 | |---|---| | `caseops-agent/` | 确定性分诊核心（UiPath coded agent，原生 `uipath` SDK）。风险点 + 受印证上限约束的置信度：`min(avg, 0.40 + 0.15 × signals)` —— 单个信号永远不能超过 0.55，因此单一信号永远不会触发自动升级。 | | `caseops-agent/verify_verdict.py` | **盲评器。** 从原始警报重新计算裁决，并对五个裁决字段进行 diff（差异比对）。被篡改的裁决 → 非 0 退出。 | | `caseops-agent/evaluations/` | 一个自定义的 `uipath eval` 评估器，对全部三个演示裁决进行评分；一个故意篡改的预期结果集会导致其中一个案例得分低于 1.0，证明该评估器并非橡皮图章（形同虚设）。 | | `maestro/caseops-process.bpmn` | Maestro 流程：一个 XOR 网关，四条条件边，批准关卡。导入 Studio Web 的 Agentic Process 设计器中 0 个验证问题。 | | `remediation-stub/` | 模拟修复（工单 + 日志）。演示中无破坏性操作。 | | `postmortem-agent/` | 确定性复盘渲染器。缺口部分始终渲染；即使在输入格式错误时也能正常运行。 | | `demo-data/` | 三个场景：D1 低危自动关闭，D2 关键升级且批准时可见信息缺口，D3 工具降级时的置信度缺口审查。 | ## 自行尝试重审 ``` python -m venv .venv && .venv/Scripts/pip install uipath pytest # 运行完整套件（按目录） .venv/Scripts/python -m pytest caseops-agent/tests remediation-stub/tests postmortem-agent/tests # 从原始 alert 重新计算并验证 verdict .venv/Scripts/python caseops-agent/verify_verdict.py demo-data/incident-case-001.json triage-001.json # → "verdict intact" (exit 0)。现在编辑 triage-001.json 中的任何 verdict 字段： # → "VERDICT TAMPERED (1 field(s))" (exit 1) ``` 一个包含 38 个案例的 pytest 测试套件固定了演示场景、所有四个不可变量（带负面断言）、严重性阈值边界（在合成案例上为 4/5、8/9、13/14）以及篡改检测。 ## 严重性模型（以及为什么这些阈值不是任意的） 每个信号携带 0–5 的严重性。`medium ≥ 5` = 一个强信号 (4) 加上任何印证；`high ≥ 9` = 两个强信号；`critical ≥ 14` = 三个独立的攻击阶段。这已通过独立于演示夹具的边界测试验证。在 high/critical 级别上，置信度低于 0.7 始终会重新路由到分析师审查。 ## 使用 coding agent 构建 由 Claude Code 端到端设计和实现：设计文档 → 对抗性设计审查（盲评器） → TDD。提交历史即是审计追踪。 ## 许可证 MIT — 见 [LICENSE](LICENSE)。

标签：BPMN, LLM集成, UiPath, 告警分诊, 安全事件响应, 安全规则引擎, 安全运营, 扫描框架, 逆向工具