Your API Client Is a Credential Vault: Audit It

A developer opens an HTTP client on their Mac. Nothing else. No clicks, no consent dialogs, no "enable AI features" checkbox. The next day, their coding agent is failing to authenticate against a remote MCP server they never configured, routing API work through skills they never installed, and carrying a cryptographically trusted startup hook they never approved. That's not a hypothetical — it's what the evidence in a recent, meticulously documented bug report shows Postman's desktop app doing: auto-installing plugins into Codex and Claude Code, writing to global agent configs, and attempting to mark its own session hook as trusted. If you care about API client security, this is the incident that should change how you treat every desktop dev tool on your machine.

What the Postman Desktop App Actually Did

Strip away the outrage and look at the forensics, because the reporter did the work most of us never do. Postman's own log file recorded an auto-existing-upgrade event: on an existing, signed-in desktop installation, a script ran and reported claude-code:installed,codex:installed. No prompt. The user's global Codex configuration gained a new marketplace pointing at a Postman git repo, an enabled plugin, and a hook trust record. Claude Code's settings gained an enabled plugin and install records with timestamps matching the same window. A Postman CLI binary appeared in ~/.local/bin. And a remote MCP connection was pointed at Postman's servers — one that then failed authentication and spammed errors, which is the only reason the user noticed any of it.

Two details deserve to be read twice. First, the installed session-start hook instructs the agent that before responding to any non-trivial API engineering task — designing, testing, mocking, documenting, deploying — it should load Postman's skill. That isn't integration on request; it's one application rewriting the default behavior of a different vendor's application. Second, the installer's source contains code that explicitly fetches the hook's hash and upserts it into the agent's trusted-hook state. The trust mechanism exists so the user approves hooks. Having the installer approve its own hook is the software equivalent of signing your own permission slip.

The reporter was careful — they explicitly note the trust record alone doesn't prove who created it, and they make no exfiltration claims. That restraint makes the report more credible, not less. What it proves is enough: silent modification of unrelated tools, a broad behavioral instruction injected into an agent's session startup, and an attempted end-run around a user-consent control. In any security review I've run, that combination gets a product pulled from the fleet pending investigation.

Why Your API Client Is a Credential Vault

Here's the part teams consistently underweight. An API client isn't a text editor with a send button. It's where your bearer tokens, session cookies, mTLS client certificates, OAuth client secrets, and signed request headers live. Environment variables holding database URLs and third-party keys get pasted into it. If you use templating syntax like {{api_secret}}, the resolved value flows through the app on every request — and depending on the vendor's telemetry design, potentially through their logging pipeline too. One practitioner investigating HIPAA compliance reported finding exactly that: resolved secret values in outbound logging traffic, with the app degrading when that endpoint was blocked. I can't independently verify every detail, but it matches the architectural pattern I've seen in other "helpful" desktop tools: full-fidelity request logging shipped as a feature.

Now add the agent angle. When a tool installs a plugin into your coding agent and registers a session hook, it gets its instructions into the context of a process that can read your codebase, execute shell commands, and hold its own set of credentials. The blast radius is no longer "my API collections leak" — it's "every secret reachable from my agent's environment is one bad prompt or one compromised skill away from the wrong endpoint." We've written before about how CLI tools that install background daemons quietly expand their own attack surface; this is the same pattern with a smarter payload. A daemon you can see in ps is almost polite compared to an instruction hook living inside another vendor's trust store.

Treat the threat model honestly and the conclusion is uncomfortable: a desktop API client sits at the intersection of secrets, network access, and — increasingly — agent control planes. It deserves the same scrutiny you'd give a password manager or a CI runner. Almost nobody gives it that scrutiny. That's the gap this incident exploits, and it's why the response has to be procedural, not just emotional.

Why Vendor Opt-Outs and Settings Toggles Fail

The first instinct after an incident like this is to go hunting through the app's preferences for a telemetry toggle, flip it, and move on. I've watched entire teams do this and call it remediation. It's theater, for three reasons.

• Consent can be version-gated. The Postman install was triggered by a feature flag on an existing signed-in account. The toggle that exists today doesn't tell you which flags ship tomorrow, and auto-updaters mean tomorrow arrives without asking.
• Toggles govern what's documented, not what's possible. A privacy setting controls the code paths the vendor chose to expose. The plugin installer wasn't a documented preference — it was a scripted upgrade path. You can't opt out of a switch you can't see.
• Trust decisions get made outside the app. The hook-approval attempt happened inside Codex's configuration, not Postman's. Even a perfectly behaved settings panel in the source app wouldn't have surfaced it.

The deeper failure is structural: opt-outs put the burden of vigilance on the party with the least information. The vendor knows what the updater can do; you don't. The vendor knows which endpoints the app phones home to; you're guessing. Any control that requires the less-informed party to continuously out-research the more-informed party will eventually fail. This is the same reason the trust problems in IDE plugin marketplaces keep biting people — the security boundary you think you're managing isn't the one being crossed.

Vendor trust isn't worthless — it just can't be the control. It's a factor in deciding what to install, not a mechanism for keeping installed software honest. Once you internalize that, the audit strategy writes itself: verify behavior from the outside, continuously, with tools the vendor doesn't control.

Why One-Time Security Audits Fail Too

The second failed attempt is more respectable: the point-in-time audit. Security team reviews the tool, checks its network calls, reads the privacy policy, issues an approval, files the report. Done — until the auto-updater runs. Desktop dev tools ship on weekly or even daily cadences now, and feature flags mean two users on the same version number can run materially different code. The behavior in this incident was gated behind a server-side flag and an "existing user" condition, which means a clean-room install reviewed by your security team could look spotless while your long-time users get the plugin drop.

I've been burned by this exact gap. Years ago I approved a sync client after a thorough review — clean traffic capture, sane permissions, no persistence mechanisms. Six months later an update added a LaunchAgent and a socket listener. We found it only because a laptop with a flaky VPN kept showing weird connection retries in a firewall log. Nobody had re-reviewed anything, because nobody's process said to. The approval was a snapshot; the software was a movie.

So both cheap fixes fail: trusting the vendor's settings fails because the interesting behavior isn't in the settings, and one-time audits fail because the interesting behavior ships after the audit. What works is treating your own machine's state as the source of truth and watching it change. That's less glamorous than a procurement review, but it catches reality instead of intentions.

How to Audit Desktop Developer Tools for Real

The working approach has three legs: snapshot the state that matters, watch the wire, and contain what you can't fully verify. None of these require enterprise tooling. They require discipline and about an hour of setup.

Detect Silent Plugin Installs With Config Snapshots

Every coding agent and dev tool on your machine has a small set of files that define its behavior: ~/.codex/config.toml, ~/.claude/settings.json and the plugins directory, MCP configs, shell rc files, ~/Library/LaunchAgents, ~/.local/bin. These files are the consent boundary. Anything that modifies them without asking is the thing you're trying to catch. So hash them daily and diff:

#!/usr/bin/env bash
# snapshot-agent-configs.sh — hash every file your agents and shells read,
# then diff against yesterday. Run from cron or launchd.
set -euo pipefail
SNAP_DIR="$HOME/.config-audit"
mkdir -p "$SNAP_DIR"
TODAY="$SNAP_DIR/$(date +%F).txt"
find \
"$HOME/.codex" \
"$HOME/.claude" \
"$HOME/.config" \
"$HOME/.local/bin" \
"$HOME/Library/LaunchAgents" \
-type f 2>/dev/null \
| sort \
| xargs shasum -a 256 > "$TODAY"
PREV=$(ls -t "$SNAP_DIR"/*.txt 2>/dev/null | sed -n '2p' || true)
if [ -n "${PREV:-}" ]; then
if ! diff -u "$PREV" "$TODAY" > "$SNAP_DIR/latest.diff"; then
echo "config drift detected — see $SNAP_DIR/latest.diff" \
| mail -s "agent config drift" you@example.com || \
cat "$SNAP_DIR/latest.diff"
fi
fi

This is crude and that's fine. Had this been running on the reporter's machine, the Codex config.toml change, the new Claude plugin records, and the CLI binary in ~/.local/bin would all have lit up in a single diff the morning after. The signal-to-noise ratio is excellent because these directories are otherwise quiet — your own edits are the only legitimate changes, and you know when you made them. Pair it with launchctl list | grep -v com.apple output in the same snapshot and you'll also catch persistence mechanisms the day they appear.

Watch Network Egress, Not Just Files

File integrity tells you what changed on disk; it won't tell you what left the building. For egress, you want per-application visibility. On macOS, Little Snitch or the open-source LuLu firewall will both alert on new outbound connections per process — the first time Postman's updater or a fresh CLI binary reaches for an unfamiliar host, you get a prompt instead of a fait accompli. On Linux, opensnitch does the same job. If you just want a manual spot-check of what a chatty app is doing right now:

# Every established outbound connection, grouped by process
sudo lsof -iTCP -sTCP:ESTABLISHED -P -n | awk '{print $1, $9}' | sort | uniq -c | sort -rn
# Watch one vendor's traffic live (find the process name first)
sudo tcpdump -i any -n host mcp.postman.com

Two things to look for: destinations that have nothing to do with the tool's stated function, and connections that persist when the app is idle. An HTTP client should be quiet when you're not clicking send. Telemetry endpoints themselves aren't automatically damning — but as the earlier HIPAA investigation story shows, what matters is the payload. If your client resolves {{secrets}} client-side and logs full request detail server-side, "anonymous usage data" isn't anonymous. The only way to know is to capture and read, ideally during a session where you've deliberately loaded a canary token — a unique fake credential — into an environment variable and watched whether it transits anywhere it shouldn't. Canary tokens turn "we think they might" into "we know they did."

Contain What You Can't Fully Trust

The final leg accepts that you won't catch everything. So limit the blast radius. Run credential-heavy tools in a dedicated OS user account or a lightweight VM so their filesystem reach stops at the sandbox edge — macOS and Linux both make a second user cheap, and tools like firejail on Linux can deny whole directory trees per application. Keep real production secrets out of desktop tools entirely: use short-lived tokens, scoped service accounts, and request signing that expires. If a tool demands a long-lived production credential to be useful, that demand is itself a finding. We've argued before that containment beats monitoring when the cost of a miss is high — for agents and for the tools that configure them, containment is the layer that still works on the day your monitoring has a blind spot.

A Rollback Playbook for Tooling Incidents

When you do catch something, deletion of the offending app is step one of about six. The Postman reporter's removal checklist is the right shape, and it's worth internalizing before you need it:

1. Preserve evidence first. Copy logs, configs, and version numbers somewhere safe before uninstalling. Postman's own main.log was the smoking gun here — uninstall scripts love to delete it.
2. Remove the app and its helpers. The app bundle, plus anything it dropped in ~/.local/bin, Application Support, and caches.
3. Scrub the agent configs. Remove marketplace entries, enabled-plugin stanzas, MCP server definitions, and cached plugin directories from every agent host, not just the obvious one.
4. Revoke trust records. Delete any trusted_hash entries for hooks you didn't approve. Then audit other hooks in the same file — if one got smuggled in, check the rest.
5. Check persistence. LaunchAgents, LaunchDaemons, login items, cron entries, shell rc additions.
6. Rotate what flowed through it. Any credential that lived in the tool's environments or collections should be treated as exposed. Rotation is annoying; incident response is worse.
7. Verify removal sticks. Keep your snapshot script running for a few weeks. Reinstall-under-a-different-flag is a known pattern.

Notice what's not on the list: filing a ticket and waiting. Do that too — public, well-evidenced reports are how the rest of us find out — but your own hygiene can't depend on the vendor's roadmap.

The Bigger Lesson on Developer Tool Security

There's a temptation to make this story purely about one company's trajectory — a beloved lightweight tool that raised hundreds of millions in funding, hired a small army, and now has to justify a multi-billion-dollar valuation with logins, subscriptions, and AI everything. That narrative is satisfying and mostly true, but it lets the rest of us off too easily. The same incentive structure now sits underneath half the tools on your machine. Every vendor with an AI story to tell wants their plugin in your agent, their MCP server in your config, their hook in your session start. Some will ask. The evidence says at least one decided asking was optional.

The market response is already visible, and it's instructive: offline-first, git-native API clients like Bruno, Kreya, and Yaak are having a moment precisely because their trust model is legible. Files in your repo, requests from your machine, no account required. When a tool's storage format is a folder of text files, auditing it is git diff. That's not nostalgia — it's a security architecture. The LiteLLM supply-chain incident taught the same lesson from the package-registry side: the artifacts you can inspect and pin are the ones you can defend.

Consent that lives in a feature flag isn't consent. If a tool can change what it does without changing its version number, your approval of the tool means nothing.

So here's the position I'll defend: stop evaluating desktop dev tools on features and start evaluating them on reversibility. Can I see everything it writes? Can I diff its config? Can I run it without an account, offline, behind a firewall that logs? Can I remove it completely, including whatever it touched outside its own directory? The tools that survive those questions tend to be boring, and boring is exactly what you want standing between your credentials and the network. The ones that fail — no matter how good the autocomplete is — belong in a sandbox or off the machine. Your API client is a credential vault. Start treating it like one, because the vendors clearly already do — just not in the way you'd hope.