Launching today
HOL Guard
The 1st Firewall for AI Agents
59 followers
The 1st Firewall for AI Agents
59 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.
HOL Guard
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.
HOL Guard
@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
HOL Guard
@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.
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?
HOL Guard
@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.
HOL Guard
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.
HOL Guard
@brandon_davenport3 Thanks Brandon! Looking forward to your feedback & thoughts