Harden.Run AIF: an on-device firewall for coding agents

The gap AIF is aimed at: agents that act before you read the diff

A coding agent does not ask permission between deciding to run a command and running it. Claude Code, Codex, Cursor and Gemini CLI all execute shell commands, read files and call tools on your behalf. The usual safety net is a review step after the fact: you look at the transcript, notice the agent read a .env file, and rotate a key. Harden.Run AIF is built around the opposite position. It describes itself as a local system for coding agent safety, and the coverage table in the README lists pre-execution blocking for four agents: Claude Code, Codex, Cursor (IDE and CLI) and Gemini CLI. Kiro gets hooks for the main agent, with subagent MCP calls routed through a proxy. OpenClaw and Hermes are handled differently, through what the README calls block-and-steer via a bridge process.

The intended user is someone running these agents on a laptop or workstation with real credentials in reach. That is a narrower audience than "anyone using AI," and the README does not pretend otherwise. The tool is local, the dashboard binds to 127.0.0.1, and the telemetry section is explicit that code, commands, file paths and prompts are not collected. Whether the blocking logic is rule-based, model-based or signature-based is not stated in the README, so treat the decision engine as a black box until you read the trust page or the source.

How the blocking actually attaches to an agent

AIF does not wrap your agent in a sandbox or intercept syscalls. It attaches where each agent already offers an extension point: hooks. For Claude Code, Codex, Cursor and Gemini CLI, the README says the integration uses native hooks with pre-execution blocking. That means the agent calls out to AIF before a tool call runs, and AIF returns a decision. A block at that point stops the action; a pass lets it through. This is why the supported-agent table matters more than any feature list. An agent without a hook point cannot be covered the same way, and the README is honest about that: Kiro's main agent gets hooks, but its subagent MCP calls go through a proxy, and OpenClaw and Hermes use a bridge process with block-and-steer semantics.

The second visible piece is the dashboard. The README states that aif show serves a local dashboard at http://127.0.0.1:47391/, and that aif show --tui gives a terminal view. The port is fixed in the documentation, which tells you the process is meant to be local-only. Nothing in the README describes a remote management API or a team console, so the operational model is per-machine. If you manage a fleet of developer laptops, that is a real constraint: you would be configuring each machine, not a central policy server.

Installing AIF and running your first blocked action

The README gives a single install path, a shell script fetched over HTTPS and piped to sh. There is no package manager command, no Homebrew formula and no container image mentioned.

curl -fsSL https://aif.harden.run/install.sh | sh

Piping a remote script into a shell is a decision you should make deliberately, especially for a tool whose job is to police what other software executes. The README does not document a checksum, a signature or a manual download alternative. If that matters to you, verify the script before running it.

After install, the README lists four commands. The first is configuration, the second is a demo, and the last two open the dashboard in web and terminal form.

aif configure
aif demo
aif show
aif show --tui

What you should see: aif configure sets up the agent hooks and whatever policy the tool ships with. aif demo is the interesting one, because it is the only documented way to watch a block happen without pointing a real agent at a real secret. The README does not describe what the demo executes, so the safe expectation is a scripted example rather than a live test against your own files. aif show then opens http://127.0.0.1:47391/ in a browser, and aif show --tui renders the same view in the terminal. If the dashboard does not load, check that nothing else holds port 47391 before assuming the install failed.

Telemetry you can inspect before it leaves

Most tools in this category ask you to trust a privacy paragraph. AIF ships a command that prints the payload. The README states that aif telemetry show prints the exact payload before it is sent, and frames it as a secret-safety tool inspecting its own egress. That is a design choice worth noting: the claim is verifiable on your own machine, not just asserted in a policy document.

The stated scope is anonymous operational counters: version, OS and architecture, which adapters are in use, and decision and block counts. The README explicitly says code, commands, file paths and prompts are not collected. Opting out is one environment variable, AIF_NO_TELEMETRY=1. The full schema is on the trust page rather than in the README, so if you need to audit field by field, that is where to look. A reasonable first move after install is to run aif telemetry show, read the output, and then decide whether to keep it on. The counters alone are low-risk; the point is that you can check rather than assume.

What the README does not tell you

The biggest gap is the rule model. Nothing in the README explains how AIF decides that a command is dangerous. There is no example policy file, no syntax for allow and deny entries, no description of whether detection is pattern matching, entropy checks on file contents, or something else. For a firewall, that is the core question, and the documentation answers it only by pointing at the trust page. Until you read that page or the source, you cannot predict what AIF will block, which means you cannot tell a false positive from correct behavior.

The second gap is rollback. The README does not document how to remove the hooks from Claude Code, Codex, Cursor or Gemini CLI, nor how to uninstall the tool. If aif configure writes into agent configuration files, and the README does not say it does not, you should back those files up first. The third gap is failure behavior. If the AIF process is not running, or the hook call times out, does the agent proceed or stop? The README is silent. For a blocking layer, fail-open versus fail-closed is the difference between an annoyance and a security hole, and you should test it rather than guess. The fourth gap is the licence. The repository reports NOASSERTION and ships a LICENSE.txt and a NOTICE file, so the terms exist but are not summarized anywhere in the README. Read LICENSE.txt before you deploy this inside a company.

Where AIF is the wrong tool, and what to use instead

AIF is the wrong tool when your agents are not on the supported list. If you run Kiro with heavy subagent MCP usage, the README's own description puts you on a proxy path rather than native hooks, which is a different trust story. If you run OpenClaw or Hermes, you are on a bridge process with block-and-steer, and the README does not claim pre-execution blocking there. Read the coverage table as a compatibility matrix, not marketing.

A real alternative in this space is a sandboxed execution environment, for example running the agent inside a container or a microVM with a restricted filesystem and no network by default. The difference in approach is fundamental. AIF sits inside your normal environment and inspects the agent's intent before it acts; a sandbox assumes the agent will misbehave and removes its ability to reach anything you did not mount. Sandboxing is stronger against an agent that finds a path AIF's rules do not cover, and weaker at letting the agent do useful work, because every capability has to be granted explicitly. AIF is lighter to adopt and keeps your normal toolchain, at the cost of depending on the quality of its detection rules. Some teams will want both. The README does not discuss sandboxing, so treat that as a separate layer, not something AIF replaces.

Maintenance, diagnostics and licence terms

The repository is not archived, and the last push was on 2026-09-05, which is recent. That tells you the project is being worked on, and nothing more. There are no retrieved releases, so there is no version history to read. Upgrades run through the same install script, and the README does not describe a versioned upgrade path, a changelog or a rollback procedure. Plan for the possibility that re-running the installer is the only documented way to update, and keep your agent configuration files under version control so you can see what aif configure changes.

For support, the README points at two channels: email security@harden.run, and a private report through the repository's Security tab using GitHub Security Advisories. Both expect the output of aif doctor --bundle, which the README shows writing to a file:

aif doctor --bundle > aif-diagnostics.txt

That file is what you attach to an issue. Before you send it anywhere, open it and read it, because a diagnostics bundle from a security tool can contain more than you expect. The README does not describe what the bundle includes.

On licensing, the repository reports NOASSERTION rather than a recognized SPDX identifier. A LICENSE.txt and a NOTICE file are present at the top level. That combination sometimes means a custom or modified licence. Whether you can use AIF commercially, redistribute it, or embed it in a product is a question for LICENSE.txt and your own counsel. Nothing here is legal advice.

Editorial conclusion

Adopt AIF if you already run Claude Code, Codex, Cursor or Gemini CLI and want a blocking layer that sits in front of tool execution rather than a scanner that reports afterwards. Skip it if your agents are Kiro subagents, OpenClaw or Hermes, where the README describes a bridge process instead of native hooks, or if you need documented rule syntax before you deploy. Verify three things first: that aif configure writes a policy you can read, that aif doctor --bundle produces a diagnostics file you are willing to attach to an issue, and that AIF_NO_TELEMETRY=1 actually silences egress from your machine.

Frequently asked questions

Official sources

1. hardenrun/aif on GitHub
2. Issues
3. Project website
4. README