Configurar tu entorno de desarrollo es básicamente como darle las llaves de tu casa a alguien. Podés darle una copia de la llave del portón nada más, o podés darle la llave maestra que abre todo —el garaje, la caja fuerte, el cuarto donde guardás los backups. La pregunta no es técnica. Es: ¿cuánto confiás?
Ahora bien: ¿qué pasa cuando la persona a la que le das las llaves también invita amigos? ¿Y esos amigos traen a otros? ¿Y ninguno de ellos pasó por ningún control?
Eso es exactamente lo que pasa hoy con los MCP servers locales. Y es, curiosamente, lo que Emacs lleva décadas intentando resolver.
Confianza en herramientas de configuración y entorno propio: el problema que nadie nombra
No uso Emacs. Lo intenté, sobreviví una semana, y decidí que mi productividad no merecía ese nivel de sufrimiento voluntario. Pero hay algo que el ecosistema de Emacs entiende mejor que casi cualquier otro entorno de desarrollo: que darle poder a una herramienta sobre tu sistema es un acto con consecuencias reales.
Hace unos días leí el draft de "Towards trust in Emacs" —una propuesta para formalizar el modelo de confianza dentro de Emacs, especialmente en relación a paquetes de terceros y su acceso al sistema. Y me quedé pensando: este es el debate que el ecosistema de agentes debería estar teniendo. Y no lo está teniendo.
La propuesta de Emacs parte de una pregunta sencilla pero brutal: cuando instalás un paquete desde MELPA, ¿qué permisos le estás dando? ¿Puede leer tus archivos? ¿Puede ejecutar comandos en la shell? ¿Puede hacer requests HTTP? La respuesta honesta es: sí, todo eso, sin preguntarte nada.
Ahora reemplazá "paquete de Emacs" por "MCP server local" y el problema es idéntico.
Cómo funciona el trust en Emacs (y por qué importa fuera de Emacs)
El modelo de confianza en Emacs históricamente fue: si lo instalaste, confiás en ello. Punto. No hay sandboxing real. No hay declaración de capabilities. No hay revisión de permisos después de la instalación.
La propuesta "Towards trust in Emacs" intenta cambiar eso con algo más granular:
- Trust levels por paquete: no todo lo que instalás tiene que tener acceso total
- Declaración explícita de capabilities: el paquete dice qué necesita, vos decidís qué le das
- Audit trail: qué ejecutó cada paquete y cuándo
- Sandboxing progresivo: empezás con acceso mínimo, ampliás según necesidad
Suena razonable. Suena a algo que debería existir hace veinte años. Y la razón por la que no existe todavía es exactamente la razón por la que los agentes IA tampoco lo tienen: la fricción inicial mata la adopción.
Nadie quiere que su herramienta le pregunte permiso para cada operación. Pero el otro extremo —acceso total sin preguntar— es un desastre esperando pasar.
El problema concreto con MCP servers locales
Cuando corrí mis primeros MCP servers locales para conectar Claude con herramientas de mi sistema, la experiencia fue así:
# Instalar un MCP server de terceros
npx @algún-developer/mcp-filesystem-server
# Lo que acabas de hacer:
# - Ejecutar código de alguien que no conocés
# - Darle acceso a tu filesystem (porque eso hace el server)
# - Sin auditar el código
# - Sin saber qué más hace además de lo que dice que hace
# - Sin forma de revocar permisos granularmente después
La configuración típica en claude_desktop_config.json se ve así:
{
"mcpServers": {
"filesystem": {
"command": "npx",
"args": [
"-y",
"@modelcontextprotocol/server-filesystem",
"/Users/juanchi/proyectos"
]
},
"postgres": {
"command": "npx",
"args": [
"-y",
"@modelcontextprotocol/server-postgres",
"postgresql://localhost/midb"
]
}
}
}
Mirá ese -y en el npx. Eso significa "bajá e instalá sin preguntar". Cada vez que arranca Claude Desktop, potencialmente baja código nuevo de npm y lo ejecuta con acceso a tu filesystem y tu base de datos.
¿Cuántos de ustedes auditaron el código fuente del MCP server que instalaron? Yo no. Lo instalé, funcionó, seguí.
Eso es exactamente el problema que tiene Emacs con MELPA. Y Emacs al menos tiene la discusión.
// Lo que queremos: declaración explícita de capabilities
interface MCPServerManifest {
name: string;
version: string;
// Qué necesita este server para funcionar
requiredCapabilities: {
filesystem?: {
read: string[]; // paths que puede leer
write: string[]; // paths que puede escribir
execute: boolean; // puede ejecutar archivos?
};
network?: {
allowedHosts: string[]; // solo estos dominios
allowedPorts: number[];
};
shell?: {
allowed: boolean;
allowedCommands?: string[]; // whitelist explícita
};
};
// Hash del código auditado
codeSignature?: string;
}
// Lo que tenemos: nada de esto
// El server arranca y tiene acceso a todo lo que el proceso tiene
Los errores que ya vi (y los que voy a ver)
La discusión sobre trust en Emacs identifica tres patrones de falla que reconozco completamente en el ecosistema de agentes:
1. Confianza transitiva sin control
Instalás un MCP server confiable. Ese server tiene dependencias. Esas dependencias tienen subdependencias. Una de esas subdependencias tiene una vulnerabilidad o directamente hace cosas raras. Vos confiaste en el server, no en toda su cadena de dependencias.
Emacs tiene el mismo problema con los paquetes: instalás magit y transitivamente instalás cinco cosas más que nunca auditaste.
2. Scope creep silencioso
Un MCP server que instalaste para leer archivos Markdown podría, técnicamente, leer cualquier archivo de tu sistema. El scope que declaró en el README y el scope que realmente tiene son dos cosas distintas.
Cuando medí los costos reales de mis agentes (acá hablé de eso en detalle), me di cuenta de que los MCP servers estaban haciendo operaciones que yo nunca pedí explícitamente —enumeración de directorios, lecturas de archivos de configuración— como parte de su proceso de "contexto".
3. La ilusión del entorno controlado
Tenés Docker, tenés Railway, creés que tu entorno está aislado. Pero el MCP server corre en tu máquina local, fuera de cualquier container, con tus credenciales. El sandboxing que aplicás a tu código de producción no aplica acá.
Esto se conecta con algo que escribí antes sobre los costos de decisiones de arquitectura en agentes: cada decisión de diseño tiene consecuencias que se amplifican. Una decisión de trust incorrecta al principio se amplifica en toda la cadena.
Lo que el ecosistema de agentes debería aprender de Emacs
Emacs, para todo lo que tiene de raro y hermético (hablo con cariño y trauma), entiende algo fundamental: su entorno es también su superficie de ataque. La flexibilidad que lo hace poderoso es exactamente la misma flexibilidad que lo hace peligroso.
Los agentes IA en 2025 tienen exactamente la misma tensión:
- Para ser útiles, necesitan acceso real al sistema
- Para ser seguros, ese acceso tiene que estar acotado
- Para tener adopción, la configuración tiene que ser simple
Estos tres objetivos están en conflicto. Y el ecosistema hoy resuelve ese conflicto ignorando el segundo objetivo.
Anthropíc publicó Claude Design que muestra cómo piensan en la experiencia del developer, pero el tema de trust en MCP no está suficientemente desarrollado. La documentación te dice cómo instalar servidores, no cómo evaluarlos.
Lo que Emacs está intentando hacer —y que debería existir en el ecosistema MCP— es algo así:
# Hipotético: mcp-manifest.yaml que cada server debería tener
name: "filesystem-server"
version: "1.2.0"
author: "modelcontextprotocol"
code_hash: "sha256:abc123..." # hash auditable del código
capabilities:
filesystem:
read:
- "${WORKSPACE_DIR}/**/*.md" # solo markdown en tu workspace
- "${WORKSPACE_DIR}/**/*.ts" # solo TypeScript
write:
- "${WORKSPACE_DIR}/**/*.md" # puede escribir markdown
# NO tiene write en .env, en ~/.ssh, en nada fuera del workspace
network: false # no necesita red
shell: false # no ejecuta comandos
review_status:
last_audit: "2025-01-15"
audited_by: "anthropic-security"
issues_found: 0
Esto no existe. Deberíamos estar pidiéndolo.
La conexión que nadie dibuja
Hay una ironía profunda acá. En el mundo del software, llevamos décadas construyendo capas de confianza: firmas digitales, auditorías de dependencias, SBOM (Software Bill of Materials), Supply Chain Security. Npm tiene npm audit. Cargo tiene cargo-audit. Python tiene pip-audit.
Y entonces llegaron los agentes IA, con su capacidad de ejecutar código arbitrario y acceder a sistemas reales, y... volvimos a 1995. Instalá y confiá.
Esto me recuerda al debate que abrí cuando escribí sobre Brunost —quien decide qué es legible, qué es confiable, qué entra en el ecosistema. El poder de curación es un poder real. Y en el ecosistema MCP, hoy no lo tiene nadie.
También cuando construí un intérprete de Python en Python, lo que aprendí es que los límites entre "ejecutar" e "interpretar" son más difusos de lo que parecen. Un MCP server es, en cierta forma, un intérprete: toma instrucciones de un agente y las ejecuta en tu sistema. Los límites de ese intérprete deberían estar definidos explícitamente.
FAQ: Confianza en herramientas, configuración y entorno propio
¿Qué es un MCP server y por qué debería importarme la seguridad?
Un MCP (Model Context Protocol) server es un proceso que corre localmente y le da a tu agente IA acceso a herramientas reales: tu filesystem, tu base de datos, APIs externas. Importa porque ese proceso tiene los mismos permisos que tu usuario en el sistema operativo. Si el código es malicioso o tiene vulnerabilidades, tiene acceso a todo lo que vos tenés acceso.
¿Es lo mismo el problema de Emacs que el de los agentes IA?
Estructuralmente, sí. En ambos casos tenés un entorno extensible donde plugins/servers de terceros pueden ejecutar código con acceso real al sistema, sin un modelo de permisos granular ni un proceso de auditoría estandarizado. La diferencia es que Emacs está discutiendo cómo resolverlo. El ecosistema de agentes todavía no arrancó esa discusión en serio.
¿Cómo puedo auditar un MCP server antes de instalarlo?
Hoy, manualmente. Revisás el repositorio en GitHub, leés el código fuente, verificás las dependencias con npm audit, revisás el historial de commits. No hay herramienta automatizada específica para MCP servers. Como mínimo: usá MCP servers con repositorios públicos, activos y con maintainers verificables. Evitá los que vienen solo como paquetes npm sin código fuente accesible.
¿Qué es "confianza transitiva" y por qué es un problema?
Es cuando confiás en A porque A dice ser confiable, pero A depende de B, C y D que nunca auditaste. En el ecosistema npm, un paquete "simple" puede tener 50 dependencias transitivas. Cuando instalás un MCP server, instalás todo eso. La vulnerabilidad famous de left-pad en 2016 fue exactamente esto: una dependencia transitiva que nadie había pensado que era crítica.
¿Existe sandboxing para MCP servers?
No de forma nativa y estandarizada. Podés correr MCP servers dentro de Docker containers con volúmenes limitados y sin acceso a red, lo que reduce significativamente el blast radius. Pero requiere configuración manual y rompe algunos servers que asumen acceso irrestricto. Es el tradeoff clásico entre seguridad y fricción de configuración.
¿Cuándo va a tener el ecosistema MCP un modelo de trust real?
No sé. Y eso me preocupa. La presión para adoptar agentes IA rápido es enorme —tanto en empresas como en proyectos personales. Cuando la presión de adopción es alta y la madurez de seguridad es baja, los incidentes son inevitables. Mi predicción: el ecosistema va a empezar a tomar esto en serio después del primer incidente público significativo. Ojalá me equivoque.
Conclusión: el problema de Emacs es tu problema
No necesitás usar Emacs para que esto te importe. Si tenés MCP servers locales corriendo —o si estás considerando correrlos— estás en exactamente la misma situación que describe "Towards trust in Emacs": un ecosistema poderoso, extensible, y con un modelo de confianza que es básicamente "ojalá funcione".
La frustración que siento no es con ninguna herramienta en particular. Es con el patrón. Construimos décadas de práctica en supply chain security, en auditoría de dependencias, en principio de menor privilegio —y cada nueva ola tecnológica llega y repite los mismos errores desde cero.
Lo que Emacs está intentando articular en 2025 debería ser la conversación central del ecosistema de agentes IA. No lo es. Mientras tanto, mi configuración práctica es la más aburrida posible: solo MCP servers del repositorio oficial de Anthropic, código fuente revisado antes de instalar, y Docker con volúmenes explícitos cuando puedo.
¿Es más fricción? Sí. ¿Vale la pena? Preguntale a cualquiera que haya tenido un incidente de seguridad a las 2am.
¿Tenés MCP servers de terceros corriendo localmente? ¿Los auditaste? Contame en los comentarios —o no me cuentes, total, ya sé la respuesta.
Este artículo fue publicado originalmente en juanchi.dev
