For as long as software has called APIs, we’ve solved the same problem the same way. The code needs a secret (a key, a token, a credential), so we give it one. We copy it into a config file, an environment variable, a secrets manager, an OS keychain. The details have changed a great deal over the years. The shape of the answer never has: to make the call, the caller holds the secret.
That assumption has been quietly load-bearing for two decades. It’s about to stop being safe.
To understand why, it helps to trace how we got here.
We kept getting better at storing secrets
Secrets management has a clear line of progress, and every step on it was a real improvement.
Hard-coded in source. The original sin, and still the most common finding in any first security review. The key sits in the code, which means it’s in the repository, in every clone, and in the git history forever. Rotating it means a commit. Anyone who can read the code can read the key.
Externalized configuration. So we pulled secrets out of the code and into environment variables and .env files. This was genuinely better: the key stopped shipping with the source. But it didn’t stop existing in plaintext; it just moved from the repository to the environment, where every process you launch inherits it whether it needs it or not.
Centralized secret managers. Then came HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, and their peers: one source of truth, with encryption at rest, rotation policies, access policies, and audit logging on the store itself. This is the current state of the art for most teams, and for good reason. It solved storage properly.
Local vaults and credential helpers. In parallel, the OS keychain, git’s credential helper, and tools like Postman Local Vault kept secrets off shared infrastructure and encrypted on the developer’s own machine.
Each generation answered the question where do we keep the key? better than the one before it.
Every generation improved where the key is stored. The next one changes whether the caller holds it at all.
But most importantly, every one of these generations makes the same assumption about the consumer:
At the moment of the call, the consumer holds the real secret.
Storage got centralized, encrypted, rotated, and audited. Use never changed. A secret manager secures the key at rest and then, at request time, hands the plaintext to the thing making the call. From that instant, the secret lives in the application’s memory, its logs, its outbound requests, and every copy the consumer makes of it. The vault secured the key right up until the moment it mattered most, and then handed it over.
For most of software’s history, that was a safe enough trade. Agentic development is what turns it into a liability.
Agents don’t work that way
Given a goal rather than an instruction, an agent decides while it is running which tools to call and which hosts to hit, and every process it spawns inherits your environment variables whether or not it needs them. A key you exported for one task is now reachable by code you did not write, making calls to endpoints you did not choose. The execution path that spends the credential doesn’t exist until runtime, so there is no file you could open beforehand to predict where it ends up.
That is enough to break the storage model. Where is the key kept? had a satisfying answer for twenty years, because you put it somewhere and so you knew where it was. Once an agent is the caller, the honest answer to where does this key go? is that you can’t know in advance – and real agent traffic bears that out, fanning a single exported key across hosts, processes, and formats that no one chose ahead of time.
Better storage cannot fix a problem that isn’t about storage.
A different answer: grant access, don’t distribute secrets
The way out is to stop improving where the secret is stored and change whether the consumer ever holds it at all.
Instead of handing out the secret, hand out a credential reference, a token that points at a secret without containing it. The real key stays in your own network, in your existing secret store. When a request goes through a secure access proxy running inside that network, the proxy resolves the reference, injects the real credential, forwards the request, and returns the response. The consumer places the reference wherever the secret used to go and gets back a normal, authenticated result. It never holds the secret.
This inverts the model. Secrets management became an access-control problem instead of a storage-and-distribution one.
The inversion: stop handing every consumer a copy of the secret, and hand them a reference that only resolves through a proxy inside your network.
In practice, that model provides:
- Credential references in place of distributed keys, so consumers hold pointers, not secrets.
- Resolution inside your own network, in front of your existing secret store, so the plaintext never crosses an external boundary and never reaches the application layer, logs, or the vendor’s cloud.
- Cryptographically proven caller identity, bound to the holder, so a reference copied off a machine is inert without the matching identity.
- Operation-level scope, so a consumer can be granted read and denied delete on the same API.
- Per-consumer, revoke-anytime access, so you can cut off one caller without touching any other.
- Attribution on every call, so the audit record answers who did what, not merely that something happened.
- One consistent model across humans, CI pipelines, and AI agents, because “consumer” was never only a person.
From distributing secrets to governing access
Every generation of secrets tooling answered a storage question better than the last. The next one answers a different question entirely.
The unit we need to govern is no longer a secret you keep safe. It is an act of access: a specific caller making a specific call, with a specific scope, at a specific moment.
The old question was:
Where is this key kept, and is it encrypted?
The new question is:
Who (person, pipeline, or agent) is allowed to make this call, scoped to what, right now, and can I prove it and take it back?
A model built to answer the first question cannot answer the second, no matter how good its storage becomes. Encrypting a key at rest tells you nothing about who is allowed to spend it or where it will go once you hand it over. That is the shift, and like every shift before it, the tooling has to evolve to meet it.
How Postman Passport puts the access model into practice
At Postman, this is the shift we’re building Postman Passport to meet.
A request through Passport: the reference goes in, the proxy resolves the real secret inside your network, and the target API sees a normal authenticated call, while the secret never leaves your network.
Passport is a secure API access system for your team. Instead of distributing keys to every consumer that needs one, it grants access with credential references while the real secrets stay inside your own network. The secure access proxy runs in your network, in front of the secret store you already use (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, 1Password), and resolves references at request time. Your rotation policies, audit trails, and access policies inside that store keep applying. Passport adds the layer above them that keeps consumers from ever seeing a resolved value.
Everything the previous section argued for is the design:
- Identity is cryptographic and bound to the holder, so a stolen reference is inert.
- Scope is checked before the store is ever contacted, and can be granted down to the operation.
- Secrets are resolved inside your network and never transit the Postman cloud, logs, or audit records.
- Access is granted per API and revoked as a single write in your Private API Network: no key to rotate, no distribution list to chase.
- And because a consumer was never only a human, the same model covers CI pipelines and AI agents. You grant an agent scoped, revocable access instead of handing it a key it can leak into a prompt, a log, or a third-party tool.
That last point is where this connects to the broader shift the industry is working through. As teams stand up infrastructure to govern what an agent may do (the gateways and control planes emerging around agentic systems), Passport governs which credentials it may use, without ever giving it the credential. Governing intent and governing access are two halves of the same problem, and neither is solved by better storage.
If you distribute static keys to consumers today, the place to start is the honest question from earlier, asked of one API: if this consumer had to be cut off this afternoon, could I prove their access was gone by tonight? The APIs where the answer is “we’d rotate what we remembered” are the ones where an access model pays for itself first.
Postman Passport is available now. Point one high-value key at a reference and watch a real call succeed with the secret nowhere near the caller — that’s the whole idea, and it’s the fastest way to see it.
Try Postman Passport → usepassport.ai
Resources
The post From API Keys to Access Control: Rethinking Secrets Management appeared first on Postman Blog.
Log in
