What Is an AI Agent Firewall? A Plain-English Guide

Chatbots talk. Agents act.

Not long ago, most companies used AI to write. A person asked a question, the model answered, and a person decided what to do with the answer. If the answer was wrong, the damage stopped at a bad paragraph.

Agents are different. An agent can open a pull request, run a database query, call a payments system, file a ticket or reply to a customer on its own. It reads the world through tools, and it changes the world through tools. That's the whole point. It's also the problem.

We run AI agents inside Aptibit every day, on our own code and our own systems. The question that kept us up at night wasn't "will the model say something odd?" It was "what happens if it does something we didn't mean, at three in the morning, with nobody watching?" That question is what an AI agent firewall exists to answer.

What is an AI agent firewall?

An AI agent firewall is a checkpoint between an agent and the systems it can touch. Every action the agent tries to take passes through it first. The firewall compares the action with the company's own rules and decides what happens next, before anything takes effect.

The word comes from networking, and the comparison is useful up to a point. A network firewall doesn't care what an email says. It cares where traffic is going and whether that's allowed. An agent firewall cares about the action: which tool, which arguments, which data, which system, and on whose behalf.

In practice it behaves less like a spam filter and more like a careful senior colleague. It looks at a proposed change and asks three questions. Is this allowed? Is it safe? Should someone else see it first?

How is it different from prompt filters and guardrails?

These terms get mixed up all the time. They're all useful, and they're not the same thing. Here's how we use them.

• Prompt filters look at text going into the model. They try to catch a harmful request or a known attack phrase before the model sees it.
• Guardrails usually shape what the model says. They might keep it off certain topics, force a format, or check an answer for toxic content.
• An agent firewall checks what the agent is about to do. It looks at the tool call, the database query, the infrastructure change or the outgoing reply, and decides whether it goes ahead.

Why the action is what matters

The difference between those three is where they look. Text filters guess at intent. An action check judges the consequence. If an agent has been tricked by a hidden instruction in a web page, a prompt filter may never see the trick, because it arrived through a tool result rather than the user's prompt. But the action the agent then attempts, such as emailing a customer list to an unknown address, is concrete. It can be checked.

The OWASP Top 10 for LLM Applications 2025 makes the same point from the risk side. Next to prompt injection, it lists Excessive Agency as a risk of its own, and the OWASP entry on Excessive Agency traces it to excessive functionality, excessive permissions and excessive autonomy. Those are problems with what an agent can do, not with what it says.

Check actions, not just words

If you're weighing up any approach, start with a list of what your agents can actually change. Don't forget the inputs. Agents fail through what they read as often as through what they do, which is why the OWASP guidance on prompt injection recommends segregating external content and requiring human approval for high-risk actions.

Tools deserve the same suspicion. Simon Willison has written about tools that change their own definitions after installation, so the tool you approved last week may not be the tool your agent calls today. For most companies, the list of things to check looks something like this, and a firewall should be able to judge every item on it.

• Code changes. Is the agent editing files it shouldn't, switching off a test, or adding a dependency nobody approved?
• Database changes. How many rows would this update or delete? A query that touches 12 rows and one that touches 12 million look almost the same as text.
• Infrastructure changes. Does this plan open a port to the internet, delete storage, or change who has access to what?
• Tool calls. Is this a tool the agent is allowed to use, with arguments that make sense? Does the tool even exist?
• Replies and messages. Does the outgoing text contain a password, an API key (a secret code that lets software into another system), a card number, or a link to a site nobody approved?
• What comes back. Documents, web pages and tool results can carry hidden instructions. They need checking before the agent acts on them.

A good firewall does more than say yes or no

A control that can only say yes or no gets switched off. If it blocks a useful reply because one line contained a phone number, people will route around it within a week.

A better design has more options. It can allow the action. It can fix it, by removing the risky part and letting the safe part through. It can hold it for a person to approve. Or it can block it and tell the agent why, so the agent can try a safer path instead of failing silently.

That last detail sounds small. In practice it's what keeps agents useful. An agent told "blocked: this query would delete 40,000 rows, limit it to one customer" can often correct itself. An agent told nothing just retries, or gives up, and a person has to pick up the pieces.

What an agent firewall can't do

No single control stops everything, and anyone who tells you otherwise is overselling. The UK's National Cyber Security Centre put it plainly in December 2025: prompt injection attacks "may never be totally mitigated" in the way SQL injection attacks can be. OWASP says it's unclear whether fool-proof prevention methods exist at all.

A firewall also can't rescue a bad rule. If your policy allows an agent to drop production tables, the firewall will faithfully allow it. Rules come from your own judgement, and they need named owners and regular review, just like the rest of your security policy.

So treat a firewall as one layer. It works best alongside a few old, boring habits:

• Least privilege: each agent gets only the tools and permissions its job needs.
• Short-lived credentials, so a leaked key stops working quickly.
• Good records of what agents did, kept somewhere the agents can't edit.
• Reviewers who have the time and context to judge held actions, not just click approve.

Questions to ask any vendor

Whether you buy or build, these questions separate real control from a good demo. Write the answers down, and ask to see each one working rather than described.

• Does it check actions (tool calls, queries, infrastructure plans, replies), or only the text of prompts?
• Can it test a risky database change before it runs, and show how much it would change?
• What can it do besides block? Can it fix, hold for approval, and explain its decision to the agent?
• Can we read and change every rule? Are there any rules we can't see?
• What happens if someone tries to weaken a protection? Is that change checked too?
• Does it inspect what comes back from tools and documents, not just what goes out?
• Can we start in watch-only mode and see what it would have done before it enforces anything?
• Where does our data go? Can it run on our own servers, including sites with no internet connection?
• Is every decision recorded as evidence we can trust later, and can we replay a session?
• Is there one switch that stops an agent, a team, or every agent at once?

Why we built Cognilox

We built Cognilox because we needed it. Aptibit runs AI agents on its own work, and we wanted every action they take to be checked against our rules before it lands.

Cognilox checks each action an agent takes through it against the company's own rules: code, database and infrastructure changes, tool calls and replies. Risky database changes are tried first and rolled back, so you can see how much they would change. Infrastructure change plans are reviewed before they're applied. Then it allows, fixes, holds for approval or blocks, and when it blocks, it tells the agent why.

You own and can read every rule, and there are no hidden ones. A rule change that would remove a protection is refused. You can start in watch-only mode. It runs on your own servers, fully offline if you need it, or in Cognilox Cloud, and none of your data goes to Aptibit. If you'd like to see it on real agent actions, we're happy to give you a live demo.