HOL Guard — AI agent antivirus and runtime protection
HOL Guard — AI agent antivirus and runtime protection
一句话结论
HOL Guard 把 AI agent 的安全边界从“事后扫描代码”前移到本地运行时：对 shell、文件、MCP、prompt、tool result、package install、plugin/skill/config 等事件做 allow / block / approve / receipt 处理。它值得进入 wiki，不是因为可以立刻安装，而是因为它把 Harness-Engineering 中反复出现的 effect-boundary control 具体化为一个跨宿主的本地安全层。
为什么对用户重要
用户的 Hermes / llm-wiki 工作流已经包含 cron、文件写入、网页抓取、raw/source 入库、向量重建和可能的发布动作。随着外部 skills、MCP servers、hooks 与 coding agents 增多，风险不再只是“模型写错代码”，而是：技能供应链、MCP 工具描述注入、secret 读取、网络外传、危险 shell 命令、过宽配置共同形成行动面。HOL Guard 的价值在于把这些面统一到 runtime policy 和 security receipt，而不是散落在 prompt 纪律里。
机制 / 一阶原理
HOL Guard 的核心不是替代 sandbox，而是补齐 sandbox 看不懂 agent intent、传统 scanner 看不到运行时工具链的空隙。它通过 agent adapter / hook / proxy / launch overlay 捕获支持的事件，并用一套本地 policy 判断：安全动作放行，已知威胁阻断，模糊动作转人工审批，同时记录 inventory changes 和 security receipts。README 明确说 enforcement depth 会随 agent 与 event type 变化，这一点对评估很重要：同名“支持 Hermes/Claude/Codex”不等于所有工具调用都有同等强制力。
与既有 wiki 概念的关系
- 对 Harness-Engineering：它是 effect boundary 上的 runtime guard，与 claimproof-evidence-gated-agent-claims 的最终声明门禁互补；前者管行动，后者管报告。
- 对 External-Agent-Skills-Design-Patterns：它把 skill/plugin/MCP 接入提升为 supply-chain admission 问题，要求外部包在执行前被扫描、授权和记录。
- 对 Context-Engineering：policy、approval、receipts 也应成为任务上下文的一部分；未来回答“我为什么没执行某动作”时应能引用 guard verdict，而不是只说“为了安全”。
对 Hermes / llm-wiki 的可执行启发
- 为外部 skills/MCP 维护轻量 admission record：来源 URL、commit/hash、权限、脚本、联网、secret access、是否需要人工审批。
- 将 wiki radar 的未入库理由继续细分：
low-depth、duplicate、unverified、security-review-needed，避免把安全 HOLD 和低价值拒绝混在一起。 - 高风险自动化动作不要只依赖 cron prompt；至少应有文件路径 allowlist、网络/发布动作 receipts、以及可复查的 post-effect verification。
失败模式 / 边界
- README 证据还不足以证明所有集成的真实拦截效果；需要支持矩阵、实际 hook 测试和 false-positive / false-negative 数据。
- 运行时 guard 可能制造 approval fatigue；如果规则太宽，用户会被频繁打断；如果规则太窄，危险链会漏过。
- local vs cloud 同步会带来额外隐私/运维权衡。对个人 wiki，默认应先学习设计模式，不急于安装执行。
写入记录
- 2026-08-09 09:00 CST：新增 HOL Guard source note，提炼 runtime protection、skill/MCP supply-chain admission 与安全 receipt 对 Hermes harness 的启发。