How Postman governs AI agent access to 42 production systems

Postman rolled out its Passport credential-brokering system in 5 days to secure AI agent access to 42 production systems — 33 SaaS vendors and 9 internal — removing 278 API keys from circulation and leaving 0 credentials on developer machines. An internal security audit found 278 API keys spread across developer laptops, CI configurations and deployment manifests, with some vendor keys over-scoped enough to delete records or change org-wide settings, while 70 agents on Postman's agentOS run across go-to-market, product and engineering teams using Claude Code, Codex, Cursor and Postman. Passport replaces .env values with vault references resolved at call time by a proxy inside Postman's corporate network, and security scoped the 42 systems down to 104 approved endpoints.

How Postman governs AI agent access to 42 production systems At a glance - Company: Postman - Use case: Secure production access for AI agent development - Landscape: 70 agents operating across go-to-market, product and engineering functions - Product: Passport - Systems: 33 SaaS, 9 internal - Coding tools: Claude Code, Codex, Postman - Rollout: 5 days Background Postman’s agentOS running on Astropods https://astropods.com hosts 70 agents that power their go-to-market, product and engineering teams. The developers who build and maintain them, use their coding agents across Claude Code, Codex, Cursor, Postman and need access to 42 systems 33 SaaS vendors and 9 internal first party systems . | 42 systems secured | 278 API keys removed from circulation | 0 credentials on developer machines | 5 days to roll out | Credentials Sprawl. Every system access followed the same steps: request access from Infosec, get a key, copy it into a local .env file, wire it into the agent. An internal audit from security found 278 API keys across developer laptops, CI configurations, deployment manifests. Over-scoped Credentials. The audit revealed that many vendor keys didn’t offer fine-grained permissions. An agent in one case that needed read access to a specific resource held a key that could delete records, modify pipeline data and change org-wide settings. Coding agents running on the same machine. Every developer runs Claude Code, Cursor or Codex on the filesystem that held those keys. Each new agent added another key and another .env file, so exposure grew with the agent fleet. Shared service key maintenance. For some APIs, it was feasible to provision only service keys and not keys per developer. This present attribution challenges to both developers and agents. In addition, when security had to rotate the shared credential, it broke every other developer and every agent using it, and required significant change management overhead. What Postman needed 1. Credentials stay inside the zero-trust boundary owned by security. 2. Scope is set per resource, not per vendor. It is decided upfront, and inherited by every developer who contributes to the agent s . 3. Each API access attributes it to the developers, the agent and the execution. 4. Developers’ access to APIs is scoped only to the time they’re actively building or iterating on the agent. 5. It works where the developers’ work – the terminal, IDE, coding agents and CI. Security defines the boundaries upfront, and the system enforces them on every call. The solution: Passport Postman’s product team built Passport https://app.usepassport.ai/ after seeing this pattern repeat across multiple customers handling API keys. Developers don’t hold any real keys . Every value in a .env file is a reference bound to the developer who requested it. Passport resolves it at call time. A lightweight Passport daemon on the developers’ laptop forwards calls to the Passport proxy. The daemon is remotely deployed and managed through Jamf by our security team. ANTHROPIC API KEY={{vault:e96b2432-7ca0-47a0-9d83-b6805c04396d}} SF CLIENT SECRET={{vault:2912c85a-01f3-415e-afd7-a884d1d24472}} CONFLUENCE API TOKEN={{vault:ad0faeed-b6be-42ea-ac14-a990bd4f2654}} GITHUB TOKEN={{vault:d2a76849-c215-4411-be0f-2d2c3fff36ef}} Real credentials stay in the vaults. The Passport proxy runs inside our corporate network. It verifies identity and scope, reads the real secret from the vault in memory, and makes a normal API call to the vendor. It is the only part of the system that accesses the real credential. Security operates the resource catalog. Security scoped the 42 vendor+internal systems down to 104 approved endpoints across those systems. The proxy honors the scoped down entries in the catalog, so a vendor key that potentially allows resource deletion, serves only the read endpoint the agent needs. Every developer who requests access from the Passport system gets the same pre-approved scope. Every API call is attributed and each access grant has an end date. Passport logs each request against the developer, the agent and the run, including calls on shared service keys. Developers request access with a reason and a duration of access. Security approves requests from their administration queue, and are also able to revoke each developer’s access to an entire fleet of agents in one click. Rollout in 5 days - Days 1 and 2. Security and the agents development team worked together to build the catalog: 42 vendor + internal systems, 104 approved endpoints. - Days 3 and 4. Every value in every .env file became a Passport reference. - Day 5. The old keys were rotated across each vendor by security, retiring 278 copies. After the .env credentials were replaced with Passport references, developers continued using their existing coding tools. Security deploys the Passport daemon across the organization through Jamf, and administers access through Passport. Results For security - 0 production credentials on developer machines - 278 keys removed from circulation - Every API call is attributed to a developer, an agent and a run - One-click revocation of access for any developers For engineering - A new production system is added to the catalog in 3 days, down from 15. - New developers are able to contribute to any agent fleet in 2 hours - Happier developers who are able to build new and improve existing agents. Since rollout, the agent fleet has grown from 32 to 70 agents, integrating into 42 systems, growing from 27 at the beginning. Credentials exposure remains at zero. I'm far more comfortable saying yes to agentic actors in our systems, because we stay in control of what every agent can reach. Our engineers move fast and build what matters, and we stay safe while they do it. Sam Chehab , Head of Information Security, Postman Get started Explore Passport https://app.usepassport.ai/ or talk to our team https://postman.zoom.us/zbook/d/su1v4dij/chat-with-postman-forward-deployed-engineering . For a deep dive behind this work, read The agentOS: Rethinking Access for Agents https://www.linkedin.com/pulse/agentic-os-rethinking-access-agents-ankit-sobti-nnsde/ .