Setting the Table: What Do We Mean by "Gateway"?

Part 1 of "The Gateway Sprawl" series

A few years ago, I sat in a room with a security team that had just finished a textbook zero trust rollout. Every laptop was enrolled. Every internet-bound connection ran through their access gateway. Split tunneling was locked down, SSL inspection was on, and the dashboards looked great. By any conventional measure, they had "done zero trust."

Then their audit team asked a simple question: which service accounts and integrations can reach your ERP system, and why?

Nobody in the room could answer it. Not because the gateway had failed — it was doing exactly what it was built to do — but because the question wasn't one it was ever designed to answer. The traffic they couldn't account for wasn't sneaking past their perimeter. It was API calls between systems that never touched the gateway at all, and a handful of automation accounts that had been granted access eighteen months earlier for a project nobody could quite remember the name of.

That gap — between "our traffic is secure" and "we know who and what actually has access, and why" — is what this series is about.

The word "gateway" is doing too much work

If you asked ten people in security to define "gateway," you'd get ten different answers, and most of them would be right — for a narrower slice of the problem than they realize. The term gets applied to network appliances, API middleware, identity federation services, and now, increasingly, to whatever sits between an AI agent and the tools it's allowed to call.

For the purposes of this series, here's the definition we'll use:

A gateway is any control point that mediates access between a requester and a resource — deciding whether, how, and under what conditions that access is allowed.

That definition is intentionally broad, because it has to cover a lot of ground. What's interesting isn't that these tools all fit the definition — it's that they each apply it to a completely different plane of your environment, and very few organizations have mapped out which plane each of their tools actually covers.

Four planes, one blind spot each

Over the next several posts, we'll dig into each of these individually. For now, here's the map:

• Internet / Web Access Gateways — control the path between users and devices and the internet or internal applications. This is the world of SSE (Secure Service Edge) and SASE, and it's where most people's mental model of "the gateway" starts and ends. Zscaler is the name most readers will recognize here, and it'll be our running example in Post 2.
• API Gateways — control the path between systems and services talking to each other over APIs. Think Kong, Apigee, or Azure API Management. This is the plane my audit-room story above fell through.
• Identity Brokers / CASBs — federate identity across SaaS applications and give visibility into what's being used and by whom, without necessarily governing whether that use is appropriate.
• Agentic Access Gateways — the newest category, governing how AI agents reach tools, data, and each other. Most organizations don't have one of these yet. Most organizations also didn't have an API gateway strategy fifteen years ago, and we all know how that gap got closed.

Each of these gateways is genuinely good at what it does. None of them can see what the others see. A internet access gateway has no visibility into API-to-API traffic that never crosses it. An API gateway can validate that a token is well-formed without ever asking whether the identity behind it should still hold that scope. A CASB can tell you an app is in use without telling you whether the access to it was ever reviewed.

Why this is urgent now

This gap has existed for years, quietly, in the form of stale service accounts and orphaned API integrations. What's changing is the pace and the blast radius. AI agents don't just call one API — they chain calls, invoke tools dynamically, and sometimes spin up other agents to finish a task, often on behalf of a human who never explicitly approved each individual step. The access patterns this creates don't look like the human-driven sessions or static service accounts that most of today's gateways were designed around.

That's not a reason to panic. It's a reason to get the map right before the territory gets more complicated — which is exactly what this series is for.

Where this series is going

Over the next several posts, we'll take each of these four planes in turn: what it does well, and — more importantly — what it fundamentally cannot see or control. From there, we'll get into the question that actually matters: not which gateway is "best," but how these layers work together, and what's still missing even when you have all of them deployed.

Next up: the plane most security programs already know best — internet and web access gateways — starting with what Zscaler and SSE architectures actually do well, and where their visibility quietly runs out.