Cyber, Explained is our series unpacking the security terms your business keeps hearing, and cutting them down to what matters and what to do next.

There’s a pattern to how security terms enter the language. Something new appears, it clearly matters, and within a few months every vendor has a page explaining it. Read a handful of those pages side by side and you notice something odd: the term seems to mean whatever the vendor happens to sell. “AI firewall” is the clearest current example, and it’s worth slowing down on, because the confusion isn’t accidental.

Look at how the names have multiplied. One vendor describes an AI firewall as a network security system that uses machine learning to spot threats, which happens to be an AI-flavoured version of the firewalls it already makes. Another defines it as a layer that inspects the prompts and responses moving in and out of an AI model, which happens to be the product it recently launched. Elsewhere the same basic idea is sold as an AI gateway, or guardrails, or an agent firewall, or an AI proxy, each name tracing neatly back to whatever its maker built before AI arrived. A category analyst put it plainly this year: the space is barely two years old, and the firms that built network firewalls call their product an AI firewall, while the firms that built API gateways call theirs an AI gateway. None of them is wrong, exactly. Each has anchored the term to its own corner of the problem and left you to assume that corner is the whole room.

That would be harder to untangle if there were no neutral referee. As it happens, there is one. The OWASP GenAI Security Project, a vendor-agnostic body that has been a trusted authority in software security for two decades, publishes a Solutions Landscape that maps this market and updates it through the year. It’s worth knowing what it actually says, because it’s more precise than any vendor page. OWASP doesn’t really use the loose phrase “AI firewall” at all. It defines an LLM firewall: a layer that monitors and filters the prompts and responses going to and from an AI model, to block malicious inputs and stop data leaking out of the model. The broader frameworks sit one level above the product entirely. NIST’s AI Risk Management Framework describes how to govern AI risk. MITRE ATLAS catalogues how AI systems get attacked. ISO 42001 defines an AI management system. They set out the risks and the governance, and leave the labels to the market.

So the nearest thing to an official definition is quite specific, and it points at protecting AI applications you build. Which brings us to the interesting part, and the reason all this matters beyond pedantry.

Almost nobody asking us about AI firewalls is worried about that.

The business owners and IT leads raising this aren’t building their own language models or shipping customer-facing AI features. They’re worried about something much closer to home: their own staff, already using ChatGPT and its many cousins, and what leaves the business when they do. That’s not the OWASP LLM firewall problem. It’s a different problem that has been quietly wearing the same borrowed name, and it deserves to be described plainly rather than dressed up in someone else’s terminology.

It’s also the more urgent problem for most organisations, because it’s already happening at scale. In a 2026 survey of office professionals, two-thirds admitted using AI tools at work despite believing it broke company policy. In the UK, more than half had pasted work correspondence into public tools, and around a third had put customer data into them. Most of it runs through personal accounts that never touch a company’s security controls, which means for a lot of businesses the true answer to “how are our people using AI” is simply “we don’t know.”

You’ll sometimes hear the EU AI Act raised as the reason to move on this, and it’s worth being accurate, because the timeline shifted in 2026. The Act’s most demanding obligations for high-risk AI systems were pushed back to December 2027, and in any case they govern organisations building high-risk AI, not employees using a chatbot. The exposure that’s genuinely live today is more ordinary and more immediate. When a customer list or a contract goes into a public AI tool, that data has left your control and landed with a third party you have no agreement with. Under data protection law you’re still accountable for it. That needs no future deadline to matter.

The instinct, once this lands, is to ban the lot. It’s the move that feels responsible and quietly makes things worse, because a blanket ban doesn’t stop people using AI, it just moves them onto personal phones where you can’t see anything at all. The organisations handling this well aren’t the ones with the strictest rules. They’re the ones who chose to see what was happening and make deliberate decisions about it: discover which tools are genuinely in use, decide tool by tool and team by team which are allowed, and keep a record they can show an auditor or an insurer when asked.

That’s the category TrustLayer works in, and we’d rather be straight about which one it is. We don’t protect the models you build. We give you control over the AI tools your people reach for, deciding by user and by group what’s allowed, restricted or blocked, and we do it without routing your traffic through a proxy to get there. Call it an AI firewall if the term is useful in the room. What matters is being honest about the problem underneath it.

Because the term itself will keep being pulled in whichever direction suits whoever is using it next. The useful skill, the one this series exists to sharpen, is looking past the label to the question that actually matters: not “do we need an AI firewall,” but “how are our people using AI, and are we comfortable with the answer.”

If you’re not sure what that answer is, that’s the place to start. A short assessment shows which AI tools are in use across your organisation, who’s using them and where the exposure sits, with no commitment and no disruption to the people doing the work.