Governing AI Agent Access to APIs: Postman Fabric Gateway and Passport

AI agents now call APIs, MCP servers and language models on their own. Each call needs a credential, a policy and an audit record. In September 2026, Postman made two products generally available for this problem: Fabric Gateway, a gateway for AI traffic, and Passport, which gives people and agents API access without handing them the real keys.

This article explains what each product does, how they divide responsibilities, and the trade-offs of putting a vendor control plane in front of agent traffic. Capabilities, plans and deployment options differ by edition and contract, and Postman notes that parts of this product direction are still evolving.

Why agent API access became a governance problem

Traditional API governance assumes a known set of applications with long-lived credentials. Agents break that assumption. One team can deploy many agents, each wired to several tools, and each tool needs a key. Keys get copied into prompts, configuration files and scripts.

Postman’s 5 October 2026 announcement states the premise plainly: any key in circulation is a risk. It describes keys copied between laptops, wikis and scripts, where security teams often cannot track them. The engineering questions that follow are familiar, but at a larger scale:

• Which agents call which models, MCP servers and internal APIs?
• Who approved that access, and can it be revoked quickly?
• Where do credentials live, and who or what can read them?
• Is every call attributed to an identity and logged where the security team can see it?

Postman’s answer has two parts. Fabric Gateway governs the traffic path. Passport governs the credential.

Fabric Gateway: one governed path for AI traffic

The Fabric Gateway product page describes an AI-native gateway for agents, LLMs, MCP servers and the systems they interact with. Traffic is routed, governed and observed through a single endpoint deployed inside your own cloud. Postman’s Learning Center page lists centralized providers, routes, imported services and policy guardrails, with analytics, audit logs, health status and traces.

The Fabric AI Gateway architecture page splits the product into two planes.

Plane	Where it runs	What it does
Control plane	Postman Cloud	Registry of APIs, MCP servers, agents, LLMs and CLIs; versioned policy and configuration; identity and RBAC across org, team and agent; admin portal and admin API; certificate issuance for node enrollment. It is not in the request path.
Data plane	Your cloud (the page lists AWS, GCP and Azure)	Processes every request: routing, protocol adapters for MCP, A2A, HTTP and LLM traffic, a plugin chain for authentication, rate limiting, PII redaction and transforms, a credential broker, failover and OpenTelemetry output.

Several design choices matter for security review. The architecture page states that the data plane always dials out to the control plane over mTLS gRPC, rather than accepting inbound connections. Only credential references sync to the control plane, never secret values. If the control plane is unreachable, the gateway keeps working from a signed on-disk cache. Telemetry goes to your own OpenTelemetry collector, and the product page states that logs remain in your cloud.

The October 2026 “What’s new” post adds that the cloud version, with both planes in Postman Cloud, reached general availability for Team plans. A later launch added an admin API, certificate-based node enrollment and identity-based access control. So there are two deployment shapes to choose between, and they have different data-residency profiles.

Passport: API access without handing out keys

Passport addresses the credential itself. The Passport page in the Postman Learning Center describes teammates receiving secret references that the Passport Proxy resolves inside your cloud, so secrets never leave your infrastructure. Admins connect HashiCorp Vault, AWS Secrets Manager or Google Cloud Secret Manager.

The Passport key concepts page defines the building blocks:

• Namespace: a group of related APIs; access is granted through usage requests.
• Resource: an API endpoint that Passport manages access to.
• Secret reference: a token that points to a secret in your store rather than containing it. It is bound to the consumer it was issued to.
• Passport Proxy: a container-based deployment inside your cloud that checks identity and permissions, fetches the secret and injects it into the request.
• Passport Cloud: the hosted backend for namespaces, access requests, roles and audit history. It does not handle real secrets.
• Roles: a Passport Admin approves requests and maps references; a Passport Member requests access.
• Passport CLI: signs a user in, connects to the proxy and sends authenticated requests.

The Passport security model states that both Passport Cloud and the proxy verify the user’s identity and the machine making the request. The proxy checks authorization before it contacts your secret store. Secrets are resolved and used inside your cloud, then discarded, and do not pass through Passport Cloud. Admins can revoke access at any time, and every API call is logged and attributed to the caller’s identity.

How the two products divide the work

The products overlap: Fabric Gateway also has a credential broker, and both log calls. The difference is the scope of the problem each one centres on.

Question	Fabric Gateway	Passport
Primary concern	Routing, policy and observability for AI traffic	Who may use which API credential
Typical caller	Agents, IDEs, apps and LLM SDKs	Developers, scripts and agents calling approved APIs
Targets	LLM providers, MCP servers, REST APIs and other agents	API endpoints grouped into namespaces
Credential handling	Broker strips caller credentials and injects upstream ones	Proxy resolves identity-bound secret references from your store
Runtime location	Data plane in your cloud, or Postman Cloud for the cloud version	Proxy in your cloud
Hosted component	Control plane on Postman Cloud	Passport Cloud

A reasonable reading is that Fabric Gateway suits teams that need one policy point for model and tool traffic, such as model allowlists, token budgets and PII redaction. Passport suits teams whose immediate risk is key sprawl across people, scripts and agents. Some organizations will need both. Postman’s documentation does not yet describe a combined reference architecture, so test how the two interact before you design around it.

Trade-offs to weigh before adopting

Centralizing agent traffic has real benefits: one audit trail, consistent policy and fewer copies of keys. It also creates dependencies that an architecture review should address.

• Hosted control planes. Both products rely on a Postman-hosted component for configuration, identity and audit history. Confirm what metadata it holds, where, and under which contract terms. Postman’s announcement also introduces Postman Private Cloud, a dedicated single-tenant deployment Postman manages; ask whether it applies to these products for your contract.
• A new runtime component in the request path. The data plane and the proxy sit between callers and targets. Size them, run them redundantly, monitor them, and include them in incident runbooks.
• Behaviour when the control plane is unreachable. Fabric Gateway documents a signed on-disk cache. Confirm the equivalent behaviour for Passport and test both.
• Policy ownership. Someone must own the registry, approvals and revocations. Without that role, a gateway records sprawl instead of reducing it.
• Coverage. Governance only applies to traffic that goes through the gateway or proxy. Agents that hold their own keys elsewhere remain outside it.
• Maturity. Both products became generally available recently, and the architecture page notes that details may change. Pin versions and track release notes.
• Disconnected environments. Postman announced an air-gapped client, stated as coming soon and generally available in early 2027. It is a client for networks without internet access, not a statement about these two products.

A rollout checklist

• Inventory agents, the models, MCP servers and APIs they call, and where their keys live today.
• Decide whether the first problem is traffic policy, credential sprawl or both.
• Choose the deployment shape: data plane in your cloud, or the Postman-hosted cloud version.
• Confirm with Postman which plan or contract covers the features you need, including Private Cloud if relevant.
• Connect a secret store and move one non-critical API behind Passport references first.
• Route one agent’s model and tool traffic through Fabric Gateway, with a model allowlist and logging to your own OpenTelemetry collector.
• Test revocation, control-plane loss and data-plane failover before widening scope.
• Assign owners for approvals, policy changes and audit review.
• Record product versions and re-check the documentation at each upgrade.

How Bassirah can help

Postman is a Bassirah strategic technology partner. We help teams map agent and API traffic, design where gateway and proxy components run, and pilot governed access with clear rollback steps. See our Postman partner page and our enterprise AI AgentOps and LLMOps architecture work. Product editions and support entitlements are confirmed in each engagement.