# HOL Guard: a runtime antivirus for AI agents, MCP servers and plugins > HOL Guard is a local-first Python CLI that reviews shell commands, file access, package installs and MCP tool calls before an agent runs them. It covers many agents, but enforcement depends on the hooks each one exposes. **hashgraph-online/hol-guard** — Open-source antivirus for AI agents: block risky tools, secret access, prompt injection, malicious packages, MCP servers, plugins, and skills at runtime. - Repository: https://github.com/hashgraph-online/hol-guard - Website: https://hol.org/guard - Stars: 681 · Forks: 116 - Language: Python - License: Apache-2.0 - Published: 2026-09-10 · Updated: 2026-09-10 · Language: en - Canonical page: https://hysenlabs.com/projects/hashgraph-online-hol-guard ## What HOL Guard actually guards Coding agents now execute shell commands, read files, install packages and call MCP tools on the developer's own machine. HOL Guard sits in front of those actions. The README describes it as a local-first security layer for AI agents, tools, plugins, skills, MCP servers and package installs, and the protection table lists six surfaces: shell commands and file access, package installs, plugins and agent configuration, MCP servers and tools, prompts and tool results, and approvals with local receipts. Each action is allowed, blocked, or routed to an approval prompt according to policy. The audience is narrow but real: developers who run agents like Codex, Claude Code, Cursor, Cline, Gemini CLI, OpenCode or OpenClaw against a working directory that also contains an SSH key, a cloud credential file, or a package manifest. The project is Apache-2.0 and runs locally without an account; Guard Cloud is optional and adds shared history, team policy and fleet management. That split matters, because it means the default install does not require sending decision data anywhere. ## Hooks, proxies and the support matrix Guard is not a sandbox. It does not intercept syscalls. It connects through three mechanisms the README names: native agent hooks, managed MCP proxies, and launch integrations. For Codex, for example, Guard installs native pre-tool hooks and refuses a managed launch if those hooks are missing or disabled. That is a deliberate design choice: rather than guessing at agent behavior, Guard hooks into the events each agent already emits. The consequence is that coverage is uneven by construction. The README says plainly that coverage depends on the events each agent exposes, and points to docs/guard/harness-support.md for enforcement, approval delivery and failure behavior per integration. If you are choosing between two agents and security is part of the decision, that document is more useful than the headline list of fifteen supported agents. A managed MCP proxy, for instance, sees tool calls that pass through it, while a pre-tool hook sees what the agent chooses to report. Neither is the same as a container boundary. Decision data lands in two places: an approval center for pending requests, and local receipts for decisions already made. The CLI exposes both through hol-guard approvals and hol-guard receipts. ## Install HOL Guard and run a first check The README requires Python 3.10 or newer and pipx. The install is two commands: pipx installs the package, then the first-run wizard discovers supported agents and walks through protection setup. The README states the wizard asks before each setup change, including opening the dashboard, installing agent integrations, and connecting optional cloud services. ```bash pipx install hol-guard hol-guard init ``` After the wizard, verify the installation and the current protection state. The version check confirms the binary resolves, and status reports what Guard believes it is protecting. If status shows no agents, the wizard did not find an integration to install. ```bash hol-guard --version hol-guard status ``` To wire up one agent explicitly rather than relying on discovery, the README gives Codex as the worked example. The dry run records the current artifact state before launch, which is what makes later diffs meaningful. ```bash hol-guard install codex hol-guard run codex --dry-run hol-guard run codex ``` For a first look at how a dangerous-looking command is classified without executing it, the README documents command test and command explain. Both inspect the command and its matching rules without running it or creating an approval. ```bash hol-guard command test 'rm -rf ./build' hol-guard command explain 'git clean -ndx' ``` Everyday operations are small commands: hol-guard doctor codex diagnoses an integration, hol-guard diff codex shows changes before launch, hol-guard approvals lists pending requests, and hol-guard abom --format json exports an AI bill of materials. ## Where the hook model breaks down The honest limitation is the one the README itself concedes: enforcement depends on what the agent exposes. An agent that does not emit a pre-tool event, or whose hooks the user disables, is outside Guard's reach. The Codex path handles this by refusing a managed launch when hooks are missing or disabled, but that refusal is specific to Codex, and the README does not claim the same hard stop for every integration. If you assume uniform enforcement across all fifteen listed agents, you will be wrong. There is a second boundary. Guard reviews actions at the agent boundary, not inside the process. A tool that the agent calls, and that itself spawns a child process, is only visible to the extent the agent reports it. Guard is also not a replacement for running untrusted code in a container or VM; it is a review and approval layer for actions you would otherwise wave through. Finally, the project ships very frequently. Three releases landed between 2026-09-09 and 2026-09-10, and the last push to main was on 2026-09-10. That pace is good for fixes and bad for anyone who wants a stable surface to build against. The README documents hol-guard update for existing installations, but it does not document a rollback path, so pinning a version before an upgrade is your own responsibility. ## How it compares to a general agent sandbox The closest alternative approach is a container or VM sandbox, where the agent runs with no access to host credentials and the boundary is enforced by the kernel rather than by the agent's cooperation. Docker-based isolation is the common form. The difference is one of default posture: a sandbox denies by default and requires you to mount what the agent needs, while Guard allows by default and interrupts specific actions it classifies as risky. That makes them good at different things. A sandbox cannot tell you that a package install looks like a supply-chain risk or that a prompt contains an injection attempt; it only limits the blast radius. Guard can classify those events and record a receipt, but it depends on the agent reporting them. For a laptop where the agent needs the real working directory and real credentials to be useful, Guard is the more practical layer. For CI or for running code you do not trust at all, the container is the stronger boundary, and the repository does ship a Dockerfile that builds a plugin-scanner entrypoint running as a non-root scanner user in /workspace. Guard also overlaps with secret scanners and pre-commit hooks. Those run at commit time; Guard runs at action time, which is earlier in the chain but also noisier. ## Licence, dependencies and upgrade cost The project is Apache-2.0, declared both in the repository LICENSE and in pyproject.toml as license = "Apache-2.0". That permits commercial use and modification with the usual attribution and notice conditions; it is not a copyleft licence, so it does not force you to publish changes. This is a description of the licence identifier, not legal advice, and the optional cisco extra pulls in cisco-ai-skill-scanner and litellm, which carry their own terms. Installation cost is low. The dependency list in pyproject.toml is ordinary: rich, cryptography, keyring, packaging, jsonschema, pyyaml, regex, requests, publicsuffixlist, tomli on older Pythons, and mcp for Python 3.10 and above. Nothing exotic, and the Dockerfile installs from a hash-pinned requirements file with --no-deps --require-hashes, which is a stricter posture than most Python images. The ongoing cost is the release cadence. With multiple releases per day at the time of the last push, an unpinned install moves quickly. The update command exists, the rollback story does not appear in the README, and the support matrix is the document that will change most often as integrations are added or reworked. ## Conclusion Adopt HOL Guard if you run coding agents such as Codex, Claude Code or Cursor on machines that hold credentials, and you want a local approval and receipt trail without sending data to a cloud service. Skip it if your agents run in a container with no host secrets, or if you need kernel-level syscall enforcement rather than hook-based review. Before trusting it, run hol-guard install codex, then hol-guard doctor codex and hol-guard diff codex to confirm the native pre-tool hooks are present, and read docs/guard/harness-support.md for the failure behavior of your specific agent. ## FAQ ### What is HOL Guard and what does it protect? HOL Guard is an open-source, local-first security layer for AI agents. According to the README it reviews shell commands, file access, package installs, MCP tool calls, plugins and prompts before they run, then allows, blocks, or requests approval according to policy. ### How do I install HOL Guard? It requires Python 3.10 or newer and pipx. The README gives two commands, pipx install hol-guard followed by hol-guard init, and the first-run wizard discovers supported agents and asks before each setup change. ### Which AI agents does HOL Guard support? The README lists Codex, Claude Code, GitHub Copilot CLI, Cursor, Cline, Gemini CLI, Grok, Hermes, Kimi Code, Pi, oh-my-pi, OpenClaw, OpenCode, Antigravity and ZCode. It also states that coverage depends on the events each agent exposes, so enforcement differs per integration. ### Can I inspect a command without running it? Yes. The README documents hol-guard command test and hol-guard command explain, which inspect a command's classification and matching rules without executing it or creating an approval. ## Sources - [hashgraph-online/hol-guard on GitHub](https://github.com/hashgraph-online/hol-guard) - [License: Apache-2.0](https://github.com/hashgraph-online/hol-guard/blob/main/LICENSE) - [Project website](https://hol.org/guard) - [README](https://github.com/hashgraph-online/hol-guard/blob/main/README.md) - [Releases](https://github.com/hashgraph-online/hol-guard/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/hashgraph-online-hol-guard