Configuring your development environment is basically handing someone the keys to your house. You can give them a copy of the front gate key, or you can give them the master key that opens everything — the garage, the safe, the room where you keep your backups. The question isn't technical. It's: how much do you trust them?
Now: what happens when the person you gave the keys to also invites friends? And those friends bring others? And none of them went through any kind of screening?
That's exactly what's happening today with local MCP servers. And it's, curiously enough, what Emacs has spent decades trying to solve.
Trust in configuration tools and your own environment: the problem nobody names
I don't use Emacs. I tried it, survived a week, and decided my productivity didn't deserve that level of voluntary suffering. But there's something the Emacs ecosystem understands better than almost any other development environment: that giving a tool power over your system is an act with real consequences.
A few days ago I read the draft of "Towards trust in Emacs" — a proposal to formalize the trust model inside Emacs, especially around third-party packages and their system access. And I couldn't stop thinking: this is the debate the agent ecosystem should be having. And it's not having it.
The Emacs proposal starts from a simple but brutal question: when you install a package from MELPA, what permissions are you giving it? Can it read your files? Can it execute shell commands? Can it make HTTP requests? The honest answer is: yes, all of that, without asking you anything.
Now replace "Emacs package" with "local MCP server" and the problem is identical.
How trust works in Emacs (and why it matters outside of Emacs)
The historical trust model in Emacs was: if you installed it, you trust it. Full stop. No real sandboxing. No capability declarations. No permission review after installation.
The "Towards trust in Emacs" proposal tries to change that with something more granular:
- Per-package trust levels: not everything you install needs full access
- Explicit capability declarations: the package says what it needs, you decide what to grant
- Audit trail: what each package executed and when
- Progressive sandboxing: start with minimal access, expand as needed
Sounds reasonable. Sounds like something that should've existed twenty years ago. And the reason it doesn't exist yet is exactly the reason AI agents don't have it either: upfront friction kills adoption.
Nobody wants their tool asking permission for every operation. But the other extreme — full access without asking — is a disaster waiting to happen.
The concrete problem with local MCP servers
When I ran my first local MCP servers to connect Claude with my system's tools, the experience went like this:
# Install a third-party MCP server
npx @some-developer/mcp-filesystem-server
# What you just did:
# - Executed code from someone you don't know
# - Gave it access to your filesystem (because that's what the server does)
# - Without auditing the code
# - Without knowing what else it does beyond what it claims
# - Without any way to granularly revoke permissions later
The typical config in claude_desktop_config.json looks like this:
{
"mcpServers": {
"filesystem": {
"command": "npx",
"args": [
"-y",
"@modelcontextprotocol/server-filesystem",
"/Users/juanchi/projects"
]
},
"postgres": {
"command": "npx",
"args": [
"-y",
"@modelcontextprotocol/server-postgres",
"postgresql://localhost/mydb"
]
}
}
}
See that -y in the npx call. That means "download and install without asking." Every time Claude Desktop starts up, it potentially pulls fresh code from npm and runs it with access to your filesystem and your database.
How many of you audited the source code of the MCP server you installed? I didn't. I installed it, it worked, I moved on.
That's exactly the problem Emacs has with MELPA. And Emacs is at least having the discussion.
// What we want: explicit capability declarations
interface MCPServerManifest {
name: string;
version: string;
// What this server needs to function
requiredCapabilities: {
filesystem?: {
read: string[]; // paths it can read
write: string[]; // paths it can write
execute: boolean; // can it execute files?
};
network?: {
allowedHosts: string[]; // only these domains
allowedPorts: number[];
};
shell?: {
allowed: boolean;
allowedCommands?: string[]; // explicit whitelist
};
};
// Hash of audited code
codeSignature?: string;
}
// What we have: none of this
// The server starts and has access to everything the process has
The failures I've already seen (and the ones coming)
The trust discussion in Emacs identifies three failure patterns I recognize completely in the agent ecosystem:
1. Transitive trust without control
You install a trustworthy MCP server. That server has dependencies. Those dependencies have sub-dependencies. One of those sub-dependencies has a vulnerability or just does weird stuff. You trusted the server — not its entire dependency chain.
Emacs has the same problem with packages: you install magit and transitively install five other things you never audited.
2. Silent scope creep
An MCP server you installed to read Markdown files could, technically, read any file on your system. The scope it declared in the README and the scope it actually has are two different things.
When I measured the real costs of my agents (I went into detail on that here), I realized MCP servers were performing operations I never explicitly requested — directory enumeration, reading config files — as part of their "context gathering" process.
3. The illusion of a controlled environment
You have Docker, you have Railway, you think your environment is isolated. But the MCP server runs on your local machine, outside any container, with your credentials. The sandboxing you apply to your production code doesn't apply here.
This connects to something I wrote before about the costs of architectural decisions in agents: every design decision has consequences that amplify down the chain. A wrong trust decision early on amplifies through everything that comes after.
What the agent ecosystem should learn from Emacs
Emacs, for all its weirdness and inscrutability (I say that with affection and trauma), understands something fundamental: its environment is also its attack surface. The flexibility that makes it powerful is exactly the same flexibility that makes it dangerous.
AI agents in 2025 have exactly the same tension:
- To be useful, they need real system access
- To be safe, that access needs to be bounded
- To get adoption, configuration needs to be simple
These three goals are in conflict. And the ecosystem today resolves that conflict by ignoring the second one.
Anthropic published Claude Design which shows how they think about the developer experience, but the trust question around MCP isn't sufficiently developed there. The documentation tells you how to install servers, not how to evaluate them.
What Emacs is trying to do — and what should exist in the MCP ecosystem — is something like this:
# Hypothetical: mcp-manifest.yaml that every server should have
name: "filesystem-server"
version: "1.2.0"
author: "modelcontextprotocol"
code_hash: "sha256:abc123..." # auditable code hash
capabilities:
filesystem:
read:
- "${WORKSPACE_DIR}/**/*.md" # only markdown in your workspace
- "${WORKSPACE_DIR}/**/*.ts" # only TypeScript
write:
- "${WORKSPACE_DIR}/**/*.md" # can write markdown
# NO write access to .env, ~/.ssh, or anything outside the workspace
network: false # doesn't need network
shell: false # doesn't execute commands
review_status:
last_audit: "2025-01-15"
audited_by: "anthropic-security"
issues_found: 0
This doesn't exist. We should be demanding it.
The connection nobody's drawing
There's a deep irony here. In the software world, we've spent decades building layers of trust: digital signatures, dependency audits, SBOM (Software Bill of Materials), Supply Chain Security. Npm has npm audit. Cargo has cargo-audit. Python has pip-audit.
And then AI agents arrived — with their ability to execute arbitrary code and access real systems — and we went back to 1995. Install and trust.
This reminds me of the debate I opened when I wrote about Brunost — who decides what's readable, what's trustworthy, what gets into the ecosystem. The power of curation is real power. And in the MCP ecosystem right now, nobody holds it.
Also, when I built a Python interpreter in Python, what I learned is that the boundary between "executing" and "interpreting" is blurrier than it looks. An MCP server is, in a real sense, an interpreter: it takes instructions from an agent and executes them on your system. The limits of that interpreter should be explicitly defined.
FAQ: Trust in tools, configuration, and your own environment
What is an MCP server and why should I care about security?
An MCP (Model Context Protocol) server is a process that runs locally and gives your AI agent access to real tools: your filesystem, your database, external APIs. It matters because that process has the same permissions as your user account on the operating system. If the code is malicious or has vulnerabilities, it has access to everything you have access to.
Is the Emacs problem really the same as the AI agent problem?
Structurally, yes. In both cases you have an extensible environment where third-party plugins/servers can execute code with real system access, without a granular permission model or a standardized audit process. The difference is that Emacs is discussing how to solve it. The agent ecosystem hasn't seriously started that conversation yet.
How can I audit an MCP server before installing it?
Today, manually. You review the repository on GitHub, read the source code, check dependencies with npm audit, review the commit history. There's no automated tooling specific to MCP servers. At minimum: use MCP servers with public, active repositories and verifiable maintainers. Avoid anything that comes only as an npm package with no accessible source code.
What is "transitive trust" and why is it a problem?
It's when you trust A because A claims to be trustworthy, but A depends on B, C, and D that you never audited. In the npm ecosystem, a "simple" package can have 50 transitive dependencies. When you install an MCP server, you install all of that. The famous left-pad vulnerability in 2016 was exactly this: a transitive dependency nobody thought was critical.
Does sandboxing exist for MCP servers?
Not natively or in any standardized way. You can run MCP servers inside Docker containers with limited volumes and no network access, which significantly reduces the blast radius. But it requires manual configuration and breaks some servers that assume unrestricted access. Classic security vs. configuration-friction tradeoff.
When will the MCP ecosystem have a real trust model?
I don't know. And that worries me. The pressure to adopt AI agents fast is enormous — both in companies and personal projects. When adoption pressure is high and security maturity is low, incidents are inevitable. My prediction: the ecosystem will start taking this seriously after the first significant public incident. I hope I'm wrong.
The Emacs problem is your problem
You don't need to use Emacs for this to matter to you. If you have local MCP servers running — or you're considering running them — you're in exactly the situation that "Towards trust in Emacs" describes: a powerful, extensible ecosystem with a trust model that's basically "hope for the best."
The frustration I feel isn't with any particular tool. It's with the pattern. We built decades of practice in supply chain security, dependency auditing, least-privilege principle — and every new technology wave arrives and repeats the same mistakes from scratch.
What Emacs is trying to articulate in 2025 should be the central conversation in the AI agent ecosystem. It isn't. In the meantime, my practical configuration is the most boring one possible: only MCP servers from Anthropic's official repository, source code reviewed before installing, and Docker with explicit volumes when I can manage it.
More friction? Yes. Worth it? Ask anyone who's had a security incident at 2am.
Do you have third-party MCP servers running locally? Did you audit them? Tell me in the comments — or don't, honestly, I already know the answer.
