What’s the Difference?

5 min read

The Question That Trips Up Even Experienced Architects

“We already have an API gateway. Isn’t that authorization?”

It’s one of the most common questions we hear from platform teams evaluating AI or API access control strategy — and it’s a fair one. Gateways do authorization. They check tokens. They validate requests. They sit right at the edge of your infrastructure, exactly where security should live.

So why do breaches keep happening at organizations with mature, well-configured API gateways?

The answer isn’t that gateways are broken. It’s that gateway authorization and runtime authorization are solving two different problems — and most organizations only have one of them covered.

What an API Gateway Actually Does

Let’s give gateways their due credit first.

An API gateway sits at the edge of your infrastructure and enforces coarse-grained controls consistently, before traffic ever reaches your backend services: [1]

• Authentication — is this caller who they claim to be?

• Rate limiting — are they making too many requests?

• Request validation — is this a well-formed request?

• Traffic filtering — should this even be routed through?

It reduces attack surface and gives you consistent policy enforcement across every service sitting behind it.

But here’s the catch — and it’s the whole point of this article:

A gateway checks whether you’re allowed to knock on the door. It doesn’t check whether you’re allowed to open the specific drawer you’re reaching for once you’re inside.

The Vulnerability Gateways Consistently Miss

There’s a name for that gap, and it shows up at the top of the OWASP API Security Top 10 year after year: Broken Object Level Authorization, or BOLA. [2][3]

Here’s how it works, in plain terms:

An endpoint like /api/orders/12345 correctly authenticates the caller. The token is valid. The gateway says “yes, come in.”

What it doesn’t check: does this specific caller actually own order 12345?

Change the number to 12346, and if the backend doesn’t independently verify ownership, you’re now looking at someone else’s data. No exploit. No malware. Just a changed number in a URL. [4]

This isn’t a rare edge case. BOLA continues to dominate the API vulnerability landscape, and industry researchers consistently describe it as responsible for more real-world data breaches than any other single API flaw. [5][6]

Two of the most widely reported breaches of the last several years — involving Optus and T-Mobile — both trace back to exactly this pattern: authentication succeeded, but object-level ownership was never independently verified. [9]

Why This Keeps Happening — Even at Mature Organizations

This isn’t a failure of any single engineering team. It’s architectural.

Gateways are built to process traffic generically — the same way, for every service, regardless of what that service’s data actually looks like. That’s their strength. It’s also their blind spot.

Object-level authorization requires knowing the business logic — that order 12345 belongs to customer A, not customer B. A gateway sitting at the network edge, inspecting headers and tokens, typically has no visibility into that relationship. Only the backend service — or a system built specifically to understand transaction context — does. [1]

Recent industry analysis puts it plainly: gateways provide routing, rate limiting, and basic policy enforcement, but they consistently miss low-and-slow abuse and business logic attacks — precisely because that requires continuous context and runtime analysis, not perimeter inspection. [8]

The numbers reflect this reality. 87% of organizations reported an API-related security incident in the past year, according to recent industry research — despite most of those same organizations running gateways. [10]

So What Is Runtime Authorization, Exactly?

If gateway authorization asks “is this a valid, authenticated request?” — runtime authorization asks a different question entirely: “is this specific transaction allowed to happen, right now, given everything relevant to this decision?”

That “everything relevant” is the important part. Runtime authorization evaluates:

• Who is making the request (the authenticated identity)

• What they’re trying to access (the specific object, resource, or data)

• Whether they actually own or are entitled to that specific resource — not just any resource of that type

• What the current policy says — which may depend on data sensitivity, regulatory context, time of day, geography, or business rules that change more often than your deployment cycle

• Whether the pattern of this request looks anomalous compared to how this identity normally behaves

Where gateway authorization is a one-time gate at the perimeter, runtime authorization is a continuous decision made at the transaction level — evaluated fresh, every time, for every request, regardless of where that request originates or which system it’s headed toward.

This is the layer that catches the changed order number. The over-permissioned service account making an unusual bulk request. The AI agent that authenticated correctly but is now reaching for data outside its intended scope.

Why “Security at the Door” Isn’t Enough for AI Agents Either

This gap matters more than ever right now, for a very current reason: AI agents don’t behave like traditional API clients.

A human-driven application tends to call the same handful of endpoints, in predictable patterns. An AI agent, by contrast, can autonomously chain together dozens of calls in response to a single prompt — reaching into systems, pulling data, and taking actions the original developer never explicitly wired up. [4]

If your only authorization check happens at the gateway — a single “yes, this agent is authenticated” — you have no way of knowing whether the specific action the agent is about to take, on the specific piece of data it’s about to touch, is actually appropriate. Best practice guidance now explicitly recommends scoping each tool an agent can call narrowly, and issuing agents their own short-lived, tightly scoped credentials rather than broad shared access. [4]

That’s a runtime authorization problem. A gateway, by design, isn’t built to solve it.

Post-Mortem Security vs. Prevention: The Real Cost Difference

Here’s the pattern that shows up in breach report after breach report: the vulnerability existed for a long time before anyone noticed. Object-level authorization gaps are quiet. They don’t trigger a rate-limit alarm. They don’t look like a DDoS. They look like normal, authenticated traffic — because technically, it is.

That’s what makes detective controls (logging, monitoring, post-incident review) fundamentally different from preventive controls (runtime enforcement that blocks the transaction before it completes).

Detective security tells you what happened, after it already happened. Runtime authorization stops it from happening at all.

For a compliance-sensitive organization, that difference isn’t academic. It’s the difference between a security team writing an incident report and a security team that never had an incident to report.

The Practical Takeaway

Gateways and runtime authorization aren’t competitors. They solve different layers of the same problem, and mature security architectures need both.

• Keep your gateway doing what it does well: authentication, rate limiting, traffic filtering, consistent edge policy.

• Add runtime, transaction-level authorization for the decisions your gateway was never built to make: object-level ownership, business-context rules, continuous policy enforcement, and anomaly detection — across every API, every AI agent, and every legacy system that traffic eventually reaches.

The organizations still getting breached in 2026 usually aren’t the ones without a gateway. They’re the ones who assumed the gateway was the whole answer.

Where Control Core Fits

This is precisely the gap Control Core was built to close.

Control Core enforces policy at the transaction boundary — evaluating identity, object-level ownership, business context, and behavioral patterns in real time, on every request, across your entire stack. Legacy databases. Modern APIs. AI agents. Cloud infrastructure. One policy engine, sitting exactly where the decisions that actually matter get made — without requiring application rewrites or new SDKs bolted onto your existing systems.

If your evaluation checklist currently stops at “do we have a gateway,” it might be worth extending the question: can you prove, transaction by transaction, that the request was actually allowed — not just authenticated?

👉 See how runtime authorization works alongside your existing stack — controlcore.io

Sources:
[1] Apache APISIX, “API Gateway Security: Threats, Best Practices & Implementation,” 2026.
[2] Palo Alto Networks, “What Is Broken Object Level Authorization?” 2026.
[3] Appsecure, “The State of API Security in 2026: Common Misconfigurations and Exploitation Vectors.”
[4] DEV Community, “Building Secure APIs in 2026: Threats Developers Can’t Ignore,” July 2026.
[5] DEV Community, “API Security in 2026: The Attacks That Are Destroying Production Systems,” May 2026.
[6] Nordic APIs, “The 5 Most Common API Vulnerabilities in 2026,” March 2026.
[8] NHI Management Group, “API Gateways Expose the Limits of Transaction-Only API Security,” citing Salt Security, August 2026.
[9] Jimber, “API Gateway Security in Zero Trust 2026: A Guide,” June 2026.
[10] Prophaze, citing Akamai research and the Verizon Data Breach Investigations Report, 2026.