An AI agent firewall checks every request an agent is about to send. Reads pass. Logins, signups, purchases, uploads and unknown writes are stopped.
This page explains what it must block, how it differs from tools with similar names, and how to run a free one built on an AI agent allow list.
An AI agent firewall sits between an agent and the internet. It decides, per request, whether the agent may send it.
It judges the destination and the method, not the words the agent was given.
Three of five requests are stopped. The agent keeps its ability to research, and loses its ability to act where it should not.
That is the whole idea in one picture.
The word "firewall" is used for very different products. Only one of them controls where your agents go.
Protects your website from incoming attacks.
It never sees what your agents send to other sites.
Filters prompts and model outputs for injection or leaks.
It reads text, not destinations.
Keeps other people's agents off your own site.
The opposite direction from this page.
Controls what your own agents may request on other sites.
Outbound, per URL, before the request.
About 60 hosts denied whatever the page, such as cloud metadata addresses.
The domain's verified login, signup, checkout and upload URLs, from 40M+ domains.
About 40 patterns that recognise risky endpoints on any site.
Reads pass, unknown writes are denied. Strict agents can deny unknown reads too.
Every verdict names the layer and rule that decided it. That makes each block explainable in a log or an audit.
Agent Egress Guard is our free, Apache 2.0 agent firewall. It runs on your machine with no dependencies and no network calls.
For common Python HTTP clients, browser automation and an intercepting proxy.
New in 0.2.0: one policy file per agent, built with the policy builder.
An API key adds verified page URLs for 40M+ domains. The licensed rule set adds 40 rules and 60 hosts.
| Capability | Free edition | With licensed rules and the database |
|---|---|---|
| High-risk hosts | 2 cloud metadata hosts | About 60 curated hosts |
| URL rules | 3: login, signup, password reset | About 40, including wiki edits, WebDAV and plugin installs |
| Verified page URLs | None | 28 page types for 40M+ domains |
| Unknown writes | Denied | Denied |
| Per-agent policy files | Yes | Yes |
| Cost | Free, Apache 2.0 | API from $99 a month, databases from $14,999 |
The free edition already stops common login and signup forms and every unknown write. The full data adds verified pages on each domain, so hidden login and checkout URLs are caught too.
| Agent type | Where the firewall runs | What it catches |
|---|---|---|
| Script agent using an HTTP client | Inside the client, as a hook | Every request the tool code sends |
| Browser automation agent | In the browser context, as a route handler | Every page load and form submit |
| Agent in a container | An intercepting proxy the container must use | All traffic, whatever the code does |
| Agent using an MCP fetch server | Inside the MCP server | Every client that calls the fetch tool |
| Many agents across a company | The central egress proxy | Everything, with one log |
Use two layers where you can: a hook inside the agent and a proxy outside it. If one is bypassed, the other still decides.
Both layers should read the same policy file, so an agent gets the same answer whichever layer sees the request first.
For browser agents, the proxy matters most. Pages load many resources, and only a network-level check sees them all.
| Question | Agent firewall | Prompt filter | Domain blocklist | Secure web gateway |
|---|---|---|---|---|
| Sees the URL before the request | Yes | No | Domain only | Yes |
| Knows a page is a login page | Yes | No | No | Rarely |
| Blocks writes, allows reads on the same site | Yes | No | No | Partly |
| Per-agent rules | Yes | Varies | No | Per user |
| Stops injected instructions | Limits the damage | Detects | No | No |
| Deterministic answer | Yes | Model-based | Yes | Yes |
A prompt filter and an agent firewall work well together. One looks for hostile instructions, the other limits what any instruction can achieve.
/%6Cogin is /login to the server. A naive string match misses it.
2852039166 and 0xA9FEA9FE both mean the cloud metadata address.
Old wikis accept edits through plain links, so method checks alone fail.
Real login pages sit on subdomains and locale paths, not only /login.
An agent with raw sockets can skip a hook. Put a proxy in the path too.
/login;jsessionid=1 is still the login page and must be treated that way.
Agent Egress Guard normalises all of these before any rule runs. Its tests include each case.
When you evaluate any agent firewall, test these six cases first. They separate a real control from a string filter.
Run the firewall in observe mode for a week. Record every verdict without blocking.
Check which denials would have broken real tasks. Usually very few.
Block credential, money and publishing pages first. They carry the most risk.
For autonomous agents, deny unknown destinations and add narrow exceptions.
Guessing /login misses most real ones. Ask for verified URLs.
A GET to a pricing page and a POST to it are different risks.
For agents, a failed check should deny.
A coding agent and a sales agent need different rules.
Layer and rule names make reviews fast.
Regulated teams may need the data inside their network.
A market research agent compares twelve software vendors. Here is what its firewall log shows.
Read page types, verified per domain. The agent collects plans and prices.
More read pages. The agent checks feature limits and uptime history.
The pricing page said "sign up to see enterprise prices". The agent tried. Layer 2, page type signup.
The agent tried to ask a question under a blog post. Layer 2, page type comment.
A link in a PDF pointed to a file-sharing site. Strict policy, unclassified destination.
The agent finished its task. Three risky actions never happened.
None of the three denials needed a person to notice anything. The owner reads them in the weekly review.
Without the firewall, the same day ends with a trial account, a public comment and a file on an unknown host, all in the company's name.
Which agent tried what, and which rule stopped it.
Proof that the written policy ran on real requests.
Denials that broke a task show where an exception is needed.
| Agent | Allowed page types | Unknown destinations | Typical exception |
|---|---|---|---|
| Market research | pricing, documentation, blog, press, case studies | Deny | None |
| Support answers | help centre, status, documentation | Deny | None |
| Procurement | pricing, legal, security, about | Deny | Checkout on one approved supplier, with approval |
| Coding assistant | documentation | Allow reads | Package registry downloads, never uploads |
Build any of these in the policy builder and enforce it with Egress Guard 0.2.0.
Read pages stay open, so research keeps working. Start in log-only mode and see for yourself.
Instructions can be ignored or overridden by injected text. A firewall gives the same answer every time.
Trusted sites have signup, checkout and upload pages too. Page-level rules keep the site open and the actions closed.
Good, keep it. Prompt filters read text; the firewall reads destinations. You need both.
Per agent. A sudden rise often follows a model or tool change.
Requests no layer could classify. Should trend down as policies mature.
Keep the list short and check every end date.
As a share of all agents. The target is every agent that can reach the web.
Identity decides what the agent may reach with its own credentials.
The firewall decides which outside pages it may open at all.
The gateway decides which tools an agent may call.
The firewall decides which URLs those tools may fetch.
Filters look for hostile instructions in text.
The firewall limits what any instruction can make the agent do.
Traces show what the model said.
Firewall verdicts show where the agent actually tried to go.
The register holds each agent's web rules.
The firewall is where those rules run.
Testers try to push agents onto risky pages.
The firewall's denials are the result they check.
Traffic leaving your systems for the internet.
The firewall's answer for one request: allow, deny or ask the owner.
What a URL is on its site, such as pricing, login or checkout.
A page where the agent does something: signs up, buys, uploads or posts.
If the check cannot answer, the request is denied.
Anything nobody classified or approved is blocked.
The honest fine print — the same two assumptions we publish, plus two operational ones
Free, local, and explainable. Add the page-type data when you need full coverage.
