Secure Postman access for AI agents

Postman is where API design, testing, and documentation live for most engineering orgs, which means an agent with Postman access can read collections and specs to answer questions, but can just as easily publish a mock server, delete a workspace, or rewrite a monitor nobody asked it to touch. Adding Postman here puts every tool call through your policies and onto the audit log, so agents can explore your API surface without quietly reshaping it.

Server URL: https://mcp.postman.com/mcp

Credential modesCopy Anchor Link

Postman supports per-org dynamic registration only, so there is no app to create on Postman's side and no client ID or secret to enter. See Credential modes for how it compares with Use SecureAuth's app and Bring your own app.

Before you beginCopy Anchor Link

• A Postman account that can reach the workspaces and collections your agents need.
• Administrator access to your Agent Authority workspace, to add the resource.

SetupCopy Anchor Link

1. In the Agent Authority console, go to Tools & Services and click Add Resource.
2. Select Postman from the catalog.
3. On Choose how to install Postman, click Per-org dynamic registration. Selecting it adds the resource right away with its tools pre-configured.

Dynamic client registrationCopy Anchor Link

When you add the resource, the gateway registers its own OAuth client with Postman, the credential that lets it sign users in. Postman's own team, workspace, and role-based permissions still apply, so an agent can only reach what the person who signed in could already reach.

Verify the connectionCopy Anchor Link

The gateway syncs the Postman tools automatically. To check the connection end to end, ask your agent to run a request:

Get my Postman user

If your Postman user details come back, the connection is working.

How users connectCopy Anchor Link

Access is per user. Each additional user connects their own Postman account the first time their agent calls a Postman tool: the gateway returns a sign-in link, the user authorizes once, and the tools work from then on. Go to Connections to manage linked accounts.

Available toolsCopy Anchor Link

Postman exposes 124 tools. They are grouped below; the resource's Overview tab shows the authoritative per-tool list under Available Tools once installed.

A handful of these are worth a second look before you allow them broadly: respondPrivateNetworkAddRequest controls what joins your org's shared API network, publishMock/publishDocumentation make things externally visible, and the delete* family (collections, workspaces, mocks, monitors, specs, folders, requests, responses) is permanent: Postman has no recycle bin for most of these.

Required scopesCopy Anchor Link

The gateway does not request a fixed scope list for Postman. It registers the client without naming any scopes and records the ones Postman returns.

Policy examplesCopy Anchor Link

Read-only Postman for everyoneCopy Anchor Link

One deny rule blocks every mutating tool while leaving reads on the default path:

1. In Agent Actions, click Add Rule and name it "Postman: no writes."
2. Set the effect pill to Deny and the MCP scope pill to Postman.
3. Add these tool patterns: create*, update*, delete*, put*, patch*, duplicate*, generate*, publish*, unpublish*, merge*, transfer*, resolve*, respond*, add*, remove*, run*, sync*, pull*.
4. Set the status to Active and click Create.

That prefix list covers every writer in the tool set above; everything left over (the get*, list*, and search tools) keeps working.

Scope one agent to collection and spec browsing onlyCopy Anchor Link

An allow rule on its own restricts nothing, because every org is seeded with an Allow all rule that anything unmatched falls through to. To confine an agent, pair the allow with a deny beneath it:

1. Create the deny rule first: effect Deny, MCP scope Postman, Agent scope your browsing agent, tool pattern *.
2. Then create the allow rule: effect Allow, MCP scope Postman, the same Agent scope, tool patterns getCollection, getCollections, getCollectionFolder, getCollectionRequest, getCollectionResponse, getSpec, getAllSpecs, getSpecDefinition, searchPostmanElements, searchLearningCenter.

Order matters, and so does the sequence you create them in: new rules insert at the top of the list, so building the deny first leaves the allow above it. That is the order you need. Evaluation is first-match-wins, so the agent's browsing calls hit the allow, every other Postman call hits the deny, and neither ever reaches Allow all.

Scoping both rules to one agent keeps the blast radius small. A deny with no Agent scope would cut off every agent and user in the org.

Block destructive toolsCopy Anchor Link

One deny rule blocks every tool tagged destructive, regardless of its name:

1. In Agent Actions, click Add Rule and name it "Postman: no destructive tools."
2. Set the effect pill to Deny and the MCP scope pill to Postman.
3. Open the Tools pill and pick the built-in tag destructive.
4. Set the status to Active and click Create.

Next stepsCopy Anchor Link

• Create a policy – the full rule editor walkthrough.
• Policies – how first-match-wins ordering and the default Allow all rule interact.
• Block an agent from deleting GitHub branches – the same deny-first shape on another resource.