What Is an Agent Firewall?

An agent firewall is a control that inspects an AI agent’s actions — tool calls, shell commands, file writes, network requests — and enforces policy on them in the execution path, before they run. The decision is deterministic: a given action, from a given identity, under a given policy, produces the same verdict every time — allow it, block it, or hold it for a human. It governs what the agent does, not what the model says.

That last distinction is the whole point. A conventional firewall filters packets. Content guardrails filter text. An agent firewall filters actions: rm -rf, git push --force, a POST to an unknown domain, a write to a credentials file. It sits at the moment of execution — the only moment an action can actually be stopped.

Why the term is emerging now

For most of the LLM era, safety work meant governing model output: system prompts, content filters, classifier guardrails. Those are probabilistic controls on text. Agents changed the risk model. An agent doesn’t just produce text — it executes: it runs commands, edits files, calls APIs, spends money. A prompt-level guardrail can be argued with, injected around, or simply wrong some fraction of the time. An action that has executed cannot be un-executed.

The industry is converging on execution-path enforcement from three independent directions:

• Products. Coder ships an “Agent Firewall” — a process-level control that runs terminal agents inside an isolated jail, funnels their traffic through a proxy, enforces a domain/method allowlist, and streams every allow/deny decision to a control plane as an audit log. Pipelock is an open-source “AI agent firewall” that sits between the agent and the network, scans HTTP, WebSocket, and MCP traffic for exfiltration and injection, and emits signed action receipts as audit evidence from outside the agent’s trust boundary.
• Research. Progent (Shi et al.) formalizes agent security as privilege control: security policies expressed as “symbolic rules over tool names and arguments,” with every tool call validated “through a deterministic procedure, enforcing the principle of least privilege.” ActPlane (Zheng et al.) is titled, in part, “Policy Enforcement for Agent Harnesses” — it pushes enforcement into the OS kernel via eBPF so that policies cover every execution path an agent can take.
• Practice. Teams running coding agents in full-auto discovered the hard way that the harness’s own guardrails don’t hold. We read the guardrails of eleven agent harnesses — in each one’s permissive mode, almost nothing the vendor ships still stops a catastrophic command. If you want a floor, you have to install one that the harness’s own settings can’t switch off.

Different builders, different layers, same conclusion: the enforcement point for agent risk is the action.

What an agent firewall is not

Not a network firewall. A network firewall reasons about packets: IPs, ports, protocols. It has no concept of “the agent is about to force-push to main” — that action may never touch the network at all. An agent firewall reasons about actions with their arguments: which tool, which command, which file, which repo, invoked by which identity.

Not LLM guardrails. Guardrails are content-layer and probabilistic — a model or classifier judging text, with some error rate, before or after generation. An agent firewall is action-layer and deterministic: a policy rule matching a concrete tool call. The two compose. Guardrails shape what the model proposes; the firewall decides what the harness executes. Progent’s framing is precise here: the validation of each call is a deterministic procedure, even when a model helps author the policy.

Not an LLM gateway. A gateway sits on the wire between the agent and the model provider. That position is genuinely useful — spend limits, routing, redaction — but it cannot see actions the harness executes locally. When a coding agent runs a shell command, no model-provider traffic carries the action; the gateway sees the conversation about it, after it ran. We’ve written about this boundary in detail: an LLM gateway governs what the model says; your risk is what the agent does.

Not a sandbox. A sandbox is containment: it bounds what an agent can reach (filesystem, network, syscalls). A firewall is policy: it decides what the agent may do, action by action, and can say “ask a human” — a verdict a sandbox has no way to express. Containment without policy blocks whole categories or nothing; policy without containment trusts the interception point. You want both, and the research community itself is still debating where interception belongs — ActPlane argues tool-call-layer checks can miss indirect execution paths and puts enforcement in the kernel, while Progent shows tool-call-level privilege control substantially cutting attack success on agent-security benchmarks. Treat that disagreement as an argument for layering, not for picking a winner.

Anatomy of an agent firewall

Whatever the vendor calls it, the working parts are consistent:

1. An interception point in the execution path. Harness hooks that fire before a tool call, a proxy the agent’s traffic must transit, or a kernel-level monitor. The requirement is the same: the action must pass through the check before it executes, not be reported after.
2. A policy engine with three verdicts. Allow, deny, and — the one that makes agents usable — ask: hold the action and route it to a human with the full arguments in front of them. Policies match on the action and its arguments (Progent’s “symbolic rules over tool names and arguments”), not on vibes. Critically, the floor must survive the harness’s permissive mode: a policy the agent’s own yolo flag can disable is not a floor.
3. Identity attribution. Every verdict is attached to which agent, which run, which human it was working for. Without identity, an audit row is trivia; with it, it’s accountability — and per-identity policy becomes possible.
4. An audit trail outside the agent. Coder streams decisions to its control plane; Pipelock signs receipts from outside the agent’s trust boundary. The shared principle: evidence about the agent must not depend on the agent attesting to itself.
5. Budgets. Money is an action surface too. A runaway loop is spend executing without review; caps and per-identity budgets are the firewall rule for it. (Cost has its own discipline — see agent cost monitoring.)

FAQ

Is an agent firewall a silver bullet? No. It is one layer, and it inherits the limits of its interception point — a hooks-based firewall governs what flows through hooks; a network-based one governs egress; ActPlane exists because both can be sidestepped by paths they don’t cover. Pair it with sandboxes for containment, code review for what the agent produces, and least-privilege credentials for what the agent holds.

Do I need one if my agent asks for approval by default? Default modes aren’t the operating mode. Teams flip the permissive switch because approval fatigue is real — and in that mode, the built-in checks largely vanish. The firewall’s job is to be the part that doesn’t.

Does it slow the agent down? Interception adds a check per action. ActPlane reports 1.9–8.4% overhead for kernel-level enforcement in its evaluation; a policy decision is cheap next to a model call.

Isn’t “deny” enough — why “ask”? Deny-only forces policies to be either loose or paralyzing. “Ask” lets the risky-but-sometimes-right actions through a human, and each approval can become a standing rule — the policy learns from judgment instead of guessing at it.

Where it fits

An agent firewall is the enforcement half of a control plane. Enforcement decides each action; the control plane adds what enforcement alone doesn’t give you — identity across agents, cost metering, and one audit trail spanning every harness you run. ACP ships that: deterministic allow/ask/deny on every tool call via harness hooks (Claude Code, Codex, Hermes), a model-call proxy for spend, one log. If you want the firewall in place today, start here.