HOL Guard: An Open-Source Antivirus for AI Agents Against Malicious MCP Servers and Skills

AI agents are leaving the chat window. Over the past year, coding assistants have learned to run shell commands, read and write local files, install dependencies, and call external tools through Model Context Protocol (MCP) servers. That growth in capability raises a plain but sharp question. When a program that can be steered by a prompt holds the permissions of your terminal, who stands at the gate? HOL Guard, an open-source project from hashgraph-online, answers with a blunt positioning: an open-source antivirus for AI agents. It does not try to make the model more obedient. Instead, it places a local layer, independent of the model, in front of each action, and that layer examines the action before it lands. The idea belongs to the same family as layered endpoint defense. The object under inspection has changed, from executable files to every single move an agent makes. The working principle is review before execution. The actions in scope are shell commands, file access, package installs, and MCP tool calls. The risks it looks for are secret exposure, destructive operations, prompt injection, and supply-chain threats. According to the policy the user sets, it then allows the action, blocks it, or asks for approval. The project documentation sorts the protected surface into six groups: shell commands and file access, package installs, plugins, skills and agent configuration, MCP servers and tools, prompts and tool results, and approvals with evidence. The last group deserves attention. Every decision leaves a local receipt, and users can review the history through the command line and a local dashboard. A security decision stops being a one-off pop-up and becomes a record that can be examined later. That helps both incident investigation and policy tuning.

Architecturally, HOL Guard commits to local-first operation. It runs without an account and attaches to agents in three ways: native hooks that each agent exposes, managed MCP proxies, and launch-time integrations. The documentation states plainly that coverage depends on which events each agent exposes, and it keeps a support matrix that records enforcement, approval delivery, and failure behavior for every integration. That candor is itself an engineering virtue. The most dangerous state for a security tool is one in which users believe they are fully protected while a whole class of events has no hook to attach to. For plugins, skills, and configuration, Guard takes an inventory of local artifacts and reviews anything new or changed before it launches. This targets a threat that has appeared repeatedly in recent months: malicious skills and poisoned MCP servers that look harmless until an agent loads them.

Adoption friction is low. The requirements are Python 3.10 or newer and pipx. After pipx install hol-guard, the user runs hol-guard init. The first-run wizard discovers supported agents on the machine and asks before each change, including opening the dashboard, installing agent integrations, and connecting optional cloud services. The supported list is long: Codex, Claude Code, GitHub Copilot CLI, Cursor, Cline, Gemini CLI, Grok, Hermes, Kimi Code, Pi, OpenClaw, OpenCode, Antigravity, Devin, and others, with Paseo covered through its native providers. Teams that need more can turn to the optional Guard Cloud, which adds shared history, team policy, and fleet management. The same repository ships a plugin scanner, published as plugin-scanner, that inspects an extension before it is installed. A fair assessment must also name the limits. First, the antivirus analogy is a convenience for communication, not a technical equivalence. Classic antivirus leans on signatures and behavior monitoring, whereas agent risk arises at the semantic level. Detecting prompt injection is probabilistic by nature, so zero misses is not possible. Second, hook coverage sets the ceiling. An event that the agent does not expose is an event Guard cannot see. Third, approval workflows breed fatigue. A policy that is too loose becomes decoration, and one that is too strict gets switched off. Fourth, supply-chain verdicts depend on the quality and freshness of external intelligence. None of these is a defect. They are constraints that every tool in this category faces. What matters is whether the project shows them honestly in its documentation. From the public material, it does. It also carries the usual signs of engineering discipline: an Apache-2.0 license, continuous integration, a container image, and an OpenSSF Scorecard badge.

Our practical advice is to treat Guard as one layer in a defense in depth, never the only layer. An individual developer can enable it on the single agent they use most, watch the block log for a week, and then tighten policy in steps. A team should keep secret isolation, least privilege, and sandboxing in place, and let Guard supply an auditable gate before actions occur. Over the longer term, agent security is moving away from the topic of model alignment and toward an operating-system style problem of permissions and audit. The value of HOL Guard is that it turns this shift into a concrete tool that can be installed today and whose logs can be read tomorrow. That is closer to usable security than any abstract call to action.