Fabric AI Gateway architecture
This topic captures the current product direction and implementation, but a lot of the platform is still evolving. Use it to explore the architecture and workflows, while keeping in mind that some details, capabilities, and decisions may change as development continues.
Fabric AI Gateway is a governed API gateway that connects applications, AI agents, CLI tools, and developers to LLM providers, MCP servers, APIs, and internal or external agents through a centrally managed, self-hosted data plane.
How it works
A control plane, hosted on Postman Cloud, handles configuration, identity, and governance. A data plane, deployed in your own cloud, handles all runtime traffic. The two stay in sync over mTLS, so policy changes made centrally take effect wherever your data plane runs.
Traffic enters from AI agents/IDEs (MCP, JSON-RPC, SSE), apps and LLM SDKs (OpenAI, Anthropic), services and clients (HTTP/1.1, REST), and A2A agents, and is routed out to upstreams: LLM providers (OpenAI, Anthropic, Bedrock), MCP servers, internal APIs (imported from OpenAPI specs), and other A2A agents.
Components
Fabric AI Gateway has four main components: your stack (clients), the control plane, the data plane, and providers (downstream targets).
Your stack
The clients are the entry points into the Fabric AI Gateway. They initiate requests that are processed by the data plane according to the policies and configurations defined in the control plane.
All client types send requests into the data plane.
Control plane (Postman Cloud)
Control plane handles administration and never sits in the request path. It exposes an Admin API (REST, with 21 RBAC permissions), versioned per-tenant config and policy, certificate authority and enrollment (X.509, auto-renewing), a read-only fleet view of node health, and usage/billing metering. The control plane talks to the data plane over mTLS gRPC, and the data plane always dials out to the control plane rather than accepting inbound connections.
The control plane consists of the following key components:
- Registry — Central catalog of APIs, MCP servers, agents, LLMs, and CLIs
- Policy & config manager — Versions and syncs policy/config across environments
- Identity & RBAC — Enforces access control hierarchy: org → team → agent
- Admin portal — Provides analytics, audit logs, and UI-based management
Data plane (Customer Cloud)
Data plane handles every request. It includes TLS listeners (ports 8080/8443), a router that matches on host/path/method/header, protocol adapters for MCP, A2A, and LLM traffic, a policy chain (26 built-in plugins across 5 lifecycle phases), a credential broker that strips the caller’s credentials and mints upstream credentials, an upstream manager (load balancing, circuit breakers, failover), and local state (a signed config cache plus your own vault and database).
The data plane runs inside your own cloud and handles all runtime traffic. It’s composed of the following components:
- Protocol adapters — Normalize HTTP, MCP, and A2A traffic.
- Plugin chain — Applies auth, rate limiting, PII redaction, and transforms.
- Credential broker — Manages OAuth flows, AES-256 encryption, and vault/key storage.
- Router — Radix-tree based routing with weighted load balancing and failover.
- OTel — Emits traces, metrics, and logs for observability.
Providers
The Fabric AI Gateway connects to the following types of providers (downstream targets):
Platform capabilities
The data plane guarantees the following out of the box:
- Auto-failover — Circuit breaker and retry logic.
- Rate limits — Per-team token budgets.
- Observability — Cost, latency, and audit log tracking.
- Secret isolation — Agents never have direct access to credentials.
- Guardrails — PII detection, RBAC enforcement, and audit trail.
- Cloud-native — Deployable on AWS, GCP, and Azure.
Request flow
The following steps outline the typical request flow through the system:
- A client (application, AI agent, CLI tool, or developer) sends a request.
- The request enters the data plane, where protocol adapters normalize it.
- The plugin chain applies auth, rate limiting, and PII/transform rules.
- The credential broker injects the appropriate credentials without exposing them to the caller.
- The router selects a healthy provider using weighted load balancing.
- The request is forwarded to the destination provider (LLM, MCP registry, API, or agent).
- OTel captures traces, metrics, and logs throughout for observability.
- Configuration and policy changes made in the control plane sync down to the data plane through mTLS.
Platform guarantees
Fabric AI Gateway is designed to be a secure, reliable, and observable gateway for AI traffic. It provides the following guarantees:
- Outbound only — Postman has zero inbound access to the customer’s data plane.
- Survives a control-plane outage — The gateway keeps working from a signed on-disk cache if the control plane is unreachable.
- Secrets stay local — Only credential references sync to the control plane; secret values never do.
- Fail-closed defaults — 16 of the 26 built-in plugins fail closed by default, covering auth, authz, and redaction.
- OpenTelemetry — telemetry exports to the customer’s own collector, not Postman’s.
Where to go next
- New to Fabric AI Gateway? Start with the Quickstart to connect your first LLM provider or MCP server and send a test request.
- To understand how routes are organized once a few providers are connected, see Manage gateway connections and routes.
- To control or transform traffic (auth, rate limiting, redaction, and so on), see Control and transform gateway traffic with plugins.
- To monitor traffic, see Monitor gateway traffic with analytics and traces.
- To manage users, roles, and credentials, see Administration.