Los MCP servers están ganando terreno porque facilitan que los agentes de IA consulten herramientas y datos “en vivo” dentro de una empresa. Ese acceso es útil, pero también cambia el lugar donde viven las credenciales y cómo se usan. En la práctica, el mismo componente que hace posible que la IA trabaje con sistemas internos puede acabar revelando secretos si no se diseña y gobierna con rigor.
En este artículo repasamos por qué los MCP servers pueden terminar exponiendo credenciales, cuáles son las vías de riesgo más comunes y qué acciones concretas ayudan a reducir la superficie de ataque.
Qué es MCP y por qué importa para los secretos
El Model Context Protocol (MCP) es un estándar abierto que permite a asistentes y agentes conectar con herramientas externas y fuentes de datos. En lugar de depender únicamente del conocimiento del modelo, la IA puede interactuar con sistemas reales: consultar una base de datos, abrir un archivo o llamar una API.
El elemento clave es el MCP server: un programa que actúa como intermediario entre el agente y el sistema que intenta usar. Ese “puente” define qué acciones puede realizar el agente y, para poder ejecutarlas, normalmente necesita credenciales del propio entorno empresarial.
Por qué un MCP server puede convertirse en la “llave” de todo
Cuando los agentes de IA dejan de ser solo generadores de respuestas y pasan a tomar acción, el impacto de una filtración aumenta. Los agentes pueden recuperar información sensible, decidir qué herramientas llamar y operar mediante identidades no humanas como claves de API y tokens.
En ese contexto, si una credencial se filtra desde el MCP server, no solo se expone un dato: también puede habilitar acciones maliciosas sobre sistemas que la empresa confía a la capa de IA.
Formas habituales en las que los MCP servers exponen secretos
Credenciales en texto plano dentro de archivos de configuración
Una causa frecuente es que los MCP servers guardan tokens y claves en archivos locales. En muchos despliegues, iniciar el servidor implica pegar una cadena de configuración que incluye las credenciales. Si ese archivo queda en disco, se copia entre máquinas o termina incluido en un repositorio, las claves pueden volverse legibles.
Una vez que un atacante logra acceso a ese punto, puede leer todo lo que el MCP server contiene.
“Sprawl” de credenciales sin gobernanza central
Si no existe un lugar único para almacenar secretos, cada agente puede terminar gestionando los suyos. El resultado es la dispersión de claves por configuraciones y variables de entorno, con duplicados en desarrollo, staging y producción.
Además, sin una visibilidad completa del inventario de secretos, suele faltar la rotación. Los tokens y claves se mantienen válidos durante más tiempo del que una empresa debería tolerar.
Prompt injection: cuando el contenido engaña al agente
No todos los incidentes requieren “hackear” el sistema. Dado que los agentes leen y actúan sobre el material que se les entrega, un atacante puede esconder instrucciones dentro de documentos, tickets de soporte o páginas web que el agente consulta.
Ese mecanismo, conocido como prompt injection, puede llevar al agente a ejecutar acciones indebidas o incluso a compartir secretos que se suponía que protegía.
Permisos excesivos que terminan en producción
En el desarrollo, es común evitar errores de autorización concediendo permisos amplios para que todo funcione. Sin embargo, si esos alcances no se ajustan antes del despliegue final, la configuración “generosa” puede llegar a producción.
Cuando no se aplica el principio de mínimo privilegio, una sola falla puede exponer mucho más de lo necesario.
Riesgo de servidor expuesto: problemas de supply chain
Otra vía proviene del hecho de que cualquiera puede publicar un MCP server. Conectar con un servidor no confiable introduce un problema de cadena de suministro: el componente podría comportarse de forma maliciosa.
El riesgo puede incluir desde comportamientos inesperados hasta situaciones que permitan ejecución de código del lado del proxy que ejecuta la integración, con el objetivo de acceder a credenciales.
Buenas prácticas para proteger secretos en MCP servers
Proteger secretos en esta capa no es automático: requiere intencionalidad. A continuación se presentan medidas que ayudan a cortar rutas de exposición y limitar el daño si algo sale mal.
Evita “hardcoding” y centraliza credenciales
El primer paso es dejar de incrustar secretos en archivos de configuración, variables de entorno o código fuente. En su lugar, conviene mover credenciales a un almacén gestionado y que los agentes las soliciten en tiempo de ejecución.
Esto reduce tanto la exposición por texto plano como la dispersión de copias en múltiples servidores.
Usa credenciales de corta duración y rota automáticamente
Las claves estáticas y de larga vida son especialmente valiosas para atacantes porque permanecen útiles incluso si se filtran. Cambiarlas por credenciales emitidas bajo demanda y con vencimiento reduce la ventana de ataque.
Además, la rotación automática asegura que una credencial filtrada pierda utilidad con rapidez.
Aplica mínimo privilegio para cada tarea
Diseña el acceso del agente para que solo alcance los sistemas y datos necesarios para su función. Así, si un MCP server o un agente queda comprometido, el impacto se limita a una porción mucho menor del entorno.
Incluye verificación humana en acciones sensibles
Cuando la acción implica tocar información crítica o sistemas de producción, puede ser conveniente exigir confirmación explícita. Ese control frena escenarios donde una prompt injection intenta convertir instrucciones engañosas en una acción irreversible.
Cifra secretos con enfoque zero-trust y zero-knowledge
Una estrategia potente consiste en cifrar secretos de extremo a extremo, de forma que solo se recuperen al momento de uso y no queden legibles para la plataforma donde se almacenan. En un enfoque de zero-knowledge, un almacén comprometido no debería entregar secretos entendibles para un atacante.
Registra y audita cada acción del agente
Los agentes pueden operar rápido y con poca supervisión directa. Por eso, es esencial conservar registros de lo que se consultó o ejecutó, además de cuándo ocurrió. Esto ayuda tanto en cumplimiento como en el análisis de incidentes.
Haz inventario de los MCP servers en tu entorno
“No se protege lo que no se ve”. Mantener visibilidad sobre qué MCP servers están en ejecución reduce el riesgo de identidades no gestionadas que retienen credenciales y pasan desapercibidas en revisiones de seguridad.
Un inventario efectivo también facilita el monitoreo, la rotación y la respuesta ante anomalías.
Replantea la gestión de secretos para agentes de IA
Los MCP servers introducen una capa nueva entre la IA y los sistemas empresariales. Esa capa puede concentrar credenciales y, por tanto, exige el mismo nivel de disciplina que cualquier sistema de producción que maneje secretos.
En la práctica, la seguridad mejora cuando las credenciales se centralizan, se controlan rigurosamente los permisos y se evita que los valores quedaran expuestos en configuraciones o repositorios. Además, un flujo de trabajo con confirmación y auditoría ayuda a detectar y frenar intentos de abuso.
Muchas organizaciones complementan estas prácticas con soluciones de gestión de secretos que enmascaran valores por defecto y requieren validación antes de revelar información sensible para su uso por parte de agentes.
Conclusión
Los MCP servers no son intrínsecamente inseguros: hacen posible que la IA interactúe con herramientas y datos reales. El riesgo aparece cuando la capa se despliega sin controles: credenciales en texto plano, permisos excesivos, falta de rotación, ataques de prompt injection y exposición por supply chain.
Si quieres reducir el riesgo, aplica mínimo privilegio, centraliza credenciales, usa expiración y rotación, cifra con un enfoque zero-trust/zero-knowledge, mantén auditoría y realiza inventario continuo de todos los MCP servers. Con esa combinación, la empresa puede aprovechar la automatización sin entregar las llaves del sistema a la ligera.
Fuente: https://thehackernews.com/2026/08/how-mcp-servers-can-expose-enterprise.html
