HOL Guard

Inspiration

HOL Guard started as an internal tool because we were uneasy about how quickly AI agents were gaining access to our devices and work.

The tools we used every day were no longer just suggesting text or code. They could read files, run commands, install packages, register MCP tools, change configuration, send messages, and interact with external services. Similar agents were beginning to appear across engineering, sales, business development, content, and operations.

We liked the productivity, but we kept coming back to one question:

What can this agent do before a person notices?

Most security products either scan code, protect applications, or detect problems after something has already happened. We wanted protection at the moment an agent attempts to act.

HOL Guard began as a way to make our own use of autonomous AI feel safer. It gradually became clear that the same execution boundary would matter to any organization deploying agents with access to local files, credentials, tools, and business systems.

What it does

HOL Guard is the execution firewall for AI agents.

It sits between an agent and the environment it can act on. It inspects supported activity before execution, including file access, shell commands, package installations, MCP registrations, tool calls, configuration changes, and potentially destructive operations.

HOL Guard can:

Allow actions that match policy
Automatically block known threats
Route contextual actions to an Inbox for human approval
Explain why an action was paused or blocked
Produce an auditable receipt for each decision

For example, a clear secret-exfiltration attempt should not be presented to a user as something they can casually approve. HOL Guard blocks it and records the evidence.

Other actions require context. An agent deleting a folder of campaign drafts might be performing valid cleanup, or it might be destroying valuable work. HOL Guard can pause that action and let an authorized reviewer approve or block it.

The product is local-first, and the enforcement decision is independent from the model proposing the action. The agent can recommend what should happen, but it does not get to decide whether its own action is safe.

How we built it

HOL Guard already had a foundation of local agent integrations, approvals, policies, and security receipts.

During OpenAI Build Week, we used Codex with GPT-5.6 to build a new structured command safety engine.

The earlier approach could identify many risky patterns, but shell commands are difficult to evaluate accurately with simple keyword matching. A command can include multiple operations, wrappers, pipelines, redirects, environment variables, quoted strings, and nested shells.

We built a canonical representation that parses a command once and preserves the structure needed for security decisions. Structured rules then evaluate the complete action rather than treating it as a flat string.

For example:

git clean -nfdx && rm -rf ./build

The first segment is a safe preview. The second deletes files. HOL Guard evaluates both, so the safe-looking command cannot conceal the destructive action that follows it.

We used Codex and GPT-5.6 throughout the engineering loop:

Inspecting the existing enforcement path
Translating our threat model into an implementation plan
Designing the canonical command model
Implementing structured rule families
Generating adversarial test cases
Investigating false positives and bypasses
Reviewing pull requests and test results

GPT-5.6 was particularly useful for exploring combinations we might not immediately think to test, including quoting, pipelines, wrappers, compound commands, and safe variants.

We still kept the security architecture under explicit human control. The model helped us move faster, but it was never treated as the source of authority for an enforcement decision.

Challenges we ran into

The biggest challenge was avoiding two bad extremes.

A security layer that misses dangerous behavior is not useful. A security layer that interrupts every action will quickly be disabled.

Many actions are not universally safe or unsafe. Deleting a temporary build directory may be normal. Deleting a folder of customer research may require review. Reading a credential may be legitimate until it is combined with an outbound request.

This meant we had to reason about complete actions and combinations of evidence, not isolated keywords.

Shell parsing was another major challenge. Commands can change meaning depending on quoting, wrappers, redirects, pipelines, environment variables, and the shell dialect being used. We needed enough structure to make reliable decisions without attempting to build a complete shell interpreter.

We also had to separate terminal policy decisions from contextual approval decisions. A known exfiltration path should be blocked automatically. An action that may be legitimate should be routed to a human with a clear explanation and Approve or Block controls.

Finally, we had to make the product understandable. Silently stopping an agent is not enough. A user needs to know what the agent attempted, why HOL Guard intervened, what decision was made, and what evidence remains afterward.

Accomplishments that we're proud of

We are proud that HOL Guard is a working security product rather than a simulated hackathon interface. HOL Guard has been downloaded 400K+ times and is used everyday. In addition to HOL Guard, we also operate Awesome Codex Plugins which has ~700 stars. Many maintainers of plugins, use the Plugin Scanner from HOL Guard to reduce attack vectors.

The demo shows a real Codex action being intercepted before execution, a known threat being automatically blocked, a contextual action appearing in the HOL Guard Inbox, and a human decision preventing the underlying files from being changed.

We are also proud of the precision of the structured command engine. Safe inspection commands can continue without unnecessary friction, while dangerous operations in the same compound command are still detected. Commands are now 1st class citizens which will enable lots of great features as part of our roadmpa.

The engine now covers structured protections across areas including Git, cloud infrastructure, databases, storage, CI/CD, package operations, developer platforms, and destructive filesystem activity.

Most importantly, HOL Guard keeps enforcement independent from the agent model:

Model output is evidence, not authority.

An AI agent can explain its intent, but it cannot approve its own behavior or weaken the policy applied to it.

What we learned

This work reinforced several design principles that now guide HOL Guard.

The first is that agent security has to operate at the execution boundary. Scanning prompts or reviewing outputs is not enough once an agent can read files, call tools, modify systems, or communicate externally. The most reliable control point is immediately before an action runs.

The second is that policy needs structure and context. Evaluating the complete action produces better decisions than relying on isolated keywords. A safe command should continue without friction, while a dangerous action hidden inside the same workflow should still be detected.

We also validated the importance of separating agent reasoning from enforcement. AI models can provide useful context about intent, but they should not approve their own actions or determine the policy applied to them. HOL Guard keeps that decision independent, deterministic, and auditable.

Finally, the same control model applies well beyond engineering. The underlying risk is consistent whether an agent is changing infrastructure, accessing CRM data, handling internal research, deleting content, or publishing externally.

These lessons strengthened our conviction that organizations need a shared security layer for AI agents, with clear policies, human approval where appropriate, and durable evidence for every consequential action.

What's next for HOL Guard

Our next goal is to make HOL Guard a common control layer for AI agents across the organization.

We plan to expand supported agent harnesses, tools, MCP environments, and non-engineering workflows while maintaining a consistent policy and evidence model.

We are also working toward better organization-wide controls, shared policies, approval routing, integrations with existing security workflows, and clearer visibility into what agents are attempting across teams.

The long-term goal is simple:

Organizations should be able to adopt autonomous AI without giving it unchecked authority over their devices, data, and systems.

The agent proposes.

HOL Guard decides whether it executes.