Gateway Security Boundary Support
Purpose
This functional area contributes edge-level security behavior to the platform. The Gateway acts as the first line of defense before requests reach backend services, applying authentication checks, token validation, header hardening, and traffic throttling at the ingress boundary.
Main Capabilities
- transport security behavior
- browser security support
- request correlation
- request logging
- diagnostics endpoint protection
- per-route authentication enforcement
- JWT structural precheck
- request and response header hardening
- edge rate limiting per traffic category
Route-Level Authentication
Each named route can be configured with an authentication requirement. The Gateway enforces these requirements before proxying. The supported modes are:
- Anonymous — the route is open to all callers without credentials (used for health and version endpoints)
- Bearer token required — the request must carry a valid
Authorization: Bearer ...header (used for admin routes) - Bearer token or API key required — the request must carry either a bearer token or an
X-Api-Keyheader (used for runtime tool discovery and invocation)
Requests that do not satisfy the configured requirement are rejected at the Gateway with a 401 Unauthorized response, before the request reaches the backend.
JWT Structural Precheck
For routes that carry bearer tokens, the Gateway optionally performs a lightweight structural check before proxying. This check is not a cryptographic signature verification — that is handled by backend services. The precheck focuses on:
- confirming the token has the correct three-part JWT structure
- confirming the payload can be decoded
- checking that the token has not expired (
expclaim) - checking that the token is not being used before its valid-from time (
nbfclaim) - optionally requiring the presence of specific claims such as issuer, audience, subject, and client identifier
Tokens that fail this structural check are rejected at the Gateway with a 401 Unauthorized response. This prevents structurally broken or clearly stale tokens from reaching backend services unnecessarily.
The precheck is configurable. It can be disabled globally or tuned per claim requirement.
Request Header Hardening
The Gateway strips certain categories of request headers before forwarding to backend services. This prevents clients from injecting headers that could influence backend behavior in unintended ways:
- Forwarding headers — headers such as
X-Forwarded-For,X-Forwarded-Host,X-Forwarded-Proto, and related variants are removed from inbound requests. The platform controls what forwarding information is set, not external callers. - Hop-by-hop headers — connection management headers such as
Connection,Keep-Alive,Transfer-Encoding, andUpgradeare stripped before forwarding. - Proxy authentication headers —
Proxy-AuthenticateandProxy-Authorizationare removed.
Additionally, the Server header is removed from responses, preventing the platform from advertising its internal technology stack to callers.
Header stripping behavior is configurable per category.
Edge Rate Limiting
The Gateway applies fixed-window rate limits per traffic category. Each named route is assigned to one of the following rate limit policies:
| Policy | Applies To |
|---|---|
| Portal edge | Portal API and admin routes |
| Runtime discovery edge | Tool discovery and MCP endpoints |
| Runtime invocation edge | Tool invocation endpoint |
| Anonymous health | Health and version endpoints |
Rate limits are partitioned per caller identity where possible. When a bearer token is present, the partition key is derived from the token's subject or client identifier. For routes reached with an API key or unauthenticated, the caller's network address is used as the partition key.
Defaults are intentionally generous to avoid disrupting legitimate traffic, while still providing a coarse guard against abusive request patterns.
Requests that exceed the configured limit receive a 429 Too Many Requests response from the Gateway.
Functional Value
This area helps the ingress layer participate in platform hardening rather than acting as a passive router. By catching invalid tokens, suspicious headers, and abusive traffic at the edge, the Gateway reduces unnecessary load on backend services and provides a consistent enforcement point across all routes.
