HOL Guard: Open-Source Antivirus for AI Agents

HOL Guard Version
Plugin Scanner Version
HOL Guard Downloads
Plugin Scanner Downloads
Python 3.10+
CI
Publish
Container Image
OpenSSF Scorecard
License
GitHub Stars
Lint: ruff

HOL whole dark logo Stop risky AI actions before they compromise your machine. HOL Guard is a local-first security layer for AI agents, tools, plugins, skills, MCP servers, and package installs.

Install HOL Guard
Read the documentation
PyPI Package (hol-guard)
Report an Issue

HOL Guard brings antivirus-style runtime protection to AI agents. It evaluates supported agent actions and local artifacts for secret exposure, prompt injection, unsafe commands, malicious packages, and MCP risks. Guard can allow safe work, block known threats, pause ambiguous actions for approval, and record security receipts for later review.

Use HOL Guard locally without a cloud account. Connect Guard Cloud when you want synchronized evidence, team policies, fleet visibility, and shared approval workflows.

Install HOL Guard

pipx install hol-guard
hol-guard init

hol-guard init discovers compatible AI agents, explains each setup change before applying it, and guides you through your first protected action.

Install guide · Supported agents · Local vs. cloud · Security policy

What HOL Guard Protects

Threat surface Guard protection
Agent tool calls Evaluates supported shell, file, MCP, prompt, and tool-result events through native hooks, managed proxies, or reversible launch overlays.
Secrets and credentials Detects sensitive file access, credential-shaped output, staged exfiltration, and suspicious outbound commands.
AI supply chain Reviews package installs, plugins, skills, MCP servers, hooks, and agent configuration before trust is granted.
Prompt injection For adapters that expose prompt events, screens prompt and tool intent for instructions that attempt to expose secrets, evade controls, or trigger destructive behavior.
Human approval Routes ambiguous actions to native prompts, the local approval center, or Guard Cloud according to the active policy.
Security evidence Records attributable receipts and inventory changes so decisions can be reviewed, explained, and synchronized.

Guard prefers the strongest integration each agent exposes. Enforcement depth varies by agent and event type; see the support matrix for the exact current contract.

Supported AI Agents

HOL Guard currently integrates with Codex, Claude Code, GitHub Copilot CLI, Cursor, Gemini CLI, Hermes, OpenClaw, OpenCode, Antigravity, Kimi Code, Grok, Pi / oh-my-pi, and ZCode.

These developer agents are Guard's deepest integrations today, but the product boundary is broader: the same policy, supply-chain, approval, and evidence layers are designed to protect AI agents and their local tool ecosystems as new adapters are added.

Why HOL Guard

Most security tools see only one part of an AI agent's attack surface. Code scanners run after files change. Sandboxes constrain a process but do not understand agent intent. MCP gateways see MCP traffic but not local shell commands, package installs, skills, hooks, or agent configuration.

HOL Guard combines those signals at the local runtime boundary. It discovers the agent and its tools, evaluates supported actions against one policy, requests human approval only when needed, and records the resulting decision. The goal is practical protection without turning ordinary AI-assisted work into a stream of prompts.

Choose the Right Package

If you want to... Install Start with
protect AI agents and their local runtime hol-guard hol-guard init
lint and verify plugins, skills, MCP servers, and marketplace packages in CI plugin-scanner plugin-scanner verify .

hol-guard is the end-user antivirus and runtime protection product. plugin-scanner is the maintainer and CI companion for analyzing agent ecosystem packages before release.

Guard Operations

To update an existing pipx install from PyPI:

pipx upgrade hol-guard

If you installed Guard with pipx, verify the active user command before testing local flows:

command -v hol-guard
hol-guard --version

For a local wheel build, install into the pipx-managed hol-guard environment. Do not test with PYTHONPATH=src; that bypasses the same package path users run.

python3 -m build --wheel
hol-guard update --wheel dist
hol-guard --version

hol-guard update --wheel accepts either a specific .whl file or a directory and picks the newest matching hol_guard-*.whl.

To force a specific release, use Python package specifier syntax:

pipx install --force 'hol-guard==2.0.345'

Do not use hol-guard@<version>; pipx treats that as a separate app name, not a package version.

hol-guard init is the first-run guided setup. It shows a progressive plan first, then gates each side effect: approve dashboard, Guard completes it, then approve app protection, Guard completes it, then approve Cloud connect and notifications. Nothing opens or changes until you approve that checkpoint. Use hol-guard init --yes only for automation when you already trust the plan.

Manual and follow-up commands:

pipx run hol-guard bootstrap
pipx run hol-guard hermes bootstrap
pipx run hol-guard run codex --dry-run
pipx run hol-guard run codex
pipx run hol-guard approvals
pipx run hol-guard receipts
pipx run hol-guard status
pipx run hol-guard connect
pipx run hol-guard connect status
pipx run hol-guard connect repair
pipx run hol-guard sync
pipx run hol-guard supply-chain sync
pipx run hol-guard supply-chain scan
pipx run hol-guard supply-chain explain minimist@1.2.5 --ecosystem npm
pipx run hol-guard explain install-connect
pipx run hol-guard command test 'git reset --hard HEAD~1'
pipx run hol-guard command explain 'grep "rm -rf|git clean" README.md'
pipx run hol-guard command extensions

What you get from Guard:

  • Detects supported AI agent configuration on your machine
  • Records a baseline before you trust a tool
  • Pauses cleanly on new or changed artifacts before launch
  • Queues blocked changes in a localhost approval center when the harness cannot prompt inline
  • Stores receipts locally so you can review decisions later
  • Keeps sync optional until you actually want shared history

See docs/guard/get-started.md for the full local flow.

Inspect command protection without running it

Command safety extensions make Guard's shell, Git, filesystem, system, Windows, data-protection, container,
Kubernetes, encoded-execution, and self-protection behavior inspectable. Required core extensions cannot be mistaken
for optional integrations. They are built-in capability boundaries over the same parser used by harness hooks, not
downloadable regex bundles.

Each extension publishes stable rule IDs and structured rule metadata. Command inspection also returns a canonical,
side-effect-free parse model with wrapper, pipeline, environment-override, provenance, and confidence details so
automation can distinguish exact parsing from malformed or unsupported input.

Use command test for a concise classification and command explain for the complete evaluation trace. Both are
side-effect free: they do not execute the command, evaluate final policy, create an approval, or record a receipt.
Use --json for a stable automation contract.

hol-guard command test 'rm -rf ./build'
hol-guard command explain 'grep "rm -rf|git clean" README.md'
hol-guard command extensions command.git --json

Structured core rules preserve every match in a compound command. A Git preview such as git clean -ndx remains
safe, while an unrelated destructive segment still produces review. New structured coverage feeds the same runtime
artifact and policy pipeline as existing command classifications.

Guard commands at a glance
  • hol-guard start
    Shows the next step for the harnesses Guard found.
  • hol-guard init
    Runs first-run onboarding as approval checkpoints: local dashboard, harness discovery and install, optional Guard Cloud connect, and desktop notification setup.
  • hol-guard bootstrap
    Detects the best local harness, starts the approval center, and installs Guard in front of it.
  • hol-guard hermes bootstrap
    Installs the Guard-managed Hermes overlay bundle directly.
  • hol-guard status
    Shows what Guard is watching now.
  • hol-guard install <harness>
    Creates the launcher shim for that harness.
  • hol-guard uninstall --self
    Removes Guard-managed harness wiring, package shims, local Guard state, and uninstalls the current hol-guard package.
  • hol-guard update
    Updates the installed hol-guard package in the current environment.
  • hol-guard run <harness> --dry-run
    Records the current state once before you trust it.
  • hol-guard run <harness>
    Reviews changes before launch and hands blocked sessions to the approval center when needed.
  • hol-guard approvals
    Lists pending approvals or resolves them from the terminal.
  • hol-guard receipts
    Shows local approval and block history.
Harness approval strategy
  • claude-code
    Guard prefers Claude hooks first, then the local approval center when the shell cannot prompt.
  • copilot
    Guard can wrap the copilot CLI, detect ~/.copilot/config.json, ~/.copilot/mcp-config.json, workspace .vscode/mcp.json, and install Guard-managed Copilot hook wiring for documented preToolUse and postToolUse events.
    Guard does not treat a VS Code Copilot inline permission sheet by itself as proof of Guard interception; current proof should come from Guard hook responses, Guard receipts, or an MCP client that explicitly answers Guard elicitation.
  • codex
    Guard asks inline in the same Codex chat when the interactive CLI or Codex App can answer MCP elicitations, and falls back to the local approval center only for codex exec or any other nonresponsive session. When Guard has the right Codex thread binding, approving or blocking in the browser resumes the same Codex thread with HOL Guard-branded continuation copy. Live app-server sessions continue in place, and headless codex exec sessions resume through codex exec resume with the exact blocked command context. If the session cannot be identified, Guard says so plainly and tells you the manual next step instead of pretending it resumed.
  • cursor
    Guard respects Cursor’s native tool approval and focuses on artifact trust before launch.
  • opencode
    Guard authors package-level policy while OpenCode keeps native once, always, or reject prompts for managed MCP tools.
  • kimi
    Guard installs managed PreToolUse and UserPromptSubmit hooks in ~/.kimi-code/config.toml, blocks with exit code 2 and a JSON permissionDecision: "deny" response, and fails open on hook crash or timeout.
  • grok
    Guard installs a catch-all Grok PreToolUse hook plus observe-only prompt and subagent hooks under ~/.grok/hooks/, writes permission deny rules and backup hooks in ~/.grok/managed_config.toml, blocks tool calls with exit code 2 and a Grok-native {"decision":"deny"} response, never reads ~/.grok/auth, and launches only a trusted absolute Grok executable. Custom install roots can be selected once with hol-guard run grok --grok-executable /absolute/path/to/grok. After upgrading an existing Grok install, run hol-guard apps repair grok so the catch-all hook replaces the older per-tool matcher list.
  • pi
    Guard scans ~/.pi/agent/ and project .pi/ packages, extensions, skills, prompts, and themes; installs a managed Pi extension that reviews input and tool_call events inline; and blocks with a Pi-native {"decision":"deny"} response when Guard policy says no.
  • zcode
    Guard detects ~/.zcode/cli/config.json, configured MCP servers, enabled plugins, the plugin cache, and plugin manifests; installs managed PreToolUse and UserPromptSubmit hooks in the config hooks section without touching user mcp or plugins; and blocks with exit code 2 and a permissionDecision: "deny" response.
  • hermes
    Guard installs a managed Hermes overlay bundle, routes MCP servers through Guard proxies, and prefers native-or-center delivery for blocked requests.
  • gemini
    Guard scans extensions and falls back to the local approval center for blocked changes.

Guard: Protection Levels

HOL Guard is antivirus for AI agents. It evaluates supported runtime events and local artifacts, then applies the active policy before execution where the agent provides a pre-action boundary. Other integrations use native approval, managed proxy, launch-time, or post-action evidence surfaces according to the support matrix.

Choose a protection level with hol-guard settings set security-level <level>:

Level Who it's for What it blocks
Gentle Teams who want minimal friction; experienced users High-confidence secrets and clear exfil only
Balanced Most users (default) Secrets, shell exfil, prompt injections, supply-chain hooks
Strict Security-conscious teams Everything above plus low-confidence signals and untrusted prompts
Paranoid High-security environments All the above plus any unrecognized MCP server action

If you are unsure, start with Balanced. You can promote to Strict after reviewing your first week of receipts.

Guard: Troubleshooting

Why was my command paused?

Guard paused a command because one or more detectors fired. To see exactly what triggered:

hol-guard receipts          # review recent decisions
hol-guard doctor            # run a probe and see which detectors are active
hol-guard doctor --perf     # include per-detector timing

If the block looks like a false positive, you can approve it from the receipts view or from the dashboard at http://localhost:6174.

How do I clear approvals?

From the terminal:

hol-guard approvals         # list pending approvals
hol-guard approvals clear   # clear all pending approvals (prompts for confirmation)

From the dashboard: open http://localhost:6174, go to the Approval Center, and use the Clear all button. You will be asked to confirm before any approvals are removed.

How do I require human proof before saved approvals?

Enable the local approval gate when saved allow decisions, global trust, policy clears, or settings changes should require a human password before Guard persists them:

hol-guard settings approval-password enable \
  --new-password '<password>' \
  --confirm-password '<password>' \
  --cooldown-seconds 900
hol-guard settings approval-password status

Use cooldown only for ordinary non-global allow decisions. Guard still requires fresh proof for global allow, policy clear, settings import/reset, disabling the gate, disabling TOTP, and recovery. When TOTP is enabled, it replaces password proof and cooldown is disabled, so every protected action requires a current authenticator code. To unlock or lock the current password-only approval window from a terminal:

hol-guard approvals unlock --duration 15m
hol-guard approvals lock

For Google Authenticator-compatible second-factor proof, enroll TOTP after the password gate is enabled:

hol-guard settings approval-totp enroll --current-password '<password>' --device-label '<device>'
hol-guard settings approval-totp verify --current-password '<password>' --code 123456
hol-guard settings approval-totp status

TOTP uses SHA-1, 6 digits, 30-second steps, and a Base32 otpauth://totp/HOL%20Guard:<device> provisioning URI. Guard stores the seed encrypted locally, rejects replayed steps, and never includes the seed in settings export, receipts, or public status. When TOTP is enabled, disabling TOTP or the password gate requires a current authenticator code instead of the password.

Approval proof creates only a 30-second, transaction-local grant for the exact action, scope, subject, and session nonce being processed. The grant is never returned to the browser or reused as a general login session. Guard tracks password and authenticator failures independently and locks the active factor after five failed attempts; rotating either factor revokes outstanding grants and any saved recovery, session, or trusted-device state.

Guard: Advisory Sync Privacy

Guard's advisory database updates are optional and pull-only. When you run hol-guard advisories sync, Guard fetches a signed advisory list from advisories.hol.org. No local file paths, harness configs, receipt data, or workspace identifiers are sent to any server during sync.

Advisory sync requires a HOL Guard Cloud account. If you have not signed in, sync is skipped and Guard continues using the locally bundled advisory database. Run hol-guard connect to connect a free account, or hol-guard connect --headless on SSH/CI hosts.

Scanner Quickstart

pipx install plugin-scanner
plugin-scanner lint .
plugin-scanner verify .
# GitHub Actions PR gate
- name: AI plugin quality gate
  uses: hashgraph-online/ai-plugin-scanner-action@v1
  with:
    plugin_dir: "."
    fail_on_severity: high
    min_score: 80

When to add plugin-scanner:

  • You publish plugins, skills, or marketplace packages
  • You want a CI gate before release
  • You need SARIF, verification payloads, or submission artifacts

If your repository uses a Codex marketplace root like .agents/plugins/marketplace.json, keep plugin_dir: ".". The scanner will discover local ./plugins/... entries automatically, scan each local plugin manifest, and skip remote marketplace entries instead of treating the repo root as a single plugin.

Need More Detail?

Scanner reference: trust scoring, installs, ecosystems, and CLI commands

How Trust Scoring Works

The scanner now emits explicit trust provenance alongside the quality grade:

  • bundled skills use the published HCS-28 baseline adapter ids, weights, and denominator rules directly
  • MCP configuration trust uses the same HCS-style adapter, weight, and contribution-mode pattern locally
  • top-level Codex plugin trust uses the same HCS-style adapter, weight, and contribution-mode pattern locally

Current local specs:

This keeps the quality grade and the trust score separate. Signals like SECURITY.md remain visible, but their weight is now a named adapter weight rather than an inferred side effect of raw category points.

Quick Start For Contributors

git clone https://github.com/hashgraph-online/hol-guard.git
cd hol-guard
uv sync --extra dev --extra cisco --group cisco-mcp
pytest -q

Use uv sync --extra dev --python 3.10 when you need the lean baseline path without the Cisco MCP extra.

Install The Package You Need

Lean baseline install

Guard package:

pip install hol-guard

Scanner package:

pip install plugin-scanner

The lean baseline keeps Python 3.10+ support intact. It includes the shipped cisco-ai-skill-scanner integration on Python 3.10 through 3.14 and directly pins LiteLLM 1.93.0 so bare pip and pipx installs cannot drift to an unverified LiteLLM release.

Resolver-safe Cisco extra

Install the Cisco extra on Python 3.11 through 3.14 when you want to explicitly select the Cisco dependency surface in addition to the baseline skill scanner:

pip install "hol-guard[cisco]"
pip install "plugin-scanner[cisco]"

cisco-ai-mcp-scanner stays in the repo-controlled cisco-mcp uv dependency group and now pins Cisco's LiteLLM 1.93.0-compatible release so Docker and CI can install full Cisco coverage natively on Python 3.11.4 through 3.14. The published cisco extra remains resolver-safe for pip users.

On Guard surfaces, the Cisco extra keeps the LiteLLM-dependent Cisco skill-scanner path on a patched resolver-safe version. Repo-controlled Docker and uv sync --extra dev --extra cisco --group cisco-mcp --python 3.13 installs add optional Cisco MCP evidence to hol-guard scan, hol-guard preflight, and hol-guard explain <path>. Use --cisco-mode {auto,on,off} to control that consumer-mode evidence path for local artifact scans. hol-guard run and Guard runtime prompt/file-read protection remain native Guard behavior in this pass.

Guard inventory snapshots can also carry Cisco MCP and skill-scanner status when a Hermes or OpenClaw inventory run explicitly enables those scanners. The Cloud evidence model records scanner source, status, redacted finding text, duration, mapped artifact ID, and risk component metadata without storing raw local paths or secrets.

Guard does not add Cisco AIBOM runtime integration in this pass. If AIBOM support ret