Secure Postman access for AI agents

Manage Postman workspaces, collections, environments, specs, mocks, and monitors, and search Postman's Learning Center, via Postman's official MCP server.

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 modes

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 begin

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

Setup

  1. In the Agent Authority console, go to Resources 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 registration

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 connection

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 connect

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 tools

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

ToolDescription
getAuthenticatedUserGet information about the authenticated user
getEnabledToolsList the tools enabled for this connection – run this first if a tool seems missing
createWorkspace / getWorkspace / getWorkspaces / updateWorkspace / deleteWorkspaceCreate, read, update, or delete a workspace
getWorkspaceGlobalVariables / updateWorkspaceGlobalVariablesGet or replace a workspace's global variables
getWorkspaceTags / updateWorkspaceTagsGet or update a workspace's tags
addWorkspaceToPrivateNetwork / removeWorkspaceFromPrivateNetworkPublish a workspace to, or remove it from, your team's Private API Network
listPrivateNetworkWorkspaces / listPrivateNetworkAddRequestsList workspaces on the Private API Network, or pending add requests
respondPrivateNetworkAddRequestApprove or reject a request to add a workspace to the Private API Network
createCollection / getCollection / getCollectionsCreate a collection, or get one/all collections
putCollection / patchCollectionReplace or partially update a collection
deleteCollection / duplicateCollectionDelete a collection, or duplicate it into another workspace
getDuplicateCollectionTaskStatus / getCollectionUpdatesTasksCheck the status of an async collection duplication or update task
generateCollection / generateSpecFromCollectionGenerate a collection from a spec, or a spec from a collection
getCollectionTags / updateCollectionTagsGet or update a collection's tags
createCollectionFork / getCollectionForks / getCollectionsForkedByUserFork a collection, or list its forks / the user's forks
mergeCollectionFork / pullCollectionChanges / getSourceCollectionStatusMerge a fork back, pull upstream changes, or check fork/source drift
createCollectionFolder / getCollectionFolder / updateCollectionFolder / deleteCollectionFolderCreate, read, update, or delete a folder in a collection
transferCollectionFoldersCopy or move folders into a collection or folder
createCollectionRequest / getCollectionRequest / updateCollectionRequest / deleteCollectionRequestCreate, read, update, or delete a request in a collection
transferCollectionRequestsCopy or move requests into a collection or folder
createCollectionResponse / getCollectionResponse / updateCollectionResponse / deleteCollectionResponseCreate, read, update, or delete a saved response on a request
transferCollectionResponsesCopy or move responses into a request
createCollectionComment / getCollectionComments / updateCollectionComment / deleteCollectionCommentCreate, read, update, or delete a comment on a collection
updateApiCollectionComment / deleteApiCollectionCommentUpdate or delete a comment on an API's collection
createFolderComment / getFolderComments / updateFolderComment / deleteFolderCommentCreate, read, update, or delete a comment on a folder
createRequestComment / getRequestComments / updateRequestComment / deleteRequestCommentCreate, read, update, or delete a comment on a request
createResponseComment / getResponseComments / updateResponseComment / deleteResponseCommentCreate, read, update, or delete a comment on a response
resolveCommentThread / getTaggedEntitiesResolve a comment thread, or list entities tagged in comments (Enterprise plans)
createEnvironment / getEnvironment / getEnvironmentsCreate an environment, or get one/all environments
putEnvironment / patchEnvironment / deleteEnvironmentReplace, partially update, or delete an environment
createMock / getMock / getMocks / updateMock / deleteMockCreate, read, update, or delete a mock server
publishMock / unpublishMockPublish or unpublish a mock server
createMockServerResponse / getMockServerResponse / getMockServerResponses / updateMockServerResponse / deleteMockServerResponseCreate, read, update, or delete a mock server's canned responses
createMonitor / getMonitor / getMonitors / updateMonitor / deleteMonitorCreate, read, update, or delete a monitor
runMonitor / getMonitorRunResultsRun a monitor, or get results for a specific run
listMonitorExecutions / listRunsForExecutionList a monitor's executions, or the runs within one
createSpec / getSpec / getAllSpecs / deleteSpecCreate, read, list, or delete an API specification
getSpecDefinition / getSpecCollectionsGet a spec's full definition, or the collections generated from it
createSpecFile / getSpecFile / getSpecFiles / updateSpecFile / deleteSpecFileCreate, read, update, or delete a file within an API specification
updateSpecPropertiesUpdate a spec's properties, such as its name
syncSpecWithCollection / syncCollectionWithSpec / getGeneratedCollectionSpecsSync a spec and its linked collection in either direction, or inspect the link
getAsyncSpecTaskStatus / getStatusOfAnAsyncApiTaskCheck the status of an async spec-creation or other API task
publishDocumentation / unpublishDocumentationPublish or unpublish a collection's documentation
getAnalyticsData / getAnalyticsMetadataGet analytics data for a resource, or the metric catalog for the analytics API
searchPostmanElementsSearch across requests, collections, workspaces, specs, flows, and mocks
searchLearningCenterSearch Postman's official documentation and learning resources
getPostmanContextOverview / getApiDiscoveryInstructions / getCodeGenerationInstructions / getInstalledApiMaintenanceInstructionsContext and workflow guidance for discovering, generating from, and maintaining APIs in Postman

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 scopes

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 examples

Read-only Postman for everyone

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

  1. In Access Policies, 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 only

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 – which is what 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.

Next steps

On this page