Securing the Contracts Between Systems: What API Gateways Actually Do

Part 3 of "The Gateway Sprawl" series

Part 2 ended on a specific gap: internet access gateways see traffic that flows through them, and a large share of modern access — particularly service-to-service API calls — simply doesn't. That's exactly where this post picks up. API gateways are the plane built specifically to govern that traffic. They do it well. And they have their own version of the same blind spot.

What an API gateway actually does

An API gateway sits in front of a set of backend services and acts as the single entry point for requests to those services. Instead of every consumer talking directly to every service, they talk to the gateway, which then routes, enforces policy, and forwards the request. Kong, Apigee, and Azure API Management are common examples of the category, and while implementations vary, the core functions are consistent:

• Routing and traffic management — directing requests to the correct backend service, load balancing, and versioning APIs without breaking consumers
• Authentication and token validation — checking that a request carries a valid credential (an API key, OAuth token, JWT, etc.) before it's allowed through
• Rate limiting and throttling — protecting backend services from being overwhelmed, whether by legitimate spikes or abuse
• Schema and contract enforcement — validating that requests conform to the API's defined structure, rejecting malformed calls before they reach a backend
• Centralized observability — a single place to log, monitor, and analyze API traffic across many services

This is, in effect, doing for service-to-service and application-to-application traffic what the internet access gateway does for user-to-internet traffic: providing a consistent, centrally managed control point instead of leaving every backend service to handle security on its own. That consolidation is genuinely valuable — it's the reason API sprawl in the 2000s and 2010s didn't turn into total chaos.

The gap: valid isn't the same as appropriate

Here's where it gets interesting, and where the pattern from Part 2 repeats with a twist.

An API gateway's authentication step is very good at answering one specific question: is this credential valid, unexpired, and properly formatted? What it is generally not built to answer is a different, more important question: should the identity behind this credential still hold this scope of access?

Those sound similar. They're not. A token can be perfectly valid — correctly signed, unexpired, presented properly — while still representing access that should have been revoked months ago. A few patterns where this shows up constantly in practice:

• Service accounts provisioned for a project that ended. The integration was built, the project shipped, and the credential was never deprovisioned because nothing forced anyone to revisit it.
• Overprovisioned scopes. A token requested broad access "to be safe" during initial development, and nobody ever tightened it once the integration stabilized.
• Joiner/mover/leaver drift, applied to non-human identities. When a human changes roles, most orgs at least have a process — however imperfect — for reviewing their access. Service accounts and API integrations rarely get the same scrutiny, even though they can hold equally sensitive scopes.

The API gateway will happily validate that token every single time, correctly, because that's exactly what it's designed to do. It has no visibility into whether the entitlement behind the token was ever reviewed, whether it's still needed, or whether it was ever justified in the first place. That's not a criticism of the gateway — it's simply outside the boundary of what an API gateway is.

Two gateways deep, and the gap is still invisible

Stack this against Part 2, and a pattern starts to emerge. An organization can have a mature internet access gateway and a well-run API gateway — two real, meaningfully deployed layers of control — and still have no answer to "what has access to our ERP system, and why," because neither layer was ever designed to answer that question. One governs network-level traffic to the internet and internal apps. The other governs the shape and validity of API requests between systems. Neither governs the lifecycle of the entitlement itself.

This is the same distinction from the end of Part 2, showing up again in a different plane: can this request get through versus should this access exist at all. It's not a coincidence that it keeps showing up — it's the throughline of this entire series.

Where this goes next

In Part 4, we'll look at identity brokers and CASBs — the layer that often gets described as solving exactly this problem, because it deals directly with identity. We'll dig into why visibility into identity and usage is not the same thing as governance over it, and where that distinction quietly costs organizations more than they expect.