Postman Passport: Secure API access for the Agentic Era | Postman Blog

Skip to content

Postman Passport: Secure API access for the Agentic Era

Abhinav Asthana

June 23, 2026

Agents are going to be consuming APIs at 1,000x the rate humans do today. Not only that, developers are also using agents to call APIs as part of the agentic software development lifecycle (SDLC). Agents are embedded in more and more of the development lifecycle across CI machines, workloads, and other applications.

As we built the AI engineer, we realized that the state of API access and consumption does not meet the needs of security for today’s world.

Access happens through several different auth mechanisms like bearer tokens or OAuth-based mechanisms and in most cases, API keys are needed to make the auth mechanism work. API access might be needed for debugging, testing, running workflows, configuring MCP servers, incident responses and many other use cases. These API keys live in dot files like .env and bash profiles on local dev machines and easily get copy/pasted into Slack, Google Docs and other tools. The moment a consumer touches a key, the risk of leakage explodes.

On average, each live secret appeared in roughly eight different locations on the same machine. This means the same credential is replicated across dotfiles, shell profiles, build outputs, IDE configs, and tool caches. Each copy is an independent vector for theft. Developers are also working with coding agents and building agents with APIs. Agents gaining direct access to API keys and their ability to communicate externally means huge risk.

The current state of API design doesn’t take into account granular permissions especially early-on. Providers design overly permissive APIs as use cases are not often well known and it is easier to gain API adoption by making it easy to create auth schemes and endpoints with broad access. Moreover, key vaults are meant primarily for production systems (if configured at all). The moment someone has a secret, the best defense is reactive, not proactive.

Approaches that work today are fragmented and teams face a landscape of dealing with thousands of APIs with their own mechanisms, which results in secret sprawl in every organization for over-provisioned APIs.

Postman is solving this problem today through Passport

At Postman, we have believed that a better developer experience is almost always the right solution. If we can fix a problem upstream in the developer workflow without losing efficiency, maintaining hygiene and posture downstream for Security and IT teams is much easier.

We’re introducing Postman Passport, a secure way to call APIs for the agent-native landscape for humans, machines, and agents.

How does this work

Consumers gain access to APIs through credential references instead of real API keys.

A credential reference is a cryptographic token bound to the holder. It is useless if used by anyone else.

A passport holder can be a durable identity or an ephemeral identity.

A passport holder can request access to an API through the Postman API Network.

The Postman API Network is integrated with a customer’s vault and real keys never leave the vault.

API calls go through the Secure Access Proxy, a deployable proxy within your network. All the client has to do is route API requests through the proxy.

The Secure Access Proxy resolves the credential with the real API key, all within your virtual private cloud (VPC).

Durable identities live longer and can be used to track API consumption for longer periods of time.

Ephemeral identities are for agents spawning other agents who need a much more granular scope versus the broader scope of the original holder.

How does the credential reference and proxy work together

There are two core problems with the way secrets are made available to consumers of APIs today.

Secret sharing

For every API access point across development and production environments, secrets need to be shared with each consumer at the user or application level. As the number of consumers grows, secret distribution becomes increasingly difficult to manage and secure. Touch points from where secrets can leak increase multifold over time.

Secret resolution boundary

Secrets are often resolved in uncontrolled environments such as developer machines or loosely written applications. This creates multiple opportunities for secrets to leak through logs, traces, memory dumps, or even through users who gain SSH access to production machines.With Passport, we are flipping the model for both of these problems.

First, we invert the secret sharing model into an access control model. Instead of distributing secrets to API consumers, you grant controlled and granular access to consume APIs. Consumers never receive the underlying secrets. This eliminates direct secret access across all consumer layers. If you don’t have the secret, you cannot leak it.

Second, we move where secrets get resolved. With...