Stop Postman From Sharing Your API Traffic With Its AI

Postman's recent releases ship AI features that are enabled by default, and community reports show the app attempts to share request and response data with Postman's AI services unless you opt out. If you send production tokens, customer payloads, or health records through Postman, that default matters.

This article shows what to turn off in the app, how to verify what leaves your machine with a local proxy, and which fallbacks you still control if policy forbids Postman entirely.

What the AI features actually do

Postman bundles an AI assistant into the desktop app. Its features include generating requests from prompts, explaining responses, and suggesting tests. To do that, the client sends your collection content and sometimes request payloads to Postman's servers.

Two properties make this risky in a work context:

• The features are on by default. Nothing prompts you before the first AI-assisted action fires.
• The boundary between "collection metadata" and "request data" is not obvious in the UI, so it's easy to assume only names and URLs are shared when bodies and headers can be involved too.

The practical escape route is to disable the features, verify with a proxy, and enforce the ban in writing for your team.

Turn the AI features off in the app

Open Settings and work through these screens:

• General / AI features: disable the AI assistant and prompt-based request generation if the toggle exists in your build.
• Data: turn off anonymous analytics and crash reporting while you are there.
• Sync: if you do not need cloud workspaces, switch the workspace to local-only so collections stop leaving the machine entirely.

Settings move between releases, so treat this list as a checklist rather than a guarantee. After you flip the toggles, restart the app and confirm the settings survived.

Verify what leaves your machine

Trust but verify. Point Postman at a local HTTPS proxy that logs every outbound host, then use the app normally for ten minutes.

mitmproxy (https://mitmproxy.org) works well. Install its certificate so it can inspect TLS, then run it on port 8080:

mitmproxy --listen-port 8080 --set console_focus_add="~d postman"

Configure the system or per-app proxy to 127.0.0.1:8080, restart Postman, and watch the flow list. Any request to a Postman AI endpoint that fires while you merely open a saved collection is a finding worth screenshotting for your security team.

If the traffic is certificate-pinned and mitmproxy cannot inspect it, fall back to a passive DNS-level check with Little Snitch (macOS) or Portmaster (Windows/Linux). You lose payload visibility but keep host visibility.

Block the AI endpoints at the network edge

Local toggles can be reverted by an update. For a team, enforce the policy where you can see it: a hosts entry on developer machines, or a DNS rule in NextDNS or your company resolver.

# /etc/hosts -- coarse block, per developer machine
0.0.0.0 api.postman.com

That entry also breaks sign-in and sync, which may be exactly what you want, but it is a blunt tool. If you still need the Postman API for other things, block only the AI hostname once you have identified it with the proxy step, and pin the app version in your onboarding docs so a silent upgrade cannot re-enable anything.

Alternatives that keep data local

If your compliance rules say no third-party client touches production data at all, you need an exit. Each option trades convenience for control:

Bruno deserves a note for migrating teams. Collections are plain-text folders, so you can convert a Postman export with its importer or a short script:

# Export from Postman as a collection JSON, then inspect it locally
jq '.item[] | {name: .name, url: .request.url}' collection.json

Keeping requests in Git also gives you review history, which Postman's cloud workspaces never provided cleanly.

What this means for your codebase

The deeper lesson is that any tool holding real credentials and real payloads can exfiltrate both. Postman is the current example, not the last one. A few habits survive any vendor:

• Store secrets in environment variables the tool resolves at send time, never in the collection file.
• Give developers a scrubbed staging environment with fake customer data for manual API work.
• Review app updates as a supply-chain event, not just a changelog skim.

Key takeaways

• Postman's AI features are enabled by default and can transmit request and response data to Postman's servers, so disable them in Settings before sending anything sensitive.
• Verify with mitmproxy or a DNS-level blocker; trust the toggles less than the traffic.
• Enforce the policy for your whole team at the DNS or hosts level, because app updates can revert local settings.
• Bruno, VS Code REST Client, or plain curl give you a fully local fallback if policy rules out Postman.
• Keep secrets in environment variables and scrubbed environments, regardless of which client you use.

Source

Postman silently auto-installs AI plugins and attempts to share all API data -- the reported behavior; I added the settings checklist, traffic verification, network blocking, and migration options.

Support this work

These write-ups are researched and published with no paywall, sponsor, or tracking. If one saved you an afternoon, a small tip keeps them coming.

USDT, USDC or USDD · TRC-20 (Tron)

TFTNsfyomKrnUutRjBTGVULp19ByW29KbY