Enterprises: Stop Handing Out API Keys! (How Postman Ended Credential Sprawl with Passport)

October 6, 2026

As Postman rapidly shifted to building agents and hosting agentic workflows, we knew that reducing that increased risk required solving credential sprawl. We envisioned and built Postman Passport to help solve our own problem…but we knew it was needed industry-wide. Along the way, Passport also solved a second, related problem: we had no way to say which specific APIs (or even which endpoints within an API) a given human or agent was allowed to call. Once a key existed, it could usually hit far more than it should. This is our step-by-step journey to safely handle credentials and limit API access at the same time.

Most approaches to API credential security (including vaults, static scanners, rotation policies, and client-level controls) work to limit damage after a key has been issued. Possession is the issue which dynamic secrets and short-lived tokens can’t solve…they merely shrink the window of attack. Once a key lands on an engineer’s machine, it spreads across tools, logs, and environments. Even GitGuardian’s State of Secrets Sprawl 2026 report found that a single live secret ends up in eight locations on the same machine, on average. We saw the same pattern at Postman.

But what if we never distributed the key at all? Developers and agents cannot compromise secrets they do not possess. Instead, we give them access that is scoped to specific endpoints, attributed to a verified identity, and revocable instantly.

We treated this like every textbook security problem (accurate inventory enables effective policy, which drives automated enforcement and continuous detection). The rest of this post demonstrates how we applied it at Postman to reduce our risk.

Accurate Inventory

Starting with inventory, we wanted to ensure complete visibility into the scope of secret sprawl across our entire ecosystem. We all know secrets languish on endpoints (your standard Apple Notes/.env files that have been re-used across 50 projects for easy reference)…despite IT or Cloud Infrastructure departments provisioning vaults, and Security Awareness Teams warning us about proper credential handling techniques. We put it to the test by taking an Osquery script and scanning our engineering user base (.env/.bash_history, etc). By analyzing our environment, we discovered that the risk was concentrated to just a few users; in fact, a single laptop was 14% of our total risk!!! Historically we’d ask those users to rotate and migrate their secrets into a vault before we had an incident or AI created an unintended outcome due to finding a key. That’s a detective control, not a preventative one, and seldom does it actually get done at scale.

Here is a sample script to give you an idea how to surface up your own risk without having those credentials populate into Osquery logs, yes the irony of understanding your secret sprawl risk while not copying them to yet another location isn’t lost on me.

Osquery

Effective Policy

We based our approach on use cases for two types of users: humans and agents.

• To secure human traffic, we observed traffic and then inferred policies (think firewalls in listen-only mode)
• For agent traffic, we simply dictated sanctioned or unsanctioned behavior (think firewalls blocking gambling traffic) upon rollout.

We leveraged mobile device management (in our case, JAMF) to put Passport on our laptops and left it running for two weeks before writing any rules. We then derived policy based on user, organization, department, and role…and which applications each accessed.

Key observation: Most users don’t know what APIs they access, and if you ask, what you get back is just the half they remember. So this step is essential to get full visibility, especially the traffic where secrets are detected. Here’s just some of the anthropic calls one engineer makes:

Second, we defined our sanctioned policies. We reviewed our most critical and high-value data, systems, and assets (Zoom, Anthropic, OpenAI, Salesforce, just to name a few). With agents, you dictate policy in order to enforce least privilege. Since its call list is derivable in code (because somebody typed it), policy can be derived rather easily. As an example, Yoda is our go to market agent, and we scoped it before its first run by reading the tool modules it imports: 16 credentials, 12 providers, 42 endpoints which is a subset of what it could’ve accessed without policy and a raw API key. This is the magic of risk reduction (less credential sprawl and API access management).

By restricting which endpoints and services your teams can reach, Passport also strengthens your broader API access management posture. Access stops being an all-or-nothing grant tied to a vendor’s permission model and becomes something your security team actually defines: this identity can call this endpoint, for this purpose, and nothing else. An engineer debugging a payments integration doesn’t need standing access to every endpoint in that API, just the ones their task touches. An agent built to read support tickets doesn’t need the ability to delete them. Passport lets you draw that line once, at the catalog level, and have it hold everywhere that identity shows up, instead of relying on each vendor’s API to offer fine-grained scopes of its own (most don’t).

Key Observation: a lot of users still heavily interact with AI and have one key per user, so personal namespaces are great for this. Claude has hundreds of endpoints, and most users only need the /messages endpoint, but you’ll want to maintain an API key per developer for cost purposes.

Enforcement

The point where most security deployments struggle: enforcement. Passport has a UI shipped out of the box (which will suffice for smaller organizations), but it’s also API-enabled to wire up your IT Service Management platform (like ServiceNow or Serval). Ours is called Posty and we predominantly do Slack-based support.

UI:

Integrated UX (Posty):

Detection

Continuous detection completes the sequence which is a combination of how you detect secrets (remember Osquery from Inventory?). Now that Passport, in your virtual private cloud, sees every request passing through the Secure Access Proxy, security teams gain a unified, real-time audit trail to define future policy. Every call is logged with the caller’s verified identity as well as status about the call and OTEL information. This allowed us to define alerts around secrets identified/blocks/errors as well as concerning conditions around volume and velocity. This evidence will flow into our compliance reporting for standards such as SOC 2, ISO 27001, HIPAA, and PCI DSS, and then ultimately back into the inventory and policy stages which significantly increases the tool’s overall effectiveness over time.

Transformational Advancements

By deploying Passport internally, we’ve been able to move secrets sprawl from a detective control to a preventative while reducing the blast radius of humans and agents by controlling API access per credential. We are excited to share it with the broader developer community so learn more and set up Passport today!