Postman AI Complaint: Check What Your API Tools Can See

Postman AI Plugins: Check What Your API Tools Can See

An API client can hold more of your business than you realize: saved requests, test responses, workspace access, and credentials used to connect other systems. If an AI feature appears inside that client, the useful question is not just whether it is installed. It is what the feature can read, what it can change, and whether you can verify either one.

A public complaint about Postman’s AI plugin raised that question, but the available account does not establish that customer data or credentials left Postman. Here’s exactly how I would check a small business integration without treating an allegation as a confirmed breach.

What the Postman complaint does—and does not—establish

The reported behavior warrants an access review, not a claim that Postman leaked your API data. The available account describes an attempted connection that failed authentication; it does not establish a completed transfer, identify every affected installation, or show that the sequence was reproduced on another machine.

Keep four questions separate:

Question	What would answer it
Was a plugin installed?	The plugin’s installation status on each relevant machine and coding agent
Could it authenticate?	Its configured credentials and the account or workspace they belong to
What could it reach?	The permissions of those credentials and the tools available to the agent
Did data leave?	Relevant transfer records or other evidence of an actual completed request

A “yes” in the first row is not a “yes” in the last. Likewise, a failed connection attempt does not prove that every other route was unavailable. If you need to investigate a specific incident, preserve the relevant records and examine that environment rather than generalizing from a headline.

Postman’s current desktop-app documentation describes how to uninstall the Postman Coding Agent Plugin. It also discusses installation behavior, but current documentation cannot establish exactly what a particular user saw during an earlier installation. Treat it as guidance for checking your setup now, not a reconstruction of someone else’s.

For a small team, the practical response is narrower: identify the API tools you rely on, inspect the access attached to them, and reduce anything you cannot justify.

Map the access path, not just the plugin

An AI feature’s effective reach depends on the entire path from agent to plugin to credential to resource. Checking whether the plugin exists is useful, but it misses the permissions that determine what an authenticated request could do.

Consider a lead-follow-up workflow. A new inquiry arrives, your team looks up the lead in a CRM, and an integration prepares a reply. During development, an API client may hold a sample CRM request, a saved response, and a credential for testing. The business job might require reading one lead and creating a draft. A credential that can also export customer records or delete them would have more authority than that job needs.

That example is hypothetical; it is not a finding about the Postman complaint. It gives you a way to inspect your own system. Draw the path as plainly as possible:

Coding agent
    → Postman plugin or connected tool
    → authenticated Postman account or API key
    → accessible workspaces and resources
    → any separately connected business service

Do not collapse the last two lines. Access to a Postman workspace does not, by itself, describe what a CRM credential inside a request can do. Conversely, finding no usable CRM credential does not tell you whether an agent can read or change Postman resources.

Postman’s API key documentation says an API key can access Postman data for which its owner has permission. That makes the key owner’s accessible workspaces part of your review. Postman also says its MCP server enables AI agents to manage resources including workspaces, collections, specifications, mocks, and monitors. “AI access” is therefore too vague to put in an approval note. Name the connection and the resources it exposes.

For each connection, write down what you can establish from the actual account and permission screens. Mark everything else unknown. An unknown is not evidence of exposure, but it is not a permission you have verified either.

Check installation, credentials, and resource access separately

A reliable audit has three distinct passes: find where the plugin is installed, identify how each connection authenticates, and inspect what the authenticated account can access. Removing a plugin addresses installation; it does not automatically revoke an API key or another service’s credential.

Start with the machines and coding agents used to build or maintain the integration. Postman documents a plugin status command that shows which detected coding agents have the plugin installed. Use the command in the linked documentation rather than guessing its syntax or assuming that a check on one machine covers the whole team.

Next, examine authentication. Look at the account attached to any Postman API key used by the tool, then check the workspaces that account can reach. Separately inspect credentials saved for the CRM, inbox, billing platform, or other services involved in your workflow. A credential’s presence and its permissions are different findings: record both.

Finally, compare available access with the job the workflow performs:

Access to inspect	Question to answer
Saved requests and examples	Do they contain real customer information or internal details?
Postman workspaces	Which workspaces can the authenticated owner access?
Connected-service credentials	Which account is used, and what actions does it permit?
Agent tools	Can the agent only inspect resources, or can it change them?
Revoke controls	Which specific key, connection, or plugin would you disable?

If you decide the plugin should not remain installed, Postman documents a remove command for detected coding agents. Its desktop-app instructions give another path: Help > Postman CLI and Plugins > Uninstall Postman Coding Agent Plugin, followed by restarting coding agents. Check installation status again afterward.

Then review credentials as a separate task. If a key has broader access than the workflow needs, change or revoke it through the relevant service’s controls after checking what production jobs depend on it. Uninstalling the plugin does not prove that no data was transferred, and it should not be treated as a substitute for credential review.

Test one workflow with synthetic data

A controlled test tells you what your integration does with a specific input; it does not prove what happened in someone else’s Postman installation. Use fictional records, observe the resulting actions, and keep production customer data out of the test.

Start with one workflow rather than an inventory of every tool in the business. Lead follow-up is a good candidate because the desired outcome is easy to state: receive a fictional inquiry, look up or create the appropriate test record, and prepare a draft for review. Whether the system should send a message, update the CRM, or stop for approval must be decided before you run it.

Create a test record clearly marked as synthetic. The fields below are an illustration, not a schema you should paste into a live CRM:

test_lead:
  name: "Test Customer"
  company: "Fictional Example Company"
  inquiry: "Synthetic request for a product demonstration."
  contact_route: "controlled test inbox"

expected_behavior:
  crm: "read or update only the test record"
  email: "create a draft; do not send"
  exception: "ask for review if the lead cannot be matched"

Run the workflow through the same entry point your team normally uses, with a test environment or other controls appropriate to your setup. Watch the CRM record, the draft folder, any send activity, and the workflow’s own execution history. Record observed behavior beside expected behavior. If you cannot see whether a step ran, write “not observable” rather than “did not happen.”

Pay attention to the handoff. A system that creates a draft but silently fails to flag an unmatched lead is not finished just because it avoided sending an email. Equally, a workflow meant only to draft replies should not have permission to send them merely because that was easier to configure.

If an AI feature participates, ask which data it receives for this test and which tools it can invoke. Can it see only the fictional inquiry supplied to it, or can it browse unrelated workspaces? Can it propose an update for review, or execute one? Those are configuration questions to answer from the tool and account in front of you, not assumptions to make from the word “assistant.”

Keep an access record you can use during an incident

The useful output is a short record that names the connected account, readable information, permitted actions, and exact revocation path. If an integration breaks or a new AI feature requests access, that record lets you make a decision without rebuilding the permission map from memory.

Here is a format you can use for a single workflow. The values are illustrative; replace them with findings from your own permission screens:

workflow: "Lead follow-up"
tool: "API client and connected coding agent"
connected_account: "record the actual account owner"

can_read:
  - "list verified resources here"

can_act:
  - "list verified actions here"

credentials:
  - "name where each credential is managed; never paste its value"

revoke_at:
  plugin: "document the installation removal path"
  postman_key: "document the key management path"
  connected_service: "document that service's credential controls"

unknown:
  - "list anything not yet verified"

test_result:
  expected: "draft for review"
  observed: "record what the synthetic test did"

Store this record somewhere the person maintaining the integration can find it, but do not put secret values in it. Update it when you change the account, credential, plugin, or workflow behavior. The record is especially valuable for a small team: the person responding to a problem may not be the person who originally connected the tools.

Make the permission check part of the build

Access mapping and a synthetic end-to-end test can be part of delivering a workflow, not cleanup after the AI feature is switched on. A working lead-follow-up system has a defined trigger, the minimum actions needed to prepare the reply, and a visible review or exception path. The Postman complaint is a reason to check those boundaries in your own tools—not evidence that your data has already left them.

---

Want more like this?

I’m Lazar Milićević, a senior engineer focused on practical AI automation for solopreneurs and small teams.