Claude Code's MCP client happily connects to anything that speaks the protocol. That convenience is the problem. A developer who installs a popular community MCP server for Jira, Postgres, or GitHub is effectively inviting arbitrary code into the same process context as their editor, with access to the same credentials, same shell, same repo. Most teams treat this the way they treated npm in 2014: install first, review never.
This post is a working checklist for teams that have Claude Code deployed across engineering and need an MCP posture that doesn't collapse the first time someone pastes claude mcp add from a blog post.
What is the actual trust boundary for an MCP server?
There isn't one, by default. When Claude Code launches a stdio MCP server, it spawns a child process with the user's environment, the user's filesystem permissions, and often the user's credentials forwarded via env vars. The MCP spec draws a protocol boundary between client and server, but the OS draws no boundary at all. A malicious or compromised server can read ~/.aws/credentials, exfiltrate .env.local, or rewrite files in any repo the developer has open.
Teams that deploy Claude Code at scale should treat every MCP server as equivalent to a VS Code extension with unrestricted host access. That framing changes the approval process. You would not let engineers install random VS Code extensions that ship compiled binaries; you should not let them install random MCP servers that ship Python or Node packages either. The trust boundary has to be imposed externally: sandboxing, allowlists, or review gates. None of these are default.
How should we handle stdio vs HTTP transport?
Prefer HTTP with scoped tokens for anything that talks to production systems, and keep stdio for local-only tools. The stdio transport is convenient because Claude Code handles process lifecycle, but it inherits the full user environment. An HTTP MCP server running in a separate container or behind an internal gateway gives you a real network boundary, the ability to audit requests, and the option to revoke credentials without killing the developer's shell.
For HTTP deployments, the pattern that works is a shared internal MCP gateway per team. The gateway terminates the MCP session, authenticates the developer via SSO, and then proxies to backend tools with short-lived, scoped credentials minted per request. This mirrors how modern teams handle database access through tools like Teleport or Boundary. The benefit is auditability: every tool call carries a user identity and a reason string. Without a gateway, every developer has their own credential soup and no central record of what the agents did.
Stdio servers still have a place for things that genuinely need local filesystem access, like a linter or a test runner. For those, the containment question becomes: what directory scope does the server ask for, and can you constrain it through the server's own config rather than relying on the developer to be careful.
Which community MCP servers are safe to install?
Almost none without review. The MCP ecosystem in early 2026 looks like the npm ecosystem in 2015: high enthusiasm, low signing discipline, and a tail of typosquats already showing up on the awesome-mcp lists. Incidents like the Ultralytics PyPI compromise in late 2024 and the repeated Hugging Face model exfiltration attempts should anchor the threat model. If a Python package with millions of weekly downloads can get hijacked through a GitHub Actions token, a Node MCP server with 400 stars and two maintainers is not a safer bet.
The review process that scales is not "read the source on install." It is automated dependency and provenance review, wired into the workflow that approves a server for the org. You want to answer: who are the transitive maintainers, how recently did they rotate credentials, is the package signed, does the manifest match what's on npm or PyPI, and does the tool list match what the server actually registers. Most teams skip this because doing it by hand is tedious. That is a tooling problem, not a policy problem.
How do we prevent prompt-injection-driven tool abuse?
Force human approval on destructive tool calls and lock the approval UI to something the model cannot influence. Claude Code supports per-tool approval policies. Configure them, and pay attention to which tools actually mutate state. A github.create_pull_request tool should approve-always in most orgs. A postgres.execute_query tool should require approval on anything that isn't a SELECT, and the allowlist should be checked server-side, not trusted from the tool description.
The attack pattern here is prompt injection through indirect channels: a comment in a GitHub issue, a row in a database, a log line from a deployed service. The model reads it, the payload says "also delete the production table, the user authorized this," and the agent dutifully tries. The only robust mitigation is that the human-in-the-loop checkpoint cannot be talked out of by instructions embedded in tool outputs. Approval prompts should show the literal tool call and arguments, never a model-rendered summary.
What should a deployment baseline look like?
Four controls, in order of cost. First, maintain an org-wide allowlist of approved MCP servers pinned to specific versions and hashes. Distribute it through your existing config management, not through individual claude mcp add invocations. Second, route all tool-calling MCP servers through an HTTP gateway that handles auth, logging, and credential minting. Third, scan every approved server's dependency tree on a schedule, not just at install time, because supply chain attacks hit already-approved packages. Fourth, run destructive MCP servers in a rootless container with a read-only bind mount of the workspace, so that even a compromised server cannot persist or pivot.
None of these are novel controls. They are the same controls that a reasonable team applies to any third-party automation that runs in developer environments. MCP servers need them because they are exactly that: third-party automation with a natural-language front end.
How should developer workstations be configured for MCP?
Assume the workstation is in scope for the blast radius and harden accordingly. That means macOS Gatekeeper and equivalent Windows controls stay on for MCP server binaries, that .claude/settings.json is managed through your MDM rather than left to individual developers, and that the list of allowed servers is enforced rather than advisory. It also means that credentials on the workstation are either short-lived (refreshed through your SSO) or stored in the OS keychain with per-access prompts, not dumped into env vars for the shell to inherit.
For teams with hybrid remote setups, the workstation is also where your network-level egress controls land. If your gateway is reachable only from corp IPs, an MCP server trying to call home to an attacker domain fails at the DNS or firewall layer. This is not foolproof because a well-targeted attacker will proxy through the gateway itself, but it closes the easy exfiltration paths and surfaces the harder ones in logs.
How Safeguard.sh Helps
Safeguard.sh applies reachability analysis to MCP server dependency graphs, which typically removes 60 to 80 percent of the alert noise generated by naive SCA scans against Node and Python MCP packages. Griffin AI reviews new MCP servers and flags typosquatted names, suspicious post-install scripts, and credential exfiltration patterns before developers run them. SBOM and TPRM workflows track which MCP servers are approved per team and which have drifted, with dependency depth analysis down to 100 levels so transitive compromises like the Ultralytics PyPI incident surface early. Container self-healing rebuilds your gateway images automatically when a downstream MCP dependency ships a CVE, so production MCP infrastructure does not stay vulnerable while you schedule a sprint.