How to find secrets in Postman workspaces: Enumerate, scan and move them to a vault

Postman workspaces quietly become a store of production API keys, bearer tokens and passwords, held in shared variable values, request headers, auth settings and scripts that whole teams can read. Unlike a secrets manager, a workspace was not designed to hold credentials, and a public or widely shared workspace exposes them to people who were never meant to see them. This runbook shows how to find those secrets: Postman's Secret Scanner findings and its query API, enumeration of workspaces, collections and environments through the Postman API, an external scan with TruffleHog's Postman source, and the parts of a workspace you must review by hand. It then covers revoking what you find and moving it into a vault. It is for API, AppSec and secrets management teams. If the leaked credential is a Postman API key itself, start with Postman credentials.

This is an independent guide from NHI Mgmt Group, based on Postman's public documentation and the TruffleHog project documentation as of November 2026. It is not sponsored or reviewed by Postman. Product features change, so confirm settings against Postman's current documentation.

Key takeaways

• Start with Secret Scanner findings. Cloud Secret Detection scans collections, environments and published documentation in public workspaces by default; internal and Partner Workspaces need an Enterprise plan with the Advanced Security Administration add-on.
• Shared values are the main exposure. A local variable value stays on the user's machine, but a shared value syncs to the Postman Cloud for every teammate with access, so that is where to look first.
• Enumerate with the API, then scan. GET /workspaces, GET /workspaces/{workspaceId}, GET /collections/{collectionId} and GET /environments/{environmentId} give you every element to scan, and TruffleHog's postman command scans them directly.
• Scripts and examples hide secrets. Pre-request and test scripts, request bodies and saved examples carry literal tokens that variable reviews miss.
• Rotate, then move to a vault. Mark findings resolved only after the credential is revoked at its issuer and replaced by a Postman Vault or external vault reference.

When you need this

• Before or after making a workspace public: public workspaces are scanned by default because the exposure is to everyone.
• After a Postman API key leak: a key gives access to any Postman data its owner has permission for, so the secrets inside the reachable workspaces are the real blast radius.
• When onboarding Postman Enterprise or a security add-on: a baseline tells you how many live credentials sit in team workspaces before policies are switched on.
• Periodic hygiene: NIST SP 800-53 IA-5(7) No Embedded Unencrypted Static Authenticators and CM-12 Information Location both expect you to know where static credentials live.

Where secrets hide in a workspace

Postman's documentation separates a variable's local value, which "isn't synced to the Postman Cloud or shared with your teammates", from a shared value, which syncs to the cloud so teammates and cloud features can use it. The environment API marks secret type values as masked. Treat masking as a display control: anyone with access to the environment can still use the credential, and exports and forks may carry it.

Before you start

Use a dedicated scanning account rather than a person's account. A Postman API key acts as its owner, so a scanning key added to every workspace is a powerful non-human identity: set an expiry in API key settings, give the account a named owner, read access only where Postman's roles allow it, and remove it when the job ends. The API Key Management Guide covers the general rules. Store findings as location, type and the hash or obfuscated value, never the secret itself.

Step-by-step

Steps 1 to 5 are read-only. Steps 6 to 8 change credentials or workspace content.

1. Review existing Cloud Detection findings. In Organization settings, Secret Scanner, Cloud Detection, start on the Unresolved tab and filter by visibility type (public first), workspace name and secret type. Hover over a masked value and open Secret Details to see its SHA256 hash, which lets you match the same secret across workspaces without handling the value. Subscribe the response team to the daily summary email under Settings, Notifications.
2. Query findings through the API for reporting. With the add-on, pull all findings into your tracker:

   POST https://api.postman.com/detected-secrets-queries?limit=100&include=meta.total
   X-API-Key: <scanning key>
   Content-Type: application/json
   
   {"statuses": ["ACTIVE"], "workspaceVisibilities": ["public", "team"]}

   Each result carries secretId, secretType, workspaceId, workspaceVisibility, secretHash, obfuscatedSecret, occurrences and detectedAt. Page with cursor from meta.nextCursor. Use GET /secret-types for type IDs. EU-hosted teams use https://api.eu.postman.com.
3. Enumerate every workspace and element. List workspaces with GET /workspaces (filter with type=team or type=public, up to 100 per page), then GET /workspaces/{workspaceId} for each to get its collections, environments, mocks and monitors. Record the owner (createdBy) and visibility. Public and partner workspaces go first.
4. Scan collections and environments. Run TruffleHog's Postman source with the scanning key in the POSTMAN_TOKEN environment variable:

   trufflehog postman --workspace-id=<workspace id> --workspace-id=<workspace id>
   trufflehog postman --collection-id=<collection id> --environment=<environment id>

   The flags repeat for multiple targets, and --include-collection-id, --exclude-collection-id, --include-environments and --exclude-environments narrow a workspace scan. Add --json for machine-readable output and --results=verified,unknown to focus on credentials that are live or could not be tested. For exported files in repositories or shared drives, use --collection-paths, --environment-paths or --workspace-paths, or scan the folder with gitleaks dir.
5. Review what scanners miss. Open the highest-risk collections and read the auth tab at collection and folder level, pre-request and test scripts, and saved examples, looking for literal values rather than {{variable}} references. Check whether published documentation exists for those collections. Internal token formats need a custom detection pattern on Enterprise, or a TruffleHog custom regex detector.
6. Revoke or rotate at the issuer. For each confirmed secret, identify the system and identity behind it, check that system's logs for use since the element was shared or published, issue a replacement through your secrets manager and revoke the old one. Production cloud, payment and identity provider credentials come first. Follow the Leaked Credential Response Playbook.
7. Replace values with vault references. Move the new credential into Postman Vault: Local Vault keeps it on the user's machine and is not synced; a workspace's Shared Vault shares it with per-secret access scopes; on Enterprise with the add-on, link to an external vault so Postman stores only a reference. Shared Vault integrations with Azure Key Vault and HashiCorp Vault can resolve secrets for monitors, scheduled runs and Postman CLI pipelines. Remove the literal value from variables, headers, scripts and examples, and delete stale exported files.
8. Resolve the findings. In the dashboard mark findings Revoked, False positive or Won't fix, or through the API with PUT https://api.postman.com/detected-secrets/{secretId} and a body of resolution (REVOKED, FALSE_POSITIVE, ACCEPTED_RISK or ACTIVE) and workspaceId. Record who accepted any risk and why.

Choosing an approach

• Enterprise with the add-on: use Cloud Secret Detection across internal and Partner Workspaces as the baseline, the query API for reporting, and TruffleHog only for exported files and verification.
• Team or free plans: Cloud Secret Detection covers public workspaces by default (confirm what your plan includes), but team workspaces need your own enumeration and scan through the Postman API.
• Small team: a single TruffleHog run against each workspace and a manual review of auth and scripts is enough; move the handful of secrets to Local or Shared Vault.
• Large organisation: route findings to workspace owners by workspaceId, track time to revocation, switch on Local Secret Protection to stop new entries, and restrict who can create public workspaces.

Verify it worked

• Credentials: the revoked value fails at its issuer, and requests still work using vault references.
• Workspace: a repeat TruffleHog scan of the same workspace returns no finding for that secret, and the Cloud Detection Unresolved tab is empty for it.
• Exports: repository and shared-drive scans for exported collections show no copy of the value.
• Access: the scanning API key is deleted or has expired.

Rollback and common errors

Common failure patterns

• Trusting the secret variable type: masking hides the value on screen, but the credential is still shared with every collaborator.
• Deleting the variable without rotation: forks, exports and teammates' copies still hold a working key.
• Scanning variables only: literal tokens in auth tabs, scripts and saved examples are left behind.
• Forgetting published documentation: a collection published for partners exposes whatever it contains.
• Running the scan with a personal admin key: the most privileged key in the organisation is now on a scanning host with no expiry.

Hardening afterwards

• Prevent new entries: enable Local Secret Protection on a pilot workspace, review overrides, then widen it.
• Default to local values and vault references: make shared values the exception and require vault references in team workspaces. See the Secrets Management Guide.
• Control publication: limit who can create public workspaces and publish documentation, and review public workspaces quarterly.
• Scan exports in Git: exported collections in repositories fall under your Git Secret Scanning Guide controls and push protection.
• Set API key expiry: expiring Postman API keys reduce the chance that a leaked key opens every workspace.

Ongoing detection

A one-off sweep goes stale quickly because collections are copied and edited every day. Keep three feeds running. Summary emails: Admins, Super Admins and Workspace Admins can subscribe to daily (sent at 12:00 AM UTC), weekly (Mondays) or monthly Secret Scanner summaries; send the daily one to a shared response mailbox rather than one person. Scheduled query: run detected-secrets-queries with since set to the previous run time and push new ACTIVE findings into your ticketing or SIEM pipeline, keyed on secretHash so the same secret in several workspaces becomes one incident. Exported files: treat exported collection and environment JSON in repositories like any other code, with push protection and history scanning. Watch the ratio of new findings to resolved findings each month: if new findings keep pace with resolutions, the problem is habit and templates, not backlog.

Metrics

Framework mapping

Practitioner checklist

• Create a dedicated scanning account and API key with an expiry and an owner.
• Work the Cloud Detection Unresolved tab, public workspaces first.
• Pull findings through detected-secrets-queries into your tracker.
• Enumerate every workspace, collection and environment with the Postman API.
• Scan with TruffleHog's Postman source and exported files with a file scanner.
• Review auth tabs, scripts, saved examples and published documentation by hand.
• Revoke at the issuer, then replace values with Postman Vault or external vault references.
• Resolve findings with a reason and delete the scanning key.

Standards and references

• Postman: Secret Scanner
• Postman: Manage Cloud Secret Detection findings
• Postman API: Search detected secrets
• Postman: Store secrets in Postman Vault
• Postman: Manage environments
• Postman API: Get a collection
• NIST: SP 800-53 Rev. 5
• TruffleHog: project documentation

Related NHI Mgmt Group resources: Postman credentials · API Key Management Guide · Secret Sprawl Measurement Guide · Leaked Credential Response Playbook