AI agent firewall: what the control actually has to decide

The name is borrowed, the decision is the real thing

A network firewall reads packets. This reads a proposed action: the tool being called, the arguments as resolved, and the person the agent is acting for. A model guardrail checks text going into or coming out of a model, which is worth doing and does nothing about an agent that has already decided to send the email. The control you want sits where the action would leave, and it has to be the only way out. If the agent can also reach the system directly with a key of its own, what you have built is a suggestion.

The standalone vendors were bought during 2026

Anyone shortlisting a point product should know what happened to the category. Through 2026 SentinelOne acquired Prompt Security, Cato Networks acquired Aim Security, Check Point acquired Lakera, Palo Alto Networks acquired Protect AI, and Cisco acquired Robust Intelligence. WitnessAI stayed independent and shipped Agentic Control in June 2026, adding discovery and monitoring, plus runtime restriction of agent behaviour and of MCP servers specifically. An independent 2026 survey by AgentSwarms found open source projects, SaaS products, cloud-native services and edge deployments all implementing the same idea, which says this names a job rather than a product shape. Expect the vendor names above to keep moving.

What the control has to decide, and on what

A demo will show you a block. What matters is the shape of the decision underneath it, so ask about each of these directly.

• The resolved arguments, rather than the agent's summary of them. An argument the control cannot read is an argument it cannot constrain, so a tool with no schema should be refused outright.
• The person the agent is acting for and what that person is entitled to, so authority narrows as the run proceeds instead of widening.
• Whether the action changes something elsewhere. Effectful actions need a floor that a written rule cannot lower. Read-only calls can be cheaper to allow.
• The organisation's own rule for that specific tool, written by whoever bound it, in their own words rather than as a regular expression.
• What happens when the deciding component cannot answer. Anything effectful goes to a person. Any other default lets the action proceed when the control is unavailable.
• What gets written down: the proposed action with its arguments, the decision, the approval if one was asked for, and the outcome.

Test it against a named list

OWASP's Top 10 for Agentic Applications 2026, published on 9 December 2025, was built from documented 2025 incidents rather than speculation, including EchoLeak (CVE-2025-32711), a zero-click data exfiltration route. Excessive Agency, LLM06 in the 2025 LLM Top 10, names the failure most teams actually have: an agent granted more functionality, permission or autonomy than its job needs. Run a candidate against those categories and ask to read the record of each attempt afterwards. Detection-accuracy numbers in this category are vendor self-published, Lakera's PINT benchmark included, so treat any percentage as the vendor's own measurement of itself.

Putting one in place

The order matters, because most of the value arrives before any policy is written.

• Take the credentials away from the agents first. Until the agent has no key of its own, everything after this is optional from the agent's point of view.
• Give every tool a schema. Refuse what has none.
• Mark each tool as effectful or read-only, and set the floor for the effectful ones before anyone writes a single rule.
• Write the per-tool rules in the words of the person accountable for the job, then check them against a run rather than against a document.
• Decide the failure behaviour and the approval path, then test both by breaking the dependency on purpose.
• Read one full record from start to finish with risk or audit in the room. If they cannot follow it, the control is not finished.

How Difinity.ai's tool gateway does it

What the market calls an AI agent firewall is, in Difinity, the tool gateway. Every action an agent takes leaves through it, it is not reachable from the internet, and neither a customer nor an agent calls it directly. The agent holds no credential and cannot reach a system itself, so the tool gateway holds the credential, applies the rules the organisation set, then decides and acts. Under each bound tool the author writes when the agent may use it, in their own words, and a judge reads that text rather than a parser matching it. Anything effectful is reviewed whatever the written rule says, a floor no rule can lower. Where the judge cannot settle a call, including when the model behind it cannot be reached, an effectful tool escalates to a person regardless of the posture configured for it. The tool gateway refuses a tool when it holds no schema for it. When an action needs a person, only the person the agent is acting for can answer it, they are shown the whole action and its arguments rather than a summary, and the signed answer is checked against the stored action before anything runs.

Where the firewall metaphor stops helping

A network firewall is deployed at a boundary that already exists. This control only works if it is the only way out, which makes it an architecture decision rather than a product you place in front of something. Two honest limits. Every vendor capability on this page comes from that vendor's own material, because none of it was trialled live for this write-up. And a control at the action boundary does nothing about a bad answer that never becomes an action, which is what the guardrails on the model path and a person reading the output are for. Anyone selling you one control for both problems is selling.