Why AI Agents Are Breaking the Old Gateway Model

Part 5 of "The Gateway Sprawl" series

Across the last three posts, a pattern kept repeating itself. The internet access gateway governs network path and answers "can this traffic get through." The API gateway governs request contracts and answers "is this credential valid." The identity broker or CASB governs application usage and answers "is this access happening, and by whom." Each plane is well-built for the problem it was designed to solve. Each one is blind to a version of the same underlying question: should this identity have this access, and does it still need it?

That question has been expensive to ignore for years, in the quiet, slow-burning way that stale service accounts and unreviewed entitlements are always expensive — audits that take longer than they should, incident response that starts with "wait, what does that account even do," access reviews that are really just box-checking exercises because nobody has the context to make a real judgment call.

AI agents don't create that problem. They make it move faster, in more directions, with less human oversight at each step. This post is about why the assumptions baked into all three of the previous planes — assumptions that were reasonable for over a decade — start to break down when the thing making the request isn't a human at a keyboard or a static service account, but an agent.

What actually changes with agents

It's worth being precise here, because "AI agents are different" gets said a lot without much specificity. Three properties matter most for this discussion.

Agents act autonomously, across multiple steps, without a human approving each one. A human user's session, however long it runs, is anchored to a person who initiated it and can generally account for what they did. A service account's behavior, while automated, is typically narrow and predictable — it does the one thing it was built to do, repeatedly. An agent sits in between: it was set in motion by a human or a trigger, but the specific sequence of actions it takes to accomplish a goal is decided dynamically, by the model, at runtime. Nobody explicitly approved "call this API, then that one, then this third one" — they approved the goal, and the agent worked out the path.

Agents chain tool calls, and sometimes spawn sub-agents. A single agentic workflow can touch a dozen different systems in the course of completing one task — querying a database, calling an internal API, drafting a document, sending a notification — each of which may have been governed, if it were a human doing it manually, by a different one of the three planes we've already covered. Some agent frameworks go further and allow an agent to instantiate other agents to handle sub-tasks, which means the identity making a given request three hops downstream may not map cleanly back to anything a human ever directly authorized.

Agents often act "on behalf of" a human without a clean one-to-one session mapping. This is the one that breaks the most assumptions. Nearly every access control model built over the last twenty years — RBAC, ABAC, session-based auth, even most zero trust architectures — assumes you can draw a reasonably clean line from a request back to the human (or narrowly-scoped service account) responsible for it. Agentic workflows blur that line on purpose. The whole value proposition of an agent is that it can act without a human confirming each step. That's also exactly what makes it hard to answer, after the fact, "who authorized this specific action, and were they allowed to?"

Why the previous three planes weren't built for this

Go back through Parts 2 through 4 with this lens, and the mismatch gets concrete fast.

The internet access gateway was built around the assumption that traffic originates from a user or device with a fairly stable identity and behavioral pattern — someone browsing, someone connecting to an app, a session with a beginning and an end. Agent-driven traffic doesn't look like that. It can be bursty, machine-speed, and directed at internal systems in ways that never resemble a user's browsing session, which makes it a poor fit for policies tuned around human behavior baselines.

The API gateway was built to validate that a credential is legitimate for a given call. That still technically works for agent traffic — an agent presenting a token is not conceptually different from a service account presenting one. But the API gateway has no way to evaluate whether the specific chain of calls an agent is making, considered as a sequence, represents reasonable behavior for the task it was given, versus the agent having gone somewhere it shouldn't. Each individual call can be perfectly valid while the overall pattern is not.

The identity broker or CASB was built to track usage of SaaS applications by identifiable users or accounts, over time, with enough continuity to build a usage picture. Agent identities can be far more ephemeral — spun up for a task, used for tool access across several systems, and torn down, sometimes within minutes. A discipline built around tracking usage patterns over weeks and months doesn't have much to work with when the "user" in question existed for four minutes.

None of this means the previous three planes stop mattering. They don't. An agent's HTTP traffic still crosses network paths. Its API calls still hit gateways. Its SaaS interactions are still, in principle, visible to a broker. What's changed is that the behavioral assumptions those planes were tuned around — a human with a session, a service account with a narrow and stable job — no longer describe a growing share of what's actually happening in the environment.

A concrete example

Picture an agent given a fairly ordinary task: reconcile a discrepancy between two internal systems and notify the relevant team. In the course of doing that, it might: query a reporting database, call an internal API to pull related records, check a ticketing system for open issues, call a second internal API to cross-reference a vendor list, and finally post a message to a team channel.

Every one of those calls can be made with a perfectly valid token. Every one can traverse expected network paths. If any of those systems are SaaS applications, a CASB might even have decent visibility into the fact that "an integration" touched them. And yet: nobody explicitly approved the agent querying the vendor list as part of this task. It seemed related, so the agent did it. If that vendor list contains sensitive commercial terms the requesting team was never meant to see, nothing in the three planes covered so far in this series would have stopped it, or even necessarily flagged it as unusual — because nothing about the individual actions was invalid. The problem lives in the combination, and in the fact that the entitlement enabling each hop was granted to an agent identity that nobody is regularly reviewing.

The question this leaves open

Here's where this post has to stop short of resolving anything, and that's deliberate.

An emerging category — agentic access gateways — is starting to take shape specifically to address this: control points designed around agent and tool-call mediation rather than user sessions or static service credentials. That's a real and necessary development, and it matters for the same reason internet access gateways, API gateways, and identity brokers all mattered when they emerged: each new plane of activity eventually gets its own dedicated control point.

But if this series has shown anything so far, it's that a new control point governing whether a request can happen doesn't, by itself, answer the deeper question this whole series keeps circling back to: should this identity — now including agent identities — have had this access in the first place, and does it still need it? An agentic access gateway can mediate the call. It's a separate discipline that has to govern the entitlement behind it.

That's where this series turns next.

Where this goes next

Part 6 will lay all four planes covered so far side by side — internet access, API, identity broker/CASB, and agentic access — and make the comparison explicit: what each one enforces, and what each one is structurally blind to. From there, Part 7 will get specific about what a governance layer that actually closes this gap looks like in practice, including how it fits alongside every plane covered in this series rather than replacing any of them.

[Diagram placeholder: four-plane diagram, "Agentic Access Gateways" row highlighted, possibly with a supplementary sequence diagram showing the agent tool-chaining example above]