Michael Kantor — HOL

What experiences led you to lead HOL, and how have they shaped your approach to building products and organizations?

Before HOL, I spent a couple of years working in distributed and decentralized technology. I then started HOL as an open-source standards organization. A lot of our work comes back to practical questions: how agents identify themselves, communicate, and handle security and privacy.

We bring organizations into working groups to build those pieces together. Open source gives them something they can inspect, use and contribute to. That's also how we approach products: build something people can try, then work with them on what needs to change.

What problem prompted the development of HOL Guard? Was there a particular incident or user conversation that made the need clear?

Guard grew out of our own anxiety as we increased our AI workloads. At one point we were running roughly 10 to 20 coding sessions at the same time. We started asking what could go wrong when those agents could read files, install packages or run commands on our machines.

That concern was enough to start building. Guard lets us apply policy to actions exposed by supported integrations and require a review or block an action where the integration supports that control. The exact point where Guard can intervene matters, especially if an event only becomes visible after it has happened.

Why did you choose a local-first approach for Guard, and what trade-offs has that decision created for the product and the business?

We started from the belief that people using AI should have access to security for free. Guard's core policy decisions run on the user's machine, and people can use the open-source version on its own.

The optional cloud component coordinates policy across machines and teams. For example, a company may want certain actions pre-approved and others blocked across its employees' machines. The paid offering is built around managing and distributing those shared policies.

Who is Guard's primary audience today, and what have you learned about getting people to move from interest to regular use?

Guard is aimed at people using AI tools that can take actions on their computers. Our conversations have often been with engineering and product leaders, security teams, and founders at smaller companies.

We've asked prospective design partners which terminals they need supported and what they need the product to do, so they can help shape it. That gives the conversation something concrete to focus on: the work they need to do with their agents.

Reviewing agent actions can give users more control, but frequent approval requests can interrupt their work. How do you decide when Guard should intervene?

The policy and the action determine the response. A supported event can be allowed, observed, sent for review or blocked. Users can make policies specific to the actions they want to control and save scoped decisions, so the same kind of request doesn't always need a fresh manual decision.

For example, reading a file and deleting it can require different treatment. A rule needs to account for what a command will do, including its arguments. That is more useful than treating every use of a tool as equally risky. It still depends on what the integration exposes and what it can enforce before execution.

Security products depend on trust. How do you help users assess what Guard can protect against, understand its limitations, and test its value for themselves?

We publish the source and document the coverage limits. I would start with the exact integration and version you're using, then try a harmless example in that setup. Check the decision and the record it produces. A pre-action block and an observation made after execution provide different kinds of protection.

Guard is one layer of control. Identity, endpoint security and secrets management still matter, and there are paths that Guard doesn't cover. The coverage documentation should make those gaps visible. People need enough detail to decide whether it addresses the risk they have.

Which signals tell you that you are building something people genuinely need? How do you distinguish attention or downloads from lasting adoption?

Outside contributions have been encouraging. We've had community members submit pull requests, which gives us something concrete to review and build on.

Downloads and stars tell us people are finding the project. Lasting adoption takes more evidence: whether they keep using it in their work, whether the controls help with the problems they encounter, and whether they come back with feedback after the first try. The open-source conversations and contributions help us understand what people need next.