Claves API para servidores MCP: el riesgo de confiar en variables de entorno
Un profesional de DevOps advierte en un foro que el control de accesos tradicional no vale cuando un agente con LLM elige sus herramientas de forma dinámica.
El auge de los agentes basados en modelos de lenguaje está trayendo retos de seguridad nuevos, y uno de los más comentados en los últimos días es cómo gestionar las credenciales que esos agentes usan para invocar servicios externos a través del protocolo MCP (Model Context Protocol). Un profesional lo ha planteado en un foro de DevOps con un argumento que invita a reflexionar: la práctica común de meter las claves API en variables de entorno y dejar que el agente las use como quiera funciona hasta que dejas de tener un código determinista.
En un servicio backend clásico, conoces la secuencia de llamadas que hará cada parte del código, así que puedes auditar qué clave se usa para qué. Con un agente, la selección de herramientas la hace el modelo a partir del prompt, lo que significa que la misma clave puede acabar empleándose para acciones que nunca tuviste en mente cuando la concediste. Las herramientas de gestión de secretos registran dónde vive la clave y cuándo rota, pero no saben qué llamada concreta la utilizó ni si esa llamada fue autorizada explícitamente.
Ante esa falta de trazabilidad, la recomendación que aparece una y otra vez es limitar el alcance de cada credencial a un servidor MCP concreto, en lugar de tener una clave maestra para todo. A eso se une la sugerencia de inyectar las claves en tiempo de ejecución y no mantenerlas persistidas en el entorno, de modo que el proceso que lanza el agente sea el que adquiere el secreto en el último momento. Con eso se reduce la ventana de exposición, pero sigue sin resolverse el control fino sobre qué herramientas puede tocar el agente.
Algunos equipos optan por construir pasarelas intermedias que filtran las peticiones del agente antes de que alcancen el servicio externo, bloqueando dominios o acciones no permitidas. Otros aceptan el riesgo y tratan el acceso como el de un servicio interno con una esfera de confianza amplia. No hay consenso todavía, y probablemente no lo habrá hasta que los frameworks de agentes ofrezcan mecanismos nativos de auditoría de llamadas.
La reflexión es oportuna porque MCP se ha convertido en un mecanismo ampliamente adoptado para que los asistentes interactúen con datos y servicios corporativos, y los primeros despliegues en producción ya están chocando con estas cuestiones. De momento, la seguridad de los agentes se sigue apoyando en buenas prácticas heredadas, pero cada vez más gente coincide en que hace falta un modelo de autorización pensado para procesos no deterministas. Queda por ver cómo los proveedores de herramientas y protocolos integran esa capa sin añadir fricción al desarrollo.