Loading WURK...
RomanMotion
RomanMotion
Product ad & launch videos · 3D product visuals · app & AI builder. Concept to final cut in days. Open for projects.

AI Extensions, November 4: check where MCP Inspector keeps secrets

Inspector 2.13.0, bounded CLI probes and the keychain-to-file fallback. A debugger needs its own access review.

Published on November 4, 20266 min read

By Jack Gross. Originally published November 4, 2026 on Jack Gross.

An MCP debugging session can launch a local server and retain the credentials used to reach a remote one. That makes the debugger part of the access boundary. Today's AI Extensions digest examines MCP Inspector's current v2 line, with special attention to where secrets go when the operating-system keychain is unavailable.

This is a November 4 documentation and code review. No package, server or exploit was executed. The official repository was inspected at its released 2.13.0 checkout. The October 28 release is recent, but it is not a release from today. Repository activity and popularity do not establish quality; the checks below concern specific behavior a developer can verify before using real credentials.

Choose the client by the work

Inspector ships web, CLI and terminal interfaces in one package. Its experimental mcpdo client supports named connections through a local daemon. The web interface is useful when a person needs to inspect a sequence interactively. The CLI provides machine-readable output and exit codes for a small automated check. An interactive UI and an unattended CI job have different storage and login requirements even when both talk to the same server.

A stdio target is a command the Inspector starts. Choosing that transport authorizes local code execution in the developer's environment. An HTTP target avoids that particular process launch, while still giving the debugger network access and potentially OAuth credentials. Neither option makes an unfamiliar server trustworthy. For a first trial, use a reviewed fixture with synthetic data and no account with production access.

The CLI smoke-testing guide separates connection, tool discovery and invocation. initialize completes the handshake without calling a tool. tools/list shows advertised tools. Calling a tool adds a further effect boundary and needs its own reviewed arguments. A passing handshake does not establish that the tool's result or permissions are correct.

Pin the package and check the runtime

The 2.13.0 release notes say npm users run Inspector on their own Node.js runtime. Updating the Inspector package does not update Node. The release advises Node 22.23.4, 24.22.1 or 26.12.1, or later, while the package's engine range still accepts older 22.x versions. Treat the release's runtime guidance and the package manager's acceptance check as separate facts.

The smoke guide contains an older 2.5.0 pin as an example of reproducibility. That example should not be copied as a current security recommendation. The published DNS-rebinding advisory lists v2.0.0 through v2.11.0 as affected and 2.12.0 as patched. Version 2.13.0 follows that fix. This does not mean every future or unrelated security issue is solved.

The original example below adapts documented flags to the inspected release. It is unrun and needs an authorized test server URL. Keep credentials out of the command and output. Confirm the runtime separately before the first line that invokes Inspector:

node --version
MCP_INSPECTOR_SECRET_STORE=memory \
  npx --yes @modelcontextprotocol/[email protected] --cli \
  --transport http --server-url https://mcp.example.test/mcp \
  --connect-timeout 10000 --method initialize --format json

The hostname is a placeholder, not a service. This probe checks connection behavior only. In CI, fail on a nonzero exit code and validate the expected response fields. Do not convert an authentication failure into a passing job by removing authentication.

The fallback can be an unencrypted file

The secret-storage guide documents a selection order. An explicit MCP_INSPECTOR_SECRET_STORE chooses keyring, file or memory. Without an explicit choice, Inspector probes the OS keychain. If that fails, a container without a mounted secrets directory uses memory; other fallback cases use a file.

On a headless host or a Linux system without a working Secret Service, that can mean ~/.mcp-inspector/secrets.json. The file is unencrypted unless a key is supplied. Mode 0600 limits access by other ordinary users. It does not protect a copied backup, root or a program running as the same user.

Inspector moves several secret types out of its configuration files, including acquired OAuth tokens, client secrets and stdio env values. There is an important exception: headers remain in mcp.json as written. A bearer credential placed in a header can therefore remain in a shareable-looking configuration file. Review the actual file before attaching it to an issue or committing it.

Choosing memory has a narrower meaning than "erase every old secret". The documentation says existing plaintext values in configuration or OAuth state files are not removed under a nondurable memory store, since those files may be the only durable copy. New or changed secrets stay in memory, but old files still need a separate review. Never assume a new environment variable retroactively cleans a home directory.

Encryption has a specific threat model

For the file store, Inspector supports a high-entropy key through MCP_INSPECTOR_SECRET_KEY_FILE, with an environment-variable alternative. Its documentation describes AES-256-GCM with scrypt-derived keys. Supplying the key file later does not instantly encrypt a pre-existing file; the next write upgrades it. The effective storage indicator matters more than the fact that a variable was set.

Encryption can help when the secrets file leaks alone and the key does not. Code running as the same user may be able to read both. A stdio server is such code. Keep the key out of the same backup or repository as the encrypted file, and do not treat encryption as a sandbox for untrusted server commands.

My proposed trial uses a throwaway profile and fake credentials. Check the startup storage warning, store a fake value, stop the process and restart. Compare the memory and file cases without printing secret values. Inspect whether configured headers persist. Then simulate a failed connection and ensure the CI wrapper preserves failure. These are proposed checks, not results reported from an installation.

Adoption notes

The LICENSE file describes a transition: new code and specification contributions use Apache-2.0, documentation contributions excluding specifications use CC-BY-4.0, and contributions without relicensing consent remain under their original MIT terms. Calling the entire checkout simply "MIT" would lose that distinction. Read the terms relevant to any material you redistribute.

Inspector fits a workflow where a developer can name the target, bound connection time and inspect the active secret store. For a shared machine or CI runner, decide the profile directory and retention policy before login. Preserve only redacted diagnostics, keep authentication enabled, and verify that the observed failure is the one your job intended to test.

Sources

Optional tools for your own projects

Advertisement / referral links. We may receive referral credit. For your next coding project, try ZCode free through this invitation. Complete the invitation onboarding steps and check current eligibility.

Check the Coding Plan referral discount. Confirm included models, eligibility and the final discount at checkout. Standard API usage is billed separately.

Conversation

Join the conversation

Share your thoughts with the author and other readers.

Comments0

Checking your account…

Latest comments

0
No comments yet. Be the first to share your thoughts.