Postman Quietly Installs AI Plugins to Share API Data

As AI features are enabled by default in development tools, the risk of API data being sent externally without consent is spreading. Focusing on the Postman case, we examine risk paths and a corporate audit/blocking checklist.

As AI features are enabled by default in development tools, a structure is spreading in which API call logs and authentication information can be transmitted to external AI models without user consent. The controversy over Postman's default activation of AI features shows that this is not merely a convenience addition but a direct threat to the data governance of individual developers and organizations. Recently, infostealers targeting credentials in AI coding tools and API key leakage incidents have followed, making the 'quiet AI transformation' of development tools a trust issue that can no longer be ignored.

The Risks Quiet AI Activation Brings to Developer Workflows

Postman, a leading API development collaboration tool, has recently expanded its features by enabling an AI assistant by default. The problem is that in some cases, request and response data are configured to go through an AI processing pipeline even without explicit user consent. Developers may think they are testing APIs securely locally, but in reality, endpoint addresses, request headers, and response bodies included in collections can be sent to cloud AI services.

This change becomes even more dangerous when combined with the trend of 'vibe coding' and the normalization of AI coding tools. If a developer calls a production API with AI features enabled, production tokens and customer personal information can be exposed to AI models. According to a recent Symantec report, the Aoki infostealer has begun targeting credentials and session files from AI coding assistants. This means attackers know exactly the value of API keys and session information stored by AI tools.

Specific Paths and Impact of API Keys and Request Data Leaving the Organization

When AI features are enabled by default, data is exposed externally through three main paths. First, the AI assistant sends requests and responses to the cloud to generate replies, which is a direct transmission path. Second, AI inputs may be included in telemetry collection for error diagnostics or user behavior analysis. Third, plugins or extensions request excessive permissions and quietly collect data.

Real incident cases show that these concerns are not unfounded. In October 2026, the open-source AI coding agent OpenCode suffered an incident where attackers used AI agents to expose console API keys. During this process, third-party API keys from OpenAI, Anthropic, and Google were leaked, affecting 1.4% of all users. The AI tool itself became a new attack surface for API keys. Although there are no reports that Postman's AI features have been attacked in the same way, as the number of by-default AI connections grows, the exposure area for similar risks widens.

Ripple Effects on Team Compliance and Code Review

The moment a developer turns on AI features, that action does not appear on the code review screen. The diff only shows code changes, and you cannot confirm which data was sent to AI until you examine the audit logs. As a result, team-level compliance quietly breaks down. GDPR, HIPAA, financial security regulations, and others require documenting and controlling data processing paths, but AI features enabled by default produce 'shadow AI' that operates outside such controls.

Without notice and consent, it is difficult for security teams to proactively block risks. The very structure that requires developers to find out 'how to turn off AI features' and change settings themselves is a problem. Organizations should centrally enforce disabling AI defaults in development tools and, if exceptions are allowed, document the scope of data transmission and retention policies. A checklist is needed during code review to check not only AI-generated code but also whether AI features are being used.

Practical Checklist for Data Flow Auditing and Blocking in Enterprise Environments

When adopting AI-based development tools in an enterprise, it is advisable to check the following items in order.

  • Check defaults: In central settings, verify whether AI features are enabled by default in the API clients, IDE plugins, and coding assistants used by your organization.
  • Network filtering: Monitor traffic going to AI service endpoints at the proxy, and block unauthorized AI domains.
  • API key isolation: Separate development and production keys, and inject only test-only keys into AI tools. Minimize key scopes and set short expiration cycles.
  • Data masking: Add a preprocessing layer that automatically masks personal information, tokens, and internal hostnames from requests and responses before sending to AI.
  • Policy documentation: Obtain vendor documentation on where data goes, how long it is retained, and whether it is used for training when AI features are used, then establish an internal approval process.

This checklist should be repeated quarterly rather than one-time, because AI features may quietly turn back on through updates or policies may change.

Regaining Control with Open Source Alternatives and Self-Hosting

If Postman's default AI activation is uncomfortable, switching to open-source API clients like Bruno, Hoppscotch, or Insomnia is also a way. These keep data local by default and do not force cloud AI calls. However, open source is not a cure-all. If you add AI features, they will eventually call external LLM APIs, and at that moment the same data transmission problem reappears. Integrating a self-hosted LLM or using the tool with AI features completely disabled is a realistic compromise.

Furthermore, open-source tools are not immune to security incidents. The OpenCode leak mentioned earlier occurred in an open-source AI coding agent. Self-hosting increases control, but it also means the organization must take direct responsibility for patch management, access control, and log monitoring. Ultimately, 'knowing where data flows' matters more than 'which tool you use.'

Conclusion

AI features in development tools improve productivity, but data sovereignty and trust should not be sacrificed by default. Tools must transparently disclose what data they send where, and remain disabled until users explicitly choose to enable them. To easily review and preserve an immutable version of AI feature activation status, data transmission scope, and audit results, using a human-in-the-loop review and archive layer like md-log is one way. The trust that quiet AI transformation breaks can ultimately be restored through transparent records and explicit control.

References

Frequently asked questions

If Postman's AI features are turned on by default, what data is sent externally?
Endpoint addresses, headers, authentication tokens, and body data included in API requests and responses can be transmitted during cloud AI processing. Even without explicit user consent, data that you think is local can leave your environment when the feature is enabled by default. Therefore, in enterprise environments, you should centrally disable AI features or apply data masking.
How should an enterprise safely adopt AI-based development tools?
First, check the default state of AI features and disable them through central management, then only allow approved AI domains on the network. Separate API keys for testing only, mask request data, and document vendor data retention and training policies before going through an approval process. It is also necessary to audit settings quarterly to ensure features have not been turned back on.
Does switching to an open-source API client solve all data leakage problems?
Open-source tools generally run locally and do not force cloud transmission, but if you integrate AI features, they call external LLM APIs and the same transmission issues can arise. In addition, open-source tools can also be exposed to security vulnerabilities, as in the OpenCode leak, so continuous patching and log monitoring are required. Self-hosting increases control but also brings management responsibilities.
Why are credential theft incidents targeting AI coding tools increasing recently?
AI coding tools store API keys, session tokens, and cloud credentials locally or exchange them with the cloud, making them an attractive target for attackers. In fact, in the October 2026 OpenCode leak, attackers used AI agents to steal API keys from OpenAI, Anthropic, and Google. Infostealers are also adding collection capabilities specifically for AI tools, making attacks more specialized.

Related posts

← All posts