HOL Guard
The 1st Firewall for AI Agents
195 followers
The 1st Firewall for AI Agents
195 followers
HOL Guard is the firewall for AI agents. It sits between agents and your systems, blocking high-risk actions before they happen like deleting production data to exposing secrets. Built by HOL, it’s free, open source, and already has 400K+ downloads.
Free Options
Launch Team / Built With
Render Sandboxes: a computer for every agentRun untrusted code safely. Idle sandboxes cost nothing
Promoted
Hi Product Hunt
I’m Michael Kantor, President of HOL. We’re an open standards consortium for AI agents, with 20+ specifications contributed through LF Decentralized Trust and more than 37M transactions powered by our work.
For the past two years, we’ve been thinking about what happens when billions of autonomous agents are transacting, installing tools, accessing systems, and exchanging information. As we used AI more deeply inside HOL, we saw agents attempt to bypass safeguards, access secrets, and send data they should never have been able to reach.
We originally built HOL Guard to protect our own systems. Once we realized how widespread the problem was, we open-sourced it and started building it for everyone.
HOL Guard uses open standards and hundreds of security heuristics to protect agents from malicious packages, prompt injection, secret exfiltration, and catastrophic actions such as deleting a production database or filesystem. GPT-5.6 was also a valuable partner in building adversarial tests and hardening the product.
We’d love for you to try it, break it, and tell us what we should improve. Thank you for supporting open-source AI security.
@thys_beesman Great questions.
Our view is that high-stakes security decisions should not depend on another model making a probabilistic judgment in real time. You can use AI to generate adversarial cases, find bypasses, and improve coverage, but eventually something has to be the final authority.
In HOL Guard, that authority is local, deterministic policy. The runtime combines structured command parsing, provenance, trust state, severity, confidence, and the user or organization’s chosen security posture. Clear threats can be blocked, trusted actions can proceed, and unclear high-impact actions can require approval instead of forcing Guard to guess.
That is how we balance false positives and false negatives. We are not tuning toward “block everything unfamiliar.” We are tuning toward making consequential actions explicit before they run, while allowing teams to choose how conservative they want Guard to be.
GPT-5.6 is not making the live allow/block decision today. We use models heavily to attack the system during development: generating edge cases, searching for evasions, and challenging assumptions. But once Guard ships, enforcement remains reproducible, inspectable, and explainable.
And because the project is open source, the rules, parsers, tests, and decisions can be challenged and improved in public rather than hidden behind an opaque model response.
heuristics cutting both ways is my worry here. a firewall that's too strict on false positives trains developers to just approve everything without reading the prompt, which is worse than not having it at all. do you have real numbers yet on false positive rate at 400k downloads, or is that still mostly theoretical since it just launched
@galdayan That’s exactly the failure mode we designed around. A security product that constantly interrupts normal work eventually teaches people to ignore it.
Guard does not treat every unfamiliar action as a block. The default Balanced policy lets known-safe work continue, blocks clear high-confidence threats, and reserves approval for actions that are consequential, changed, or genuinely ambiguous. We also use structured command parsing rather than simple keyword matching, so quoted examples, searches, and dry runs are not treated the same as execution.
We do not yet publish a credible global false-positive percentage. The 400K figure is package downloads, not 400K instrumented runtime decisions, and Guard is local-first by design, so we do not collect everyone’s commands, prompts, files, or approvals to manufacture a dashboard metric. Internally, we've been leveraging HOL Guard for months now and have blocked hundreds of thousands of commands that could be deemed as critical or high risk.
What we do have today is a large regression corpus with paired benign/destructive cases, explicit false-positive release gates, side-effect-free decision inspection, and local receipts that make every interruption explainable. As real team deployments grow, we’ll publish measured results when the sample is meaningful.
@kantorcodes appreciate the honest answer instead of a made-up number. the structured command parsing over keyword matching is the part that actually addresses my worry - most "AI firewalls" I've seen just regex for scary words and call it a day. will be curious to see the real numbers once you have enough deployments
@kantorcodes lol, well played. structured parsing catches the joke, keyword matching would've just seen "attack" and panicked.
I like that this sits before the agent acts, not after logs are reviewed. The thing I would want to debug quickly is a blocked action: exact tool call, matched rule, risky input/output, and whether it was policy or model uncertainty. Is that visible in the product?
@yaroslav_stelmakh Yup! Nothing leaves you device and every action is stored in "evidence" along with great analytics so you can understand where your Agent is making risky tool calls.
@kantorcodes congrats on the launch - keen to give this a crack with our team as we push more agents into our workflows. The balanced policy approach looks to be exactly what we need to avoid approval fatigue.
@adriantomkins thanks, Adrian!
We’re excited about where AI agents are headed but as they become more autonomous, we think developers need better ways to stay in control without sacrificing speed. Our goal with HOL Guard is simple: make it easy to let AI do more while ensuring sensitive actions are reviewed or blocked when they should be.
We’re always building and would genuinely love your feedback. If you’re working with AI agents, what kinds of actions would you want an AI firewall to monitor, pause, or automatically block? We’d love to hear your thoughts!
Incredible work, I'll be setting this up in my environment today. My security concerns have been growing as I start relying on autonomous workflows more and more, so this feels like a solid step.
@brandon_davenport3 Thanks Brandon! Looking forward to your feedback & thoughts