Your agent rotated the leaked token. It never saw the new one.

Originally published on the Postman blog.

Your agent rotated the leaked token. It never saw the new one.

If you let a coding agent near your API platform, the hard question isn't whether it can do the work. It's where your secrets end up: in the model's context, the chat transcript, your shell history. This post walks through a staged leaked-credential drill. It uses a fake token in a dedicated test workspace, run end to end by a coding agent with the Postman plugin. The interesting part is which tool the agent reaches for at each step, the Postman CLI or the Postman MCP server, and how the new secret stays out of its hands.

Heads up: Secret Scanner and audit logs need a Postman Enterprise plan. Scanning internal workspaces also needs the Advanced Security Administration add-on, and audit logs need an Admin or Super Admin role.

How the Postman plugin picks a door

The plugin sends your agent's requests to the Postman CLI whenever the CLI can complete them. It falls back to the Postman MCP server only for tasks the CLI can't run or doesn't support yet. In practice that means two cases:

• The CLI can't run. For example, a hosted or mobile session that can't install binaries.
• The CLI runs but has no command for the task yet. In the versions tested, that covered Secret Scanner, audit logs and collection roles, which all went through the MCP server.

Install it into the coding agents it detects on your machine:

npx @postman/postman-plugin install

The install docs list the supported agents and their minimum versions. The plugin also registers the hosted Postman MCP server (its /mcp path selects the Full tool set). In Claude Code you authorize it once with OAuth via the /mcp slash command.

The alert, from a phone

The Secret Scanner alert arrived when only a phone was in reach: no laptop, no terminal, just the Claude mobile app with the Postman MCP server added as a custom connector. With no CLI available, this round went through MCP.

Prompt:

Secret Scanner flagged a token in the devrel-blog-mcp-test workspace. Where does it appear, and who put it there?

The agent chained three MCP tools:

1. detectedSecretsQueries to list the active findings in the workspace
2. getDetectedSecretsLocations to turn each finding into a location
3. getTeamUser to turn the leakedBy user ID into a name

It reported two findings for the same leak: the Authorization header of a saved request, matched once on the Bearer prefix and once on the JSON Web Token format. It also named the teammate who saved the request (the author, as expected in a staged drill). Each location comes back as a short record:

{
  "resourceType": "request",
  "location": "Headers",
  "occurrences": 1,
  "leakedBy": 12345678,
  "detectedAt": "2026-10-21T16:27:31.000Z",
  "isResourceDeleted": false
}

Neither finding carries the secret in full, only an obfuscated preview and a hash. That matters when the conversation runs through a model provider you don't control.

The blast radius, from the terminal

Back at a laptop, in Claude Code inside the project folder linked to the workspace, the plugin found the Postman CLI and used it.

Prompt:

Before we rotate the patients-service token, what depends on patients-service and how does each consumer authenticate to it?

The agent asked Postman Context Graph through the CLI:

postman context-graph ask "What depends on patients-service, and how does each consumer authenticate to it?" --wait

In this demo, patients-service comes from a simulated healthcare app the DevRel team ingests into its Context Graph. The graph listed 32 downstream consumers, a figure from that one demo, not a typical number. It also narrowed things down: the leaked token carries the patients.read scope, and erp-bridge-service is the one consumer that authenticates with that exact scope. That's the service whose configuration has to change in the same window as the rotation.

Context Graph needs a team with ingested sources, and each ask counts against your team's quota. One precise question beats five vague ones.

The rotation, with one prompt

The new token was issued on the service side by a human. It was never pasted into the chat, a file or an environment variable. Everything else went to the agent in one prompt:

I've issued a new patients-service token. Remove the hard-coded header from the Patients Service collection, store the new token as a vault secret for the Patients Service – shared environment (I'll enter the value myself), prove the request works, and make the collection read-only for the team while we clean up. Don't close the Secret Scanner findings until I confirm the old token is revoked.

The plugin's skills turned that into six steps and picked a door for each one. I never told the agent which tool to use.

• Remove the hard-coded header: MCP server, because the collection lived only in the cloud workspace.
• Create the vault secret, link the variable, run the request: Postman CLI, because it has those commands and a shell was available.
• Set collection roles: MCP server, because the CLI has no command for roles.

For the secret, the agent ran postman secret create. That opened a one-time form in the browser with a match code, so the human could confirm the form came from this command, and the human pasted the token there.

This is the part worth copying into any rotation. The token went from the clipboard into Postman Shared Vault without passing through the agent's context, the chat transcript, the shell history or a plain-text environment value. Secret Scanner checks the shared values of variables, so a plain value would have risked a fresh alert. With the vault reference, no new alert fired.

The collection's own test checked what actually went out (Postman Echo stood in for the service):

pm.test("request carried the rotated token", () => {
  const sent = pm.response.json().headers.authorization;
  pm.expect(sent).to.eql(`Bearer ${pm.environment.get("patients_service_token")}`);
});

Close the alert, with a human in the loop

Revoking the old token happened on the service side, not in the agent. Only after the human confirmed it did the agent mark both findings Revoked. One call timed out, so the agent read the findings back before retrying instead of writing twice.

The paper trail

Show me the audit trail for this incident.

The revoke entries in the audit log carry this user agent:

postman-claude-code-plugin/2.0.1/postman-api-mcp-server/1.8.0 (toolset: full)

The log records that the findings were closed through the Postman plugin, via the MCP server, with the Full tool set. When someone asks in six weeks who closed the alert and how, the answer is in the log. Audit logs need an Admin or Super Admin role: the agent can only see what your account can see.

Stage your own drill

1. Install the plugin: npx @postman/postman-plugin install
2. Create a team-visible (not public) test workspace. Public workspaces auto-replace detected secrets, which spoils the exercise.
3. Tell your team admins first, since detections email them.
4. Paste a sample token into a saved request header, wait for the alert and hand the incident to your agent.
5. Watch which door it picks at each step.

The full walkthrough, with the agent's complete answers and the resources list, is on the Postman blog.