If you’ve worked on a team long enough, you’ve probably had the conversation. Someone shares a Postman collection, another developer imports it, and somewhere in that collection there’s a hardcoded API key. Or a Bearer token. Or a database password sitting in plain text inside an environment file that got checked into version control three months ago.
It’s one of those problems where everyone knows it’s bad practice, but the tooling hasn’t made doing the right thing easy enough. Until now.
We’ve shipped three new capabilities that handle secrets detection and storage automatically: Local Secrets Protection, Postman Shared Vault, and Secrets Resolution. Together, they catch secrets at runtime, secure them in a vault based on your team’s policy, and replace the raw values with variable references in your collections and environments. Available across all plans, including the free plan.
The problem worth understanding
Before getting into what shipped, it helps to be specific about why secrets leak in the first place.
Postman collections and environments are designed to be shared. That’s the point. You build a collection, add request examples, configure an environment with your API’s base URL and auth headers, and share it with your team so they don’t have to set everything up from scratch.
The issue is that environment variable values travel with the collection. If you put your actual API key in an environment variable’s “current value” field and then export that environment to share it, the key goes with it. If you store credentials in collection-level variables, same thing. If you use a pre-request script that hard codes a token because you were debugging something quickly last Tuesday and forgot to clean it up, that token is now in your team workspace.
According to GitGuardian’s State of Secrets Sprawl report, millions of secrets are exposed in public repositories every year, and internal tools and collaboration platforms are a growing vector. API clients are exactly the kind of tool where developers store credentials and then share artifacts without thinking twice.
The traditional mitigation is discipline: use variable references, never put real values in “initial value” fields, rotate credentials regularly, do periodic audits of your workspaces. Useful advice, but it depends on every developer getting it right every time.
What we shipped
The three new capabilities work together as a system:
Local Secrets Protection runs on your machine. When Postman detects what looks like a secret in a request, a pre-request script, an environment value, or anywhere else in your workspace, it intercepts it before it syncs to the cloud or propagates to a shared collection. The detection happens at runtime, so you don’t have to remember to scan manually.
Postman Shared Vault is the team-facing piece. It’s a centralized vault that workspace administrators manage. Admins configure which types of secrets get stored there, set the scope (which workspaces or teams can access it), and control the policy for how secrets are stored and rotated. Developers access vault-stored secrets through variable references without ever seeing the raw values.
Secrets Resolution ties the two together. When a secret is detected and secured, Postman replaces the raw value with a variable reference automatically. Your collection ends up with {{api_key}} where a real key used to be. Your environments stay clean. And anyone who later imports or accesses that collection gets the variable reference, not the credential.
How Local Secrets Protection works
When you make a request or run a collection, Postman scans the request context for patterns that look like secrets. This includes common formats: API keys, Bearer tokens, OAuth tokens, private keys, connection strings. The detection runs on your local machine before anything syncs.
If a secret is detected, Postman applies the vault policy your administrator configured:
- Store locally: The secret is secured in Postman Local Vault on your machine. It never syncs to the cloud. Other developers on your team can’t access it, which is appropriate for credentials that are specific to you (your personal developer API key, for example).
- Store in Shared Vault: The secret is pushed to Postman Shared Vault and becomes accessible to other team members who have permission, through the vault’s access controls.
The policy is set by a workspace admin, so individual developers don’t have to make judgment calls about where a secret should live. You get a notification when a secret is detected and secured.
For developers, the day-to-day experience changes in one useful way: you can drop a real API key into an environment variable to get something working, and Postman handles moving it to the vault. You don’t have to remember the cleanup step.
Postman Shared Vault for teams
The Shared Vault is the piece that matters most at the team level. Without it, secrets management in Postman worked more or less like it works everywhere else: tell developers not to commit credentials, remind them periodically, notice the leak after the fact.
Shared Vault gives admins actual controls:
- Define which secret types are vaulted: You can configure detection patterns and policies per secret type. API keys might go to the Shared Vault; personal OAuth tokens might stay local.
- Scope access: Control which teams, workspaces, or users can read from the vault.
- Rotate credentials once: When an API key needs to be rotated, you update it in the Shared Vault and the change propagates to everyone who’s using the variable reference. No more asking every developer to update their local environment.
For teams that already integrate with external secret managers, Postman also supports Postman Vault Integrations with 1Password, AWS Secrets Manager, Azure Key Vault, and HashiCorp Vault. The Shared Vault and external integrations can coexist, so you’re not forced to migrate everything.
Secrets Resolution: variable references without the manual work
Secrets Resolution is the part that makes the other two capabilities actually usable in practice.
After a secret is detected and secured, Postman replaces the raw value in your collection or environment with a variable reference. The collection is updated in place. If you were using a literal API key in a request header like this:
GET https://api.example.com/v1/users
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...
After Secrets Resolution runs, it becomes:
GET https://api.example.com/v1/users
Authorization: Bearer {{api_token}}
The variable api_token is now backed by your Local Vault or Shared Vault. When the request runs, Postman resolves the variable from the vault. The resolved value never appears in logs or collection exports.
This is meaningful for collections you’re writing from scratch, but it’s especially useful for collections that have been around a while. Teams often let hardcoded values accumulate in shared collections over months without noticing. Running Secrets Resolution over an existing workspace can surface problems you didn’t know you had.
Working with vault-backed variables in scripts
Vault-backed variables work like any other Postman variable in your test scripts and pre-request scripts. You reference them with {{variable_name}} syntax, and Postman resolves the value at runtime.
A test script that validates an authenticated response looks the same regardless of where the token lives:
pm.test("Request authenticated successfully", function () {
pm.response.to.have.status(200);
});
pm.test("Response includes user data", function () {
const response = pm.response.json();
pm.expect(response).to.have.property("id");
pm.expect(response).to.have.property("email");
});
Where it matters is in pre-request scripts that dynamically refresh tokens. Instead of storing a refresh token in a plain environment variable, you can store it in the vault and reference it:
const refreshToken = pm.vault.get("refresh_token");
pm.sendRequest({
url: "https://auth.example.com/oauth/token",
method: "POST",
header: { "Content-Type": "application/x-www-form-urlencoded" },
body: {
mode: "urlencoded",
urlencoded: [
{ key: "grant_type", value: "refresh_token" },
{ key: "refresh_token", value: refreshToken },
{ key: "client_id", value: pm.environment.get("client_id") }
]
}
}, function (err, response) {
if (!err && response.status === 200) {
const newToken = response.json().access_token;
pm.vault.set("access_token", newToken);
}
});
The pm.vault API lets scripts read from and write to the vault programmatically. Tokens that get refreshed during a collection run stay in the vault rather than being written back to a plain environment variable.
For more on Postman scripting, the Postman Docs pre-request scripts reference covers the full API surface.
Admin setup: configuring vault policy
Workspace admins configure vault policy in the admin settings. The main decisions are:
- Detection scope: Which workspaces have Local Secrets Protection turned on
- Default vault target: Where detected secrets go by default (Local Vault or Shared Vault)
- Secret type policies: Whether specific secret types (API keys, OAuth tokens, connection strings) have different routing rules
- Shared Vault access: Which teams or workspaces can access vault-stored secrets and at what permission level
Policy changes apply to new detections going forward. Secrets already in your collections and environments are migrated through Secrets Resolution, which you can run manually or configure to run automatically.
If you’re managing a larger team and want to integrate with an external secret manager rather than Postman Shared Vault, the Postman Vault Integrations documentation walks through the connector setup for AWS Secrets Manager, Azure Key Vault, HashiCorp Vault, and 1Password.
Things to watch for
Existing collections aren’t automatically migrated. Local Secrets Protection and Secrets Resolution apply to secrets as they’re encountered going forward. If you have collections with hardcoded values that haven’t been touched recently, you’ll want to run Secrets Resolution explicitly over those workspaces. Don’t assume that turning on the feature retroactively cleans up your workspace.
Initial value vs. current value still matters. Postman has always distinguished between a variable’s “initial value” (shared with your team) and “current value” (local to your machine). Secrets Resolution handles detection, but understanding this distinction is still useful for cases where vault detection doesn’t catch something. See Postman Docs on managing environments for a refresher.
The pm.vault API is available in scripts. If you’re programmatically managing tokens in pre-request scripts, you can switch from pm.environment.set() to pm.vault.set() for anything that’s a credential. The vault-backed value won’t appear in the Postman Console output, which matters if you’re running collections in CI and logging output.
Plan availability covers everyone. Local Secrets Protection, Postman Shared Vault, and Secrets Resolution are available on all plans, including the free plan. The Shared Vault capacity and admin policy controls scale with plan tier, but the core detection and variable reference replacement works across the board.
Trying it yourself
The best way to see this in action is to take an existing collection that has hardcoded credentials and watch what happens when Local Secrets Protection runs.
- Open a collection in Postman that includes a request with a real API key in an environment variable’s current value.
- Run the request. If Local Secrets Protection detects it, you’ll see a notification and the value will be moved to your vault.
- Check the environment variable afterward. The current value field will now reference the vault-backed variable.
For team scenarios, have your workspace admin set up a Shared Vault policy, then try sharing a collection with a vault-backed variable with a colleague. They’ll get the variable reference and pull the value from the Shared Vault at runtime, without ever seeing the credential itself.
The Postman Vault documentation has the full setup guide including the admin configuration walkthrough.
Resources
The post What’s new in Postman: Secrets management built in appeared first on Postman Blog.
Log in
