The Middle Layer Everyone Forgets: What Identity Brokers and CASBs Actually Do

Part 4 of "The Gateway Sprawl" series

Part 3 ended with a promise to look at the layer that seems, on paper, like it should close the gap we've been circling for two posts now: identity brokers and CASBs. They deal directly with identity. They sit across many SaaS applications at once. Surely this is where "who has access to what, and why" finally gets answered.

It's closer than the previous two planes — but not for the reason most people assume, and the gap that's left over is worth being precise about. What this plane actually does

Identity brokers and CASBs (Cloud Access Security Brokers) occupy an interesting middle ground: unlike the internet access gateway (network path) or the API gateway (service contracts), this plane is explicitly about identity and applications, not just traffic.

• Identity federation — brokering authentication across multiple SaaS applications, often via SAML/OAuth, so users authenticate once and access many downstream apps
• Usage visibility — discovering which SaaS applications are actually in use across an organization, including "shadow IT" that was never formally sanctioned
• Policy enforcement at the app boundary — applying controls like session limits, data loss prevention, or conditional access rules as users interact with cloud applications
• Risk scoring for cloud app usage — flagging risky or non-compliant application usage patterns

This is genuinely useful, and it's the closest any of the three planes covered so far comes to touching the actual question this series keeps returning to. A CASB can tell you, with real confidence, that a particular SaaS app is in use, who's using it, and roughly what they're doing with it. That's a meaningfully different and more complete picture than either the internet access gateway or the API gateway can offer on their own.

Where it still falls short: visibility isn't governance

Here's the distinction worth sitting with for this post, because it's easy to miss: knowing that access exists is not the same as knowing whether it should.

A CASB can confidently report that a marketing contractor has been actively using a customer data platform for the past six months. What it generally can't tell you — because it isn't designed to — is:

• Whether that access was ever formally requested and approved through a governance process
• Whether the scope of that access matches what the contractor's role actually requires
• Whether anyone has reviewed that access since it was granted, or whether it's simply persisted because nobody revoked it
• Whether that access should be certified, recertified, or automatically revoked based on a change in employment status or project scope

This is the visibility-versus-governance line. A CASB is very good at answering "what is happening." It is not built to answer "is what's happening actually authorized to be happening, on an ongoing basis." Those two questions get conflated constantly — partly because CASB dashboards are detailed enough to feel like governance, and partly because vendors in this space are incentivized to blur that line in their own positioning.

A pattern completes itself

At this point, three posts in, a shape has emerged that's worth naming directly:

• The internet access gateway governs network path and can answer "can this traffic get through."
• The API gateway governs request contracts and can answer "is this credential valid."
• The identity broker/CASB governs application usage and can answer "is this access happening, and by whom."

None of these three planes — independently or stacked together — can answer the question that actually determines audit outcomes, breach blast radius, and compliance posture: should this identity have this access, does it still need it, and who attested to that being true? That's not a network question, a contract question, or a usage-visibility question. It's an entitlement lifecycle question, and it sits in a different discipline entirely: identity governance.

We're not going to resolve that yet — this series has one more plane to cover first, and it's the one that makes this whole problem considerably harder.

Where this goes next

In Part 5, we'll look at why AI agents are breaking the assumptions baked into all three of these planes at once. Agents don't behave like human users, and they don't behave like static service accounts either — they chain actions, invoke tools dynamically, and often act on a human's behalf without a clean one-to-one mapping between a session and a person. That's the access pattern none of today's gateways, including this one, were built around.

[Diagram placeholder: reuse/extend the four-plane diagram, with the "Identity Brokers / CASBs" row highlighted]