Agent Firewall
A policy engine that checks tool calls before execution.
An instruction in a prompt does not enforce a tool policy. The code that executes a call needs its own checks.
I built Agent Firewall to inspect tool arguments, return a policy decision, and record the reason for that decision.
- Tool callName + arguments
- PolicyFirst matching rule
- DecisionAllow, hold, or block
- RecordDecision + reason
The first matching rule decides
Rules are evaluated in order. A rule can allow a call, require human approval, or block execution. A call that matches no rule is blocked.
Matchers inspect argument types such as URL components, email domains, filesystem paths, and SQL operations. This lets a policy distinguish calls to the same tool.
| Call | Decision |
|---|---|
Read-only database.query
|
Allow |
email.send to a company recipient |
Allow |
email.send to another recipient |
Require approval |
browser.navigate
|
Block |
The email rules show why the arguments matter. Permission to use a mail tool does not imply permission to send to every recipient.
Checks run before the tool
The Python API, command-line interface, and Model Context Protocol proxy use the same policy engine. The engine uses the Python standard library.
Call-budget capacity is reserved before execution. Malformed calls are rejected, and a stalled tool server is treated as a block.
SQLite stores the local counters. An append-only JSONL log records decisions with a reason and rule index. Arguments are hashed rather than stored as plaintext.
The policy still needs human judgment
A permissive rule permits the behavior it describes. The firewall cannot determine whether an allowed action is appropriate for the user's goal.
Budgets are local to one machine. They do not enforce a shared limit across a fleet of agents.
Approval is a prompt rather than a managed queue. The implementation does not provide delegation or a timeout policy for unanswered requests.