Approving AI agent actions with HOL Guard: What to check first

“Clean up this project” sounds like a simple request. An AI agent may turn it into a sequence of commands, file changes and tool calls. Before approving the next step, you need to understand what it will affect and whether it fits the task you assigned.

A useful approval process makes the proposed action clear, gives you an opportunity to stop it and leaves a record you can inspect afterward.

What is HOL Guard?

HOL Guard is a security layer for AI agents. Its open-source local runtime can allow, request approval for or block covered actions, depending on the integration and active policy.

Its documented controls cover areas including shell commands, sensitive file access, package installation and supported MCP tool calls. MCP, or Model Context Protocol, connects AI applications to external tools and data. Reading a document and sending it to another service may use the same connection, but have different consequences.

Local protection works without a Guard Cloud account. Optional cloud services add shared history, policy and team controls. Coverage depends on the events the connected application exposes.

Public record: HOL Guard overview · HOL Guard README

Start with your integration’s coverage

Check the support matrix for your AI application, event type and setup. A product appearing on a supported-applications list does not mean every action is covered in every configuration.

HOL’s documentation describes pre-tool hooks for Codex and Claude Code, alongside event-specific hooks for Cursor. It also distinguishes checks that happen before execution from notifications received after a tool has run.

That timing matters. A pre-execution check can stop a covered action. A post-tool policy violation can help an investigation, but it cannot undo an action that has already happened.

Record the installed versions of Guard and the AI application. Confirm that the required integration is enabled, then run the documented diagnostic command for that application.

Public record: Agent support matrix · Local setup guide

Inspect the command before approving it

Suppose a developer asks an agent to clean a temporary build directory. Before approving the action, the developer should inspect the complete command, its working directory and the files it could affect. Small differences in arguments can change an operation’s consequences.

Guard’s README provides this command-inspection example:

hol-guard command explain 'git clean -ndx'

This asks Guard to explain the quoted command’s classification and matching rules. According to the documentation, command inspection does not execute the inspected command or create an approval request. Resolving a pending request is a separate operation.

Use the command-coverage documentation to understand the operations Guard recognises, then inspect the pending request and active workspace policy. The extension catalogue describes command coverage; it does not itself grant permission to act.

A classification result alone does not establish that a person authorised the action, that the agent attempted it or that anything changed.

Public record: HOL Guard README · Command coverage and extension directory

Five checks for every approval

1. Confirm the intended result. Does the proposed action match the task? Preparing a patch and publishing it to a shared repository are separate decisions.
2. Inspect the target and scope. For commands, check arguments, paths and the working directory. For tool calls, check the destination and the data being supplied.
3. Consider a narrower action. A preview, limited file selection or temporary test environment may answer the immediate question with fewer consequences.
4. Resolve the actual request. Use the approval interface or documented CLI. Guard’s README identifies hol-guard approvals for pending requests and hol-guard receipts for decision history.
5. Verify the result. After allowing an action, inspect the affected files or service. A permission decision records what was authorised; checking the resulting state establishes what actually happened.

Avoid broad exceptions simply to clear an approval queue. Decide the scope you intend to authorise, and consider whether a changed command, tool or artifact should require another review.

Public record: HOL Guard README

Where these checkpoints can help

For software teams, checkpoints can support reviews of file cleanup, package installation and version-control changes where the integration covers those operations.

For agents using MCP tools, identify the tool-call path and the events Guard receives. Keep connected-account permissions limited to the work required. Isolated environments and backups remain useful alongside action review.

For a team rollout, agree on who can approve consequential actions, which changes require another reviewer and what evidence should be retained.

Evaluate it with a disposable task

Before using the setup on important work, try a small exercise with disposable files and no production credentials.

Choose three covered actions: one your policy should allow, one that should require approval and one it should refuse. Write down the expected outcomes before running them through the intended integration.

For each case, check:

• The decision shown by Guard.
• Whether the requested operation actually ran.
• The resulting file or service state.

Repeat the relevant checks after changing the integration or policy. These are suggested evaluation steps, not test results reported by this article.

Document the specific environment, action and policy you tested, alongside the observed outcome. Keep that scope attached to any claim about protection.

Disclosure

HOL maintains HOL Guard. This contribution was prepared for HOL with AI assistance using public documentation and edited for clarity by Promptwire.

It includes no independent benchmark or customer deployment results. Promptwire has not independently tested the product, and this article does not claim complete protection against prompt injection.