Skip to content
On-demand recording | SAP IdM End of Life: Migration Without Disruption | With Deloitte · 60 min Watch recording

Comparison

API Gateway vs ARIA Shield vs MCP Gateway

Three layers, three jobs. API gateways route traffic. ARIA Shield proxies AI model calls and enforces budgets. MCP Gateway authorizes what agents do at the tool-execution layer. Most production deployments run all three.

Platform architects Security engineers Teams deploying MCP-based agents

When an agent calls a tool, your API gateway sees an HTTP request. It routes and rate-limits. But it can't answer: Does this user's session have budget left? Is this agent authorized to call this tool with these parameters? Does this action match an approved plan?

ARIA addresses this with two purpose-built gateways — both backed by the same AuthZEN PDP for authorization decisions: ARIA Shield (the BFF that proxies all AI model traffic, enforces budgets and content security, and keeps tokens off the client) and MCP Gateway (the PEP that authorizes agent tool execution with schema pinning, plan discipline, and signed receipts). Both sit behind your API gateway.

What each layer does

Three complementary layers, not competing products

API Gateway

Network & traffic layer

Infrastructure concerns for all HTTP traffic — human, API, or agent.

Route requests to backend services
Rate limits and throttling
TLS termination and certificates
Load balancing and caching

ARIA Shield

BFF for AI models & browser sessions

The single authorized surface for all AI model traffic. When the PDP authorizes a call, Shield unvaults per-service tokens from the OAuth Vault, makes the downstream call, and returns data — tokens never reach the client. AuthZEN PDP + OAuth Vault

LLM proxy — all AI model calls route through a single auth + billing surface
OAuth Vault integration — unvaults tokens server-side, brokers per-service credentials
Zero-token SPA — HTTP-only cookies, no tokens in the browser
Budget & streaming caps with HTTP 402 enforcement
Content security — PDP obligations enforce classification and egress controls
Signed receipts settled to actual cost

MCP Gateway

Tool-execution authorization layer

Understands what an agent is trying to do — the tool, the parameters, the plan — and authorizes before execution. AuthZEN PDP

Schema pin validation (hash/version tamper detection)
Plan discipline — deny off-plan actions pre-execution
AuthZEN constraints per tool and parameter
Signed, hash-chained receipts as proof of every action

API Gateway is your existing infrastructure (Kong, NGINX, AWS ALB, etc.). ARIA Shield and MCP Gateway are EmpowerNow components — both delegate to the same OpenID AuthZEN 1.0 PDP for authorization decisions, so one policy governs UI, API, and agent surfaces.

Side-by-side comparison

Capability API Gateway ARIA Shield (BFF) MCP Gateway
Routing & rate limiting Core function Delegates to API GW Delegates to API GW
TLS termination Core function Delegates to API GW Delegates to API GW
LLM proxy No — model-unaware Yes — single auth + billing surface for all AI model traffic No — tool-call layer
Zero-token SPA No Yes — HTTP-only cookies, no browser tokens Not applicable (agent workloads)
Per-route PDP decisions No Yes — AuthZEN decision per route Yes — AuthZEN decision per tool call
Budget & streaming caps No Yes — HTTP 402, spend/stream limits Yes — budget stops pre-execution
Content security No Yes — PDP obligations enforce classification and egress controls Yes — parameter allowlists, anti-injection checks
AuthZEN PDP No Yes — same PDP as MCP Gateway Yes — same PDP as ARIA Shield
Schema pin validation No No Yes — hash/version tamper detection
Plan discipline No No Yes — deny off-plan actions pre-execution
Token brokering No Yes — per-service tokens minted server-side Uses ARIA Passport
Signed receipts Access logs only Yes — settled to actuals Yes — hash-chained proof of every action

Key concepts

What makes MCP Gateway different from network-layer enforcement

Schema pinning

Every tool the agent can call has a registered schema with a SHA-256 hash. Before execution, MCP Gateway verifies the schema hasn't been modified — preventing tool-tampering attacks where an adversary alters a tool's definition after approval.

Plan discipline

Agents propose a plan of actions. MCP Gateway enforces that each execution matches the approved plan — no off-plan tool calls, no parameter drift. If an agent tries to execute a step that wasn't approved, execution is denied before it starts.

AuthZEN constraints

Authorization evaluated per the OpenID AuthZEN 1.0 standard — fine-grained decisions about which agent, calling which tool, with which parameters, under which delegation context. Not just "is this user allowed" but "is this action authorized right now."

Signed receipts

Every action that passes through MCP Gateway produces a signed, hash-chained receipt — cryptographic evidence of what was authorized, what parameters were used, and what the result was. Not a log entry. Proof.

How all three layers work together

Two paths through the stack — both governed

Browser / AI model path

1
API Gateway
TLS terminated, rate limits checked, routed to BFF.
2
ARIA Shield (BFF)
Validates session, requests AuthZEN PDP decision for the route, checks budget and content security obligations, proxies to AI model or backend service.
3
Execute & receipt
Authorized call proceeds. Shield writes a signed receipt settled to actual cost.

Agent / tool-call path

1
API Gateway
TLS terminated, rate limits checked, routed to MCP Gateway.
2
MCP Gateway
Validates ARIA Passport, verifies schema pin, checks plan discipline, evaluates AuthZEN constraints.
3
Execute & receipt
Authorized tool executes. MCP Gateway writes a signed, hash-chained receipt with per-parameter provenance.

Frequently asked questions

Can I use both?

Yes — that's the recommended deployment. Your API gateway handles routing, rate limiting, and TLS. MCP Gateway sits behind it and handles authorization, plan enforcement, and receipts. They operate at different layers of the stack.

Does MCP Gateway replace my API gateway?

No. MCP Gateway doesn't handle routing, rate limiting, TLS, or load balancing. It adds a governance layer that understands agent tool semantics — something API gateways aren't designed to do.

What's the difference between ARIA Shield and MCP Gateway?

ARIA Shield is the BFF for AI model traffic and browser sessions — it proxies all LLM calls through a single authorized surface, enforces budgets and streaming caps, applies content security obligations (classification, egress controls), and keeps tokens off the client. MCP Gateway governs agent tool execution — schema pinning, plan discipline, and parameter-level authorization. Both delegate to the same OpenID AuthZEN 1.0 PDP for authorization decisions, meaning one policy governs UI, API, and agent surfaces. Both emit signed receipts.

Do I need MCP support to benefit?

MCP-native agents get the fullest benefit, but schema pinning and AuthZEN authorization decisions add value for any tool-calling agent — regardless of protocol.

What happens if the agent tries an off-plan action?

MCP Gateway denies execution before any side effects occur. The denial is logged with a receipt explaining what was attempted and why it was rejected — useful for debugging and audit.

How is this different from a WAF?

A web application firewall inspects HTTP payloads for known attack patterns. MCP Gateway understands agent intent — it evaluates whether a specific tool call with specific parameters is authorized under current policy. Semantic authorization, not pattern matching.

Go deeper

ARIA Shield →

BFF gateway: zero-token SPAs, budget enforcement, streaming caps.

MCP Gateway →

Tool-execution PEP: schema pins, plan discipline, constraint enforcement.

Runtime Execution Control →

The full ARIA governance pipeline — SSC, WAITING protocol, proof chain.

Zero-Token SPAs →

The BFF pattern that keeps tokens out of the browser.

See MCP Gateway in action

Watch an agent execute a governed tool call — from plan approval to signed receipt.

Request Demo Explore MCP Gateway