Servidores MCP
Corre en tu máquina con tus permisos, como cualquier paquete. A diferencia de un paquete, sus descripciones de herramientas caen dentro del contexto del modelo, donde se leen como instrucciones. La seguridad de un servidor MCP tiene que cubrir las dos mitades.
Ninguno de estos es exótico. Salen de cómo funciona el protocolo y de dónde pone la gente sus credenciales.
tool poisoning
El nombre, la descripción y el esquema de parámetros de una herramienta llegan al modelo como texto. Un servidor puede escribir una descripción que le diga al modelo que lea un archivo y pase su contenido como argumento, y el modelo no tiene forma de distinguir eso de una instrucción legítima.
entrega de credenciales
Los servidores MCP locales corren por stdio como procesos hijo. Reciben el entorno que les das, y eso suele significar un token de larga vida en una variable. A partir de ahí la credencial ya no está en tus manos.
cambio de esquema
Las descripciones y los esquemas de las herramientas pueden cambiar en la siguiente actualización. El servidor que revisaste en marzo no es necesariamente el que corre en junio, y nada en el protocolo hace ruido con ese cambio.
alcance del token
Los servidores remotos guardan tokens de acceso en tu nombre. Un servidor que acepta o reenvía un token emitido para otro recurso se convierte en un delegado muy cómodo para llegar a cosas que nunca autorizaste.
sin registro
La mayoría de las configuraciones no guardan constancia de qué herramienta MCP se ejecutó, con qué argumentos y contra qué host. El problema aparece según el calendario de otro, normalmente en una factura o en un aviso de brecha.
El hilo común: es el modelo quien lee las descripciones de las herramientas, y la credencial está en algún sitio donde el servidor puede leerla. Arregla la segunda mitad y la primera deja de poder rentar.
Los servidores MCP locales y remotos se autentican de maneras completamente distintas, y esa diferencia pesa más de lo que sugieren la mayoría de las guías de instalación.
No hay paso de autenticación. El servidor es un proceso hijo que tú lanzaste, y merece tanta confianza como el entorno con el que lo arrancaste. El token que exportaste ahora también es el token del servidor.
confianza = tu entorno
El perfil de autorización de MCP se apoya en OAuth 2.1: el cliente descubre el servidor de autorización, tú das el consentimiento en el navegador, y el cliente guarda un token de acceso de vida corta con un token de refresco detrás.
confianza = el alcance del token
Nada de esto necesita un producto. Es la revisión que le harías a cualquier dependencia, más las dos preguntas propias de MCP.
Instala una versión concreta en vez de lo que latest resuelva hoy. Un servidor que se actualiza solo puede cambiar sus descripciones de herramientas después de que las aprobaras.
El README está escrito para ti. Las descripciones están escritas para el modelo. Lee las que el modelo va a recibir de verdad.
Un servidor stdio es un proceso hijo con tus permisos. Dale la credencial más estrecha que siga sirviendo, nunca un token de root que pasaba por ahí.
Un token revocable y de vida corta gana a un personal access token en una variable de entorno, aunque la configuración cueste cinco minutos más.
Un recurso, un destinatario. Un servidor que quiere un token de alcance amplio, o que acepta uno emitido para otra cosa, ya te está diciendo cómo se va a comportar.
Juntar cinco servicios detrás de un solo servidor MCP concentra todas las credenciales en un proceso. Sepáralos y el peor caso se hace más pequeño.
Si no puedes decir qué hizo un servidor el martes pasado, lo estás creyendo en vez de comprobándolo. Los registros son lo que convierte un incidente en un incidente acotado.
Trata un cambio de esquema de herramientas como una subida de dependencia: mira el diff. Es la comprobación que casi nadie hace, que es exactamente por lo que funciona como ataque.
Sallyport se sitúa delante de los servidores MCP con los que habla tu agente. Sus llamadas suben la misma escalera que todo lo demás y caen en el mismo registro.
01
Claude Code, Cursor o cualquier cliente MCP se conecta a Sallyport. Sallyport le presenta http.request, ssh.exec y los servidores upstream que hayas configurado.
02
Se pasan por proxy tanto los servidores stdio locales como los remotos con OAuth 2.1. Sallyport sella sus tokens en la bóveda y los refresca dentro de la app.
03
Una bóveda bloqueada deniega la llamada. Una clave marcada para aprobación por llamada levanta una tarjeta. Si no, la aprobación de sesión que ya diste cubre la ejecución.
04
Cifrado y encadenado por hash mientras ocurre, de modo que la respuesta a "qué hizo ese servidor el martes pasado" existe antes de que la necesites.
Un límite honesto: un servidor MCP local por stdio que tú configures sí recibe la credencial que le vincules. El proxy te da aprobación y constancia de sus llamadas; no le quita la clave a un proceso que decidiste arrancar.
Descarga gratis. Apple Silicon, macOS 14 o posterior. Sin cuenta, nunca.
brew install --cask olegsotnikov/tap/sallyportmacOS 14+ · Apple Silicon