How to audit MCP servers on developer laptops: config files, secrets, risk rating and clean-up

Every local MCP server on a developer laptop is a program that an AI client starts with the developer's own permissions, often fetched from a package registry at launch and handed API tokens in plain text, and most security teams cannot say how many there are. This guide is a hands-on audit of MCP servers on developer machines: where each common client keeps its configuration on macOS, Windows and Linux, which fields to collect, how to spot secrets and risky launch commands, how to rate what you find, and how to remove or replace servers without breaking a developer's workflow. It is for endpoint, application security and platform teams, and for developers checking their own machine. The principles behind the controls are in the Local MCP Server Security Guide; this page is the procedure.

Key takeaways

• Configuration files are the inventory: local servers are declared in JSON files with a command, args and env per server, in known paths per client and per repository. Collect those files and you have most of the picture.
• Scope matters as much as the server: Claude Code alone has local, project and user scopes, with project servers in a committed .mcp.json. A server in a repository reaches every developer who clones it.
• Look for secrets in env and headers: client documentation shows API keys passed in the env block. Record variable names, never values, and replace literals with references.
• Rate by what the launch command does: the MCP specification lists malicious startup commands, malicious packages and DNS rebinding of local servers as the main local attacks. Unpinned package runners, shell chains and listeners on localhost rate highest.
• Remove through the client, then enforce centrally: back up the file, remove the entry, confirm the client no longer starts it, then use managed allowlists and denylists where the client supports them so the server does not come back.

When you need this

• First visibility: before you can approve or block anything, you need to know what is installed. The audit feeds the MCP Server Inventory Template.
• After a malicious server or package report: when a server such as the one in the postmark-mcp malicious MCP server case is reported, you must find every laptop that has it configured within hours.
• Repository review: committed MCP configuration is code that runs on every developer's machine. The Amazon Q MCP config vulnerability showed how opening a malicious repository could put a developer's AWS credentials at risk.
• Developer offboarding or incident response: MCP configuration holds tokens that outlive the person. See the Compromised Developer Workstation Playbook.

Before you start

• Agree the rules with developers: the audit reads files in home directories and repositories. Publish what is collected (server names, commands, arguments, environment variable names) and what is not (values, source code).
• Collection channel: an MDM or EDR script that reads files and returns parsed fields, or a self-service script developers run. Do not copy whole configuration files to a central share: they contain tokens.
• Scope: managed laptops on macOS, Windows and Linux, development virtual machines, and dev containers. Unmanaged personal devices are out of reach of this method; note them as a gap.
• An approved list, even a short one: you will rate findings against it. The MCP Server Trust Assessment covers how servers get onto it.

Step-by-step

1. Know where each client keeps its servers

Two gaps to remember. Cursor documents an extension API (vscode.cursor.mcp.registerServer()) that registers servers at runtime without editing mcp.json, so file collection misses those; process telemetry (step 5) catches them. And file paths move between client versions, so recheck the vendor documentation each quarter.

2. Collect the fields (read-only)

1. Search each user profile for the files in step 1, and search code directories for project files (.mcp.json, .vscode/mcp.json, .cursor/mcp.json, .amazonq/mcp.json).
2. Parse each file as JSON and, for every server entry, record: device, user, file path, scope, server name, transport (command for local stdio servers, url or type for HTTP servers), command, full args, the names of env and headers keys, and the file's modification time.
3. Replace every value in env and headers with a classification before it leaves the device: literal (a value written in the file), reference (for example ${API_KEY}, which Claude Code expands from the environment), or empty. Never ship the value.
4. For a developer auditing their own machine, the client can list what it loads: claude mcp list shows every configured server with a health status such as Connected or Pending approval, and claude mcp get <name> shows one server's details.
5. Pull the same fields from repositories centrally with code search on the project file names. A committed file is one finding that affects every clone.

3. Resolve what actually loads

The same server name can appear in several scopes. Claude Code documents that it uses the highest-precedence entry in full without merging fields: local, then project, then user, then plugin-provided servers, then claude.ai connectors. A harmless user-scope entry can therefore be overridden by a project file in a repository. Record the effective entry per project, not only the list of files.

Also record approval state. Claude Code prompts before using project-scoped servers in interactive sessions, but documents that in claude -p runs and Agent SDK sessions the prompt cannot be shown and project servers load without asking. Scripts and CI jobs that run a coding agent in a cloned repository are therefore the highest-risk place for a committed .mcp.json.

4. Rate each server

5. Confirm with process and network telemetry

• Process lineage: in EDR, find child processes of AI desktop apps and IDEs that are package runners (npx, uvx), interpreters (node, python) or docker. Compare with the file inventory; anything running without a matching entry was registered another way.
• Sensitive file access: alert when a process started by an MCP client reads ~/.ssh, ~/.aws or browser profile paths. The MCP specification's own example exfiltrates ~/.ssh/id_rsa.
• Listeners: list processes listening on loopback ports whose parent is an AI client or IDE. These are the HTTP local servers to check for tokens.
• Client logs: Claude Desktop writes mcp.log and per-server mcp-server-SERVERNAME.log files (in ~/Library/Logs/Claude on macOS, %APPDATA%\Claude\logs on Windows, ~/.config/Claude/logs on Linux). They show which servers connected and when.

The Unsanctioned AI Agents and MCP Servers Guide covers the wider discovery sources (identity provider, CASB, billing) that find remote servers and agents this laptop audit does not.

6. Remediate with the developer (change-controlled)

1. Critical findings first: treat the device as possibly compromised. Isolate through EDR, preserve the configuration file and client logs, and follow the MCP Incident Response Playbook.
2. Rotate exposed secrets: any credential found as a literal in a configuration file is rotated at the issuing service, not only removed from the file. Replace it with a reference to an environment variable or the client's secret input mechanism, using a token scoped to what the server needs.
3. Back up, then remove: copy the configuration file, then remove the entry with the client (claude mcp remove <name> for Claude Code) or by editing the file. Restart the client and confirm the server no longer appears in its list and no child process starts.
4. Fix rather than remove where the server is needed: pin the package version (or a container image digest), narrow filesystem arguments to the project directory, and move HTTP local servers to stdio or add a token.
5. Repository files: raise a pull request removing or correcting the committed .mcp.json, and add a code owner rule so future changes need security review. For headless agent runs, Claude Code documents disabledMcpjsonServers and the --strict-mcp-config flag to keep project servers out.
6. Enforce centrally: where the client supports managed settings, deploy them. Claude Code documents managed MCP configuration (managed-mcp.json, managedMcpServers) and allowedMcpServers and deniedMcpServers entries matched by serverName or serverUrl. For GitHub Copilot, VS Code points to the enterprise allowlist policy in GitHub's documentation.

Rollback: restore the backed-up file and restart the client. Keep backups on the device for one review cycle. If a denylist entry blocks a server the business needs, remove that entry in the managed settings and redeploy, rather than letting developers edit around it.

Decision guidance

Verify it worked

The targets below are NHI Mgmt Group recommendations, not vendor or regulatory requirements.

Common failure patterns

• Collecting values: shipping whole configuration files to a central store creates a new collection of developer tokens. Parse on the device and send names only.
• Checking one client: developers often run two or three AI clients, each with its own files and scopes.
• Ignoring repositories: a single committed project file reaches every clone and every headless agent run.
• Removing the entry but not the credential: a token that sat in plain text in a home directory must be rotated.
• Trusting approval prompts: prompts do not appear in headless runs, and approved servers can change behaviour when an unpinned package updates.
• Auditing once: new servers appear weekly. Repeat the collection on a schedule and diff the results.

Where identity fits

Each local MCP server acts with two identities: the developer's operating system account, which decides what files and processes it can reach, and whatever tokens it is given in env or headers, which decide what it can do in SaaS and cloud services. Both are non-human use of credentials with no separate owner. Scope tokens to the server's task, issue them per server rather than reusing a developer's personal token, and record them in your non-human identity inventory. See the MCP Security Guide for the wider model.

Framework mapping

Practitioner checklist

• List the configuration paths for every AI client your developers use, per operating system.
• Collect server name, scope, command, arguments and secret key names on the device, never values.
• Search repositories for committed project MCP files and resolve which entry actually loads.
• Rate each server on its launch command, pinning, package source, secrets, arguments and transport.
• Confirm with EDR process lineage, loopback listeners and client logs.
• Rotate any literal secret found, then back up and remove or fix the entry with the developer.
• Disable project servers in headless agent runs and deploy managed allowlists where supported.
• Repeat monthly and diff the results against the approved register.

Standards and references

• Model Context Protocol: Security Best Practices
• Model Context Protocol: Connect to local MCP servers
• Anthropic: Connect Claude Code to tools via MCP
• Visual Studio Code: Add and manage MCP servers
• Cursor: Model Context Protocol
• NIST: SP 800-53 Rev. 5 Security and Privacy Controls

Related NHI Mgmt Group resources: MCP Server Security Checklist, Top 10 MCP Security Risks, MCP Gateway and MCP Server Governance Guide, Sentry MCP Agentjacking 2026.