Skip to main content

Deploy the gateway PEP

Design-stage

The gateway PEP is designed (docs/phases/phase-5-gateway-boundary-stepup-coldstart.md, FR-12) but not yet implemented — there is no agentic-auth-gateway binary in this codebase today. The steps below describe the intended deployment shape so you can plan for it; for a PEP you can deploy right now, see Deploy the sidecar PEP.

Goal (designed): run one shared proxy in front of a whole fleet of agents you control, instead of one sidecar per agent process.

Why you'd choose this over the sidecar​

A gateway is the same decide → exchange → forward logic as the sidecar, centralized behind one shared proxy — simpler to operate at fleet scale, with a shared decision cache, in exchange for a single choke point. See Enforcement point tradeoffs for the full comparison.

Intended deployment shape​

  1. Run one agentic-auth-gateway instance (or a small horizontally-scaled pool behind a load balancer) with a config mapping each agent fleet's egress to its real upstreams — the same shape as the sidecar's upstream_map, scoped per fleet instead of per process.
  2. Point every agent's egress in that fleet at the gateway instead of at individual sidecars.
  3. The gateway calls the same PDP and Token Exchange Service endpoints the sidecar calls — no separate decision logic to keep in sync.

The one non-negotiable requirement​

The gateway MUST fail closed on its own unavailability. Because it is a single choke point for many agents (unlike a per-process sidecar), a silent pass-through here would be a much larger blast radius than a single sidecar failing open — Phase 5's design explicitly calls this out as a hard requirement, not a configuration option.