@wrap_tool_call policy — every unsafe command is blocked before it runs.
Quick Start
1
Install HOL Guard
HOL Guard is a separate CLI. Install it once:
2
Add the guard policy to your agent
3
Run and see a blocked command
How It Works
Every command-bearing tool call passes through HOL Guard’s CLI before it can execute.
Tools that are not in
COMMAND_BEARING_TOOLS skip the guard entirely and run untouched.
Configuration Options
Tune the policy by editing the constants in the example.Fail-Closed Decision Matrix
The policy runs the tool only on an explicit safe verdict — everything else blocks.User Interaction Flow
A real user asks for an unsafe command; HOL Guard blocks it and the agent refuses politely.Common Patterns
Widen the tool allow-list — add more command-bearing tools to the set:after_tool hook:
before_tool argument validation for defense in depth:
Best Practices
Set both result and error on the blocked ToolResponse
Set both result and error on the blocked ToolResponse
The tool executor returns
ToolResponse.result to the model and discards error. Set result so the model sees the block, and keep error populated so after_tool hooks and logs still have the signal. Setting only error would surface as a null result.Keep Guard external
Keep Guard external
Do not vendor
hol-guard into your agent’s dependency tree. Installing it separately preserves independent versioning and lets ops teams patch Guard without a code deploy.Timeout aggressively
Timeout aggressively
Guard is on the hot path.
GUARD_TIMEOUT_SECONDS=10 is a ceiling, not a target — a slow Guard fails closed and blocks the command.Prefer allow-lists to block-lists
Prefer allow-lists to block-lists
The example checks for
allow/benign explicitly and fails closed on everything else, including verdicts introduced in future Guard versions.Related
Middleware
Intercept and modify model and tool calls with before/after hooks and wrap decorators
Hooks
Event-based hooks for agent lifecycle events

