Postman Passport: Secure API access for the Agentic Era

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 Passport, secret resolution moves from the application layer to the proxy layer. All secret resolution happens within the Passport proxy running inside your VPC. Applications, agents, and other consumers never receive the resolved secret, even when they are running inside the same VPC. By moving resolution into a controlled infrastructure layer, Passport removes the risk of accidental exposure and secret leakage.

Three properties hold in this model. The caller’s identity is cryptographically proven, so it can’t be forged. Each identity can only ever use the specific credentials it’s been scoped to, and nothing more. And the private key that proves identity never leaves the holder’s machine, so a stolen credential reference is worthless to anyone who doesn’t also hold the matching key.

The scope check runs on every request before the proxy ever touches your vault, and when a secret does get resolved, it’s injected right there inside the proxy. It never reaches Postman, your logs, or any audit record.

The trust root is your own certificate authority, not ours. Postman authorizes issuance, but the certificates that actually prove identity are signed by your key alone.

We are also extending this model to the rapidly evolving needs of agents. Agents stay scoped as well. An agent that spawns other agents passes down a strict subset of its own access, scoped and short-lived. Agents will have durable or ephemeral identities on the Postman platform and can be granted access, or they can request access through APIs or CLIs.

Finally, endpoint-level scoping is also possible with the Secure Access Proxy, where it acts as an enforcement point to control access at an endpoint level beyond the permissions granted for the original API.

What is the impact

1. Your secrets stay as secrets
2. API keys are not lying around waiting to be exploited
3. Proactive approach instead of reactive prevention
4. Control and manage API access and consumption

Bringing agents in as first-class users of APIs through Postman is what Passport is designed for. We’ll share more on identity management and endpoint scoping in an upcoming post. Register here for getting access and we’ll reach out to you!