Gateway
Purpose
The Gateway is the reverse-proxy entry point of the platform. It sits in front of internal application hosts and provides a single ingress layer for all routed traffic.
Functionally, it simplifies how clients reach the platform and centralizes edge concerns including routing, security enforcement, and traffic shaping.
What The Gateway Does
The Gateway is responsible for:
- accepting inbound HTTP traffic
- routing requests to the correct backend host
- enforcing edge-level authentication requirements before proxying
- performing structural token validation on bearer tokens
- hardening request and response headers
- applying edge rate limiting per traffic category
- exposing health and metrics endpoints at the gateway layer
- applying configured browser and transport security behavior
- supporting a single front-door deployment model
Role In The Platform
The Gateway is important because the platform has multiple backend hosts:
- the Portal for administration
- the Runtime for AI tool access
The Gateway gives deployments a clean way to expose the externally consumed surfaces without forcing clients to know internal host topology. It also acts as the first security layer that traffic passes through, catching invalid or abusive requests before they reach backend services.
Functional Characteristics
Detailed documents for each Gateway area:
Reverse Proxy
The Gateway uses a configuration-driven reverse proxy model. From a functional standpoint, this means:
- routes can be defined without changing business logic
- portal and runtime traffic can be fronted consistently
- specific routes are matched before broader catch-all routes using a priority ordering model
- cross-origin and browser-facing behavior can be managed centrally
Route-Level Policies
The Gateway applies per-route edge policies that control how each proxied path is treated. Route policies define:
- whether a route is open to anonymous callers
- whether a bearer token or API key is required to reach the backend
- whether incoming tokens are structurally validated before proxying
- which rate limiting category applies to the route
This means access requirements and traffic controls are declared in configuration per route, rather than embedded in backend services.
JWT Precheck
Before proxying protected routes, the Gateway performs lightweight structural validation on bearer tokens. This check is intentionally fast and does not replace the full token validation done by backend services. It catches structurally broken or clearly expired tokens at the edge.
Header Hardening
The Gateway strips certain request headers that should not be forwarded to backend services, and removes identifying information from responses. This reduces the risk of header-based spoofing and information leakage at the ingress layer.
Edge Rate Limiting
The Gateway enforces generous fixed-window rate limits per traffic category. Rate limits are applied per authenticated identity where possible, falling back to the client address for anonymous traffic. This provides a coarse abuse guard at the ingress layer before requests reach backend rate limiting.
Security Boundary Support
The Gateway contributes to platform hardening by participating in:
- transport security behavior
- browser security headers and policies
- request correlation and request logging
- diagnostics endpoint protection
Operational Endpoints
The Gateway exposes:
- health endpoints
- metrics endpoints
This allows operations teams to monitor the ingress layer independently from the backend hosts.
Protocols Supported
The Gateway is an HTTP reverse-proxy component. Its functional concern is request routing and edge enforcement rather than business processing.
It does not:
- onboard APIs
- publish tools
- execute mappings
- evaluate governance policies
Instead, it forwards traffic to the components that perform those functions.
Why It Matters
The Gateway helps the platform behave like a coherent product rather than a set of separate hosts. It provides:
- a cleaner deployment entry point
- simpler client connectivity
- centralized ingress observability
- early rejection of invalid or abusive requests
- better separation between edge routing and business behavior