# Pattern: API Gateway as Security Boundary

Status: seed
Readiness target: RL3 production
Primary owners: Railiance platform, product repos
Genesis family: Application/API security

## Problem

Public APIs need consistent edge protections before traffic reaches
product services.

## Context

Use this pattern for public HTTP APIs, tenant-facing APIs, admin APIs,
ingress paths, rate limiting, schema checks, authentication, and edge
logging.

## Forces

- Gateways can centralize common controls.
- Applications still need local authorization and validation.
- Edge policies must not hide tenant or object-level checks.
- Admin APIs require stricter exposure rules than public product APIs.

## Solution

Place a managed gateway at API ingress to enforce authentication
prechecks, TLS, rate limits, request size, schema constraints, logging,
and routing before forwarding to application enforcement points.

## Verification

- Unauthenticated or malformed requests are rejected at the edge.
- Rate limits and abuse controls are active.
- Admin surfaces use separate routes and stronger controls.
- Application-level object authorization still runs behind the gateway.

## Related Patterns

- Object-Level Authorization Check.
- Schema-First API Security.
- Network Default Deny.
- Central Audit Ledger.