You gave your AI assistant tools. Maybe file access. Maybe email. Maybe a calendar. Maybe a shell through a local MCP server you installed because the README looked normal and the command worked.

That is not automatically reckless. It is also not something to leave unexamined.

This is a home-user audit. The goal is not enterprise governance. The goal is knowing what runs on your own workstation, under your own account, before a convenient tool becomes a quiet exposure path.

TL;DR

  • MCP servers and agent tools run with real user permissions, often on your own machine.
  • Your first audit should be manual: find the config, list every server, read the command, check paths, check tokens, and remove anything you do not recognize.
  • Scanners such as Snyk Agent Scan help, but they are not a substitute for understanding what will execute.
  • The postmark-mcp incident showed the practical risk: a legitimate-looking npm package added a hidden BCC and exposed email traffic.
  • The home-user goal is simple: narrow permissions, avoid surprise downloads, separate sensitive accounts, and make unexpected tool changes visible.

The Real Risk Is Not “AI”

The risk is local execution under your identity.

MCP, short for Model Context Protocol, is an open standard that lets AI applications connect to external tools and data sources. In practice, that means your assistant can stop being just a chat window and start reading files, sending email, querying databases, changing tickets, launching browser actions, or running local commands.

That can be useful. It can also turn a casual install into a quiet trust boundary change.

The uncomfortable part is that many MCP servers are installed like developer conveniences:

Terminal window
npx -y some-mcp-server
uvx some-mcp-server

That command may fetch code at runtime. The server may receive environment variables. The assistant may see tool descriptions you never read. The server may expose file paths wider than you intended. None of this requires a dramatic exploit. It only requires a tool that does more than you thought it did.

A Quick Reality Check: postmark-mcp

In September 2025, Koi Security reported what it described as the first malicious MCP server found in the wild: a rogue npm package named postmark-mcp.

The package looked legitimate because it copied the official Postmark MCP project closely enough to be convincing. It was uploaded to npm on September 15, 2025. Version 1.0.15 appeared benign. Version 1.0.16, released on September 17, added the part that mattered: a hidden BCC address on outbound email.

The result was not fancy malware. It was worse in a boring way. The package sat inside agent workflows that were already trusted to send email. Researchers reported that it silently copied between 3,000 and 15,000 corporate emails per day to an attacker-controlled address. The npm package had 1,643 downloads before removal.

That is the lesson. Popularity is not a security boundary. A tool that was fine yesterday can change tomorrow. A local automation helper can become a data pipeline.

Step 1: Find The Config

Start with the boring file. Do not start with a scanner. Open the configuration and read what your assistant is allowed to launch.

Common locations:

ClientWhere to look
Claude Code~/.claude.json for user/local scope, .mcp.json for project scope
Claude Desktop macOS~/Library/Application Support/Claude/claude_desktop_config.json
Claude Desktop Windows%APPDATA%\Claude\claude_desktop_config.json
CursorCursor Settings -> MCP, and project .cursor/mcp.json when configured per project
Codex~/.codex/config.toml, plus .codex/config.toml in trusted projects

JSON-based configs usually contain an mcpServers object. Codex uses TOML, so look for mcp_servers entries.

For each server, write down five things:

QuestionWhy it matters
What command runs?npx, uvx, shell wrappers, and remote scripts deserve extra attention.
What package or binary is it?Similar names and abandoned packages are common supply-chain risk.
What paths can it access?~/notes is a decision. ~ is a much larger decision.
What secrets does it receive?Environment variables can include API keys, tokens, and account credentials.
What external services can it reach?Email, calendar, cloud storage, issue trackers, and browsers raise the blast radius.

If you cannot explain why a server exists, disable it. If you cannot explain what command it runs, do not approve it.

Step 2: Classify Each Server

Do not treat all MCP servers as equal. A weather lookup tool and an email-sending tool do not deserve the same level of trust.

Use this rough home-user risk model:

CategoryExamplesDefault decision
LowRead-only docs, local notes, limited project searchKeep if scoped narrowly.
MediumCalendar, browser automation, GitHub issues, project file writesKeep only if you use it often and understand the scope.
HighEmail, password vaults, cloud storage, shell execution, broad filesystem accessAvoid by default, or isolate to a dedicated account and narrow paths.
UnknownNew package, no clear maintainer, runtime download, vague tool namesRemove until proven useful and explainable.

This is not about paranoia. It is about matching trust to capability.

An Obsidian server reading one vault may be reasonable. A random helper server with access to your entire home directory is not the same thing. A Gmail integration on your primary account is not the same thing as a read-only calendar test account.

Step 3: Inspect The Install Path

The command is often more important than the tool name.

Look for patterns like these:

{
  "mcpServers": {
    "example": {
      "command": "npx",
      "args": ["-y", "some-mcp-package"]
    }
  }
}

This may be convenient, but it means runtime package resolution is part of your trust model. Check the package source before leaving it in place.

For npm-based servers:

Terminal window
npm view some-mcp-package name version repository dist-tags maintainers
npm view some-mcp-package scripts

For Python or uv-based servers:

Terminal window
uvx --from some-package some-command --help

Then check the repository. You are not trying to become the maintainer. You are answering basic questions:

  • Is the package linked to the project you expected?
  • Does the repository belong to the vendor or a random user?
  • Are there recent suspicious ownership or maintainer changes?
  • Does installation run postinstall or other lifecycle scripts?
  • Does the server request broader filesystem paths than the feature needs?

If the answer is “I do not know”, reduce the scope or remove the server.

Step 4: Narrow The Blast Radius

Most home users do not need perfect isolation. They need fewer catastrophic defaults.

Start with these changes:

  • Replace ~ with a specific folder such as ~/projects/myapp or ~/Documents/AI-share.
  • Use a dedicated email or calendar account for AI automation instead of your primary account.
  • Prefer read-only OAuth scopes where the service supports them.
  • Remove tokens from configs when the tool can use a local credential helper or scoped token.
  • Avoid shell-execution servers unless you genuinely need them.
  • Keep project-scoped MCP configs out of public repos when they contain private paths, tokens, or internal service names.

Filesystem scope is the easiest win. If a server only needs your notes vault, give it the notes vault. If it only needs one project, give it one project. “It works with my whole home directory” is not a feature. It is usually a missing decision.

Step 5: Scan, But Read The Prompt

Snyk Agent Scan is useful because it can discover local agent components and scan MCP servers, tools, prompts, resources, and skills for risky patterns such as prompt injection, tool poisoning, tool shadowing, toxic flows, hardcoded secrets, and suspicious skill content.

The important caveat: scanning stdio MCP configurations executes the commands defined in those configs so the scanner can retrieve tool descriptions. Snyk Agent Scan prompts for consent during interactive runs. Read that consent prompt. If it wants to run a command you do not recognize, decline it.

To run a scan:

Terminal window
set -gx SNYK_TOKEN your-api-token-here
uvx snyk-agent-scan@latest

To scan a specific project MCP config:

Terminal window
uvx snyk-agent-scan@latest .mcp.json

Useful findings to understand:

CodeMeaningPractical response
W001Suspicious words in a tool descriptionInvestigate. This is weak alone, stronger with odd tool behavior.
W018Workspace data exposureExpected for file-reading tools, but check whether the path is too broad.
W020Local destructive capabilityExpected for write tools, but check whether it can modify important files.
E001Prompt injection in a tool descriptionDisable the server until you understand it.
E002Cross-server tool referenceInvestigate. One server may be trying to influence another server’s tools.

For Codex, verify the scan output actually found your Codex mcp_servers entries. Codex uses TOML, and Snyk’s current supported-agent table lists Codex skills, but not Codex MCP auto-discovery. If the scanner misses your Codex MCP servers, convert the relevant mcp_servers entries into a temporary MCP JSON file and scan that file directly.

For example, this Codex TOML shape:

[mcp_servers.example]
command = "npx"
args = ["-y", "some-mcp-package"]

becomes:

{
  "mcpServers": {
    "example": {
      "command": "npx",
      "args": ["-y", "some-mcp-package"]
    }
  }
}

Then scan the generated file:

Terminal window
uvx snyk-agent-scan@latest /tmp/codex-mcp.json

Do not commit the generated JSON if it contains private paths, tokens, or internal service names. Treat it as a temporary audit artifact.

Step 6: Keep A Tiny Inventory

You do not need enterprise asset management for a personal workstation. A text file is enough.

Create something like:

AI tool inventory


name: obsidian
client: Claude Code
command: npx -y obsidian-mcp
scope: ~/notes/security-lab
secrets: none
decision: keep
last checked: 2026-06-13


name: gmail-helper
client: Cursor
command: npx -y gmail-mcp-example
scope: primary Gmail
secrets: OAuth
decision: remove, too much blast radius
last checked: 2026-06-13

The point is not documentation for its own sake. The point is remembering what you trusted after the install screen is gone.

Review it when:

  • you add a new MCP server,
  • a package updates,
  • your assistant gains a new tool,
  • an integration starts asking for broader permissions,
  • a scanner finding changes,
  • or you cannot remember why something exists.

What To Remove First

If you only have ten minutes, remove or disable these first:

  1. Servers you do not recognize.
  2. Servers using broad filesystem access such as ~, /, or your entire cloud-sync folder.
  3. Email or cloud-storage tools attached to your primary account.
  4. Tools launched through runtime downloads where you have not checked the package source.
  5. Shell-execution tools with vague names like helper, utility, or automation.
  6. Project MCP configs copied from someone else’s repository without review.

After that, narrow what remains.

The best MCP setup is not the one with the most tools. It is the one where every tool has a reason to exist, a narrow scope, and a failure mode you can live with.

Sources