Not by default. Postman's documentation says collection, environment and global variable values are only available locally in your instance and are not synced to the Postman Cloud, unless an editor chooses to share a value. Cloud features such as monitors use the shared value, so keep real tokens out of it.
Variable scopes
Postman's variables documentation describes several scopes. Global variables are available throughout a workspace. Collection variables are available to the requests in a collection and do not change with the selected environment. Environment variables scope your work to contexts such as local development, testing or production, with one environment active at a time. Data variables come from CSV or JSON files for collection runs, and local variables are temporary values that exist for one request or run.
The page suggests global variables suit testing and prototyping, and that you should use more specific scopes later in development.
Local value versus shared value
By default, collection, environment and global variable values are only available locally in your instance, and the local value is used when you send requests. It is not synced to the cloud, so you can update it without sharing it with teammates.
If you have Editor access, you can share a variable's value, which syncs it to the cloud so teammates get a default to start with. Teammates can keep their own local values and can reset to the shared value at any time.
The catch: the documentation says some features that run in the cloud, including scheduled collection runs, monitors and the Postman CLI, also use the shared value when sending requests. So if you put a real token in the shared field to make a monitor work, it is now stored beyond your own machine and visible to people with access to that item.
A safe pattern for secrets
| Value | Where to put it |
|---|---|
| Base URL, example IDs | Shared value, fine |
| Your personal token | Local value only |
| Token a monitor needs | A dedicated, narrowly scoped, low privilege token, reviewed by the team |
| Production credentials | Not in a collection at all |
Use an access token with the fewest permissions the request needs, and name it after the purpose. Share a placeholder so teammates know which variable to fill in.
Mistakes to look for
Search your workspaces for variables named token, key or password, and open the shared value column. Check exported collection files before sending them to a colleague, since an export may include values. Remove old environments for staging and production that nobody uses. When someone leaves, revoke the tokens they created, not just their workspace access.
Team policy in three lines
Real tokens live in each person's local value. Anything shared is a placeholder or a low privilege test credential. Anything a cloud feature must use gets its own review and an expiry date.
Where Safeguard fits
Safeguard works on the dependency and code side of your software: SBOM and dependency scanning, reachability analysis and policy gates. It does not store or manage credentials, so keep using your password manager, secrets manager or cloud identity for that. You can run a free scan of a project at gold.safeguard.sh/scan.
Quick check
Is a local value visible to teammates?
The documentation says local values are not synced and can be changed without sharing.
Do monitors use my local value?
The documentation says cloud features such as scheduled runs and monitors use the shared value.
Should a collection ever hold a production token?
Avoid it. Use sandbox credentials and keep production secrets in your platform's secret store.
Sources
Last reviewed: 19 October 2026.
