Trust Before Tool Call: Why We Built HOL Guard

AI coding agents can do real work.

They can read files, run commands, install packages, modify repositories, register MCP servers, and connect to remote tools. That makes them useful. It also means they introduce a new trust surface directly on a developer’s machine.

An agent action is not just a chat response. It can become a shell command, a package install, a file read, a credential exposure, a workflow change, or a new tool endpoint your harness can call later.

Logs still matter. Sandboxes still matter. Static scanners still matter.

But they are only part of the story.

Teams also need a way to decide what an AI agent is allowed to do before the tool call completes.

That is why we built HOL Guard.

HOL Guard is a local-first control layer for AI coding agents. It intercepts risky actions, pauses dangerous tool calls, records decisions, and gives developers and teams a clear policy layer between the agent and the machine.

The goal is simple: make agentic coding safer without asking developers to stop using the tools that are making them faster.

The problem

Most existing security tooling was not built for this workflow.

A linter can catch syntax issues. A dependency scanner can flag known vulnerabilities. A secret scanner can detect some exposed credentials after they exist in a repository.

Those tools are useful, but they do not answer the questions developers now have while working with AI agents:

• Why is this agent reading my .env file?

• Who approved this package install?

• Did this MCP server register silently?

• What command did the agent actually run?

• Was this decision reviewed, blocked, or allowed?

• Can my team apply the same policy everywhere?

• Is there a receipt we can inspect later?

That gap gets bigger as coding agents become part of daily development.

The risk is not only bad code. The risk is agent behavior that moves faster than review.

What HOL Guard does

HOL Guard was built specifically for AI coding workflows.

It sits between the agent harness and the local system, then watches for actions that should not happen silently. When a risky action appears, Guard can pause it, show what is happening, apply policy, and capture a decision receipt.

Guard is not trying to replace developer judgment.

It is trying to make sure judgment happens at the right moment.

Before the install.

Before the secret is read.

Before the remote endpoint becomes part of the agent’s tool surface.

Before a bad default becomes a normal workflow.

Guard protects several important surfaces.

1. Tool-call interception

The most important moment is before execution.

If an agent tries to read a sensitive file, call a dangerous command, or touch a protected path, Guard can intercept that action before it completes.

That matters because a lot of agent risk happens in a single round-trip.

By the time you see it in a log, the action may have already happened.

Guard changes that. It gives developers a real decision point while the action is still pending.

2. Install protection

AI coding agents often suggest and run install commands.

That can be helpful. It can also be risky.

A package install can introduce malicious dependencies, unexpected postinstall scripts, typo-squatted packages, or new supply-chain exposure.

Guard wraps install flows for package managers like npm, pip, and cargo so developers can see what the agent is trying to install and how that action was handled.

The point is not to block every install.

The point is to stop treating agent-generated installs as harmless by default.

3. MCP registration control

MCP servers extend what an agent can access.

That makes them powerful. It also makes them sensitive.

A remote MCP endpoint is not just another URL. It can become a new capability surface for the agent. If that registration happens silently, the developer may not understand what was added, who controls it, or what the agent can now call.

Guard pauses risky MCP registration before execution.

It gives the developer or team a chance to review the endpoint, apply policy, and decide whether it belongs in the environment.

That is a basic trust requirement for any serious agent workflow.

4. Secret-bearing file protection

Some files should never be casually opened by an AI agent.

.env files, npm credentials, API keys, local config files, private keys, and deployment credentials are obvious examples.

The problem is that agents often operate through normal file tools. A read can look like any other tool call.

Guard treats secret-bearing file access as a decision point.

If an agent tries to open a sensitive file, Guard can stop the action, show what is happening, and require approval before the file is exposed.

That is the difference between reviewing access and discovering exposure after the fact.

5. Receipts and audit trails

Security decisions should not disappear into terminal history.

Guard records blocks, approvals, reviews, and policy decisions as receipts. Those receipts can be inspected locally, exported, and used across team workflows.

That matters for real organizations.

If a team is going to allow AI agents into development environments, they need more than vibes. They need a record of what happened, what was allowed, what was denied, and why.

Receipts make agent behavior easier to review.

They also make policy easier to improve over time.

6. Scanner and ecosystem readiness

Guard also includes a scanner path for agent extension ecosystems.

That matters because runtime protection and pre-release review solve different problems.

Before an extension, plugin, skill, or workspace bundle is published, maintainers should be able to check whether it is structured safely. That includes manifest validation, MCP posture, marketplace metadata, installability, maintenance signals, and skill-level security checks.

Then, once developers start using agent harnesses locally, Guard enforces runtime decisions where they actually happen.

The scanner helps maintainers ship cleaner extensions.

Guard helps developers run agents with control.

Both are part of the same trust layer.

Why the local-first model matters

We did not want Guard to become another black box.

A tool that protects your development environment should not require blind trust in someone else’s server.

That is why Guard is local-first.

Your code, prompts, configs, approvals, and receipts stay on your machine unless you explicitly opt in to sync or team features.

That model matters for developers. It matters even more for companies.

The agent security layer should be inspectable. It should be portable. It should not trap your data. It should not require sending sensitive development context somewhere else just to make a local policy decision.

Guard is built around that principle.

Built for real workflows

Guard is designed to fit into the way developers already work.

It can be installed locally. It can be connected to common AI coding harnesses. It can enforce policies during day-to-day coding. It can produce receipts that teams can review later.

For maintainers, the scanner can run in CI and help gate releases before plugins or extensions are shipped.

For teams, shared policies can make reviews more consistent across developers instead of forcing every person to make the same judgment alone.

That is the workflow we care about.

Not a dashboard people forget to check.

Not a report that arrives after the damage is done.

A control layer that shows up at the moment the agent is about to do something risky.

More than a guardrail

One thing we cared about from the start was making Guard useful beyond a single blocked command.

A good agent security layer should become part of the broader trust infrastructure around AI development.

That means:

• local policy enforcement

• approval receipts

• team review flows

• scanner results

• CI gates

• trust badges

• registry ingestion

• extension quality signals

In other words, Guard is not only for the person sitting at the terminal.

It can also help teams, maintainers, registries, and ecosystems understand which agent extensions are safe enough to use, publish, and recommend.

That is where this becomes bigger than one CLI.

What this means for the ecosystem

We think AI coding agents need a trust layer.

As more developers use agents to write, install, configure, and ship software, the challenge is no longer just whether the agent can complete a task.

The challenge is whether the developer can trust the path it takes.

That does not mean every action should be blocked.

It does not mean one score should replace human review.

It means the obvious risks should be easier to catch. The dangerous actions should not happen silently. The review process should be more consistent. The team should have a common baseline for what agents are allowed to do.

That is the role HOL Guard is meant to play.

Why we built it

We built HOL Guard because trust should not be an afterthought.

AI coding agents are becoming part of real software development. They are no longer just suggesting snippets. They are operating inside repositories, running commands, changing configuration, and connecting tools together.

That requires a different kind of security model.

Not generic security theater.

Not a checklist copied from traditional application security.

Something purpose-built for the way agents actually behave.

That is what Guard is.

A local-first control layer for AI coding agents that gives developers and teams a way to stop, review, approve, deny, and audit risky actions before they become incidents.

Get involved

If you are using Codex, Claude Code, Cursor, Gemini CLI, OpenCode, MCP servers, agent plugins, or custom AI coding workflows, try Guard on your own setup.

If you maintain agent extensions, use the scanner path to catch issues before release.

If you run a team, start thinking about which agent actions should require policy, review, or receipts.

The ecosystem will be healthier if agent behavior is easier to inspect, easier to control, and easier to trust.

Trust should happen before the tool call.