HOL Guard

Coding agents are now trusted with real shells, real credentials and real package managers, and the failure mode is no longer a bad suggestion you can ignore — it is a command that already ran. HOL Guard sits between the agent and the machine as a local runtime firewall: it intercepts tool calls before execution, applies policy to shell commands, secrets reads, MCP invocations and package installs, and gives you a decision point instead of a post-mortem. Installation is deliberately unglamorous — pipx install hol-guard && hol-guard init — and everything runs locally, so agent activity and policy decisions never leave the developer's machine. That local-first design is the main reason to prefer it over cloud-mediated sandboxing: there is no new service holding a transcript of your repository or your environment variables. It is Apache-2.0 licensed, which matters for teams that need to audit or fork enforcement logic rather than take it on trust. The honest limitation, which the project states plainly, is that scanning is not a safety guarantee. Policies catch known-dangerous patterns; a sufficiently novel or obfuscated action can still slip through, and a permissive ruleset provides little protection. Treat it as defence in depth alongside scoped credentials and disposable environments, not as a licence to give an agent unrestricted access. For anyone running agents with write access to a real machine, that layer is worth having.