Cuando los agentes de inteligencia artificial empiezan a interactuar con bases de datos operativas, el primer instinto suele ser pedirles amablemente que no hagan modificaciones. Pero confiar en una instrucción textual para que un modelo de lenguaje se comporte correctamente es como poner un cartel de 'no tocar' frente a un niño curioso: funciona hasta que el niño encuentra una forma de saltárselo. En el mundo de la integración entre sistemas y modelos de IA, especialmente cuando hablamos de colas de trabajo en Redis expuestas a través del protocolo MCP (Model Context Protocol), la única manera real de garantizar que un agente no altere datos es eliminar físicamente la posibilidad de hacerlo. Eso es exactamente lo que proponemos en este artículo: construir un servidor MCP de solo lectura para Redis donde la seguridad no depende de lo que el modelo 'entienda', sino de cómo está cableado el sistema.
El reto comienza cuando un equipo quiere que un asistente de IA, por ejemplo, pueda inspeccionar el estado de una cola de procesos para diagnosticar cuellos de botella o localizar trabajos fallidos. Lo natural es exponer herramientas de lectura como listar colas, ver estadísticas, obtener un trabajo concreto. Pero el mismo modelo que usa esas herramientas también podría, si se lo piden o si una inyección de prompt lo induce, intentar reencolar trabajos o eliminarlos. Si la herramienta para reencolar está registrada, aunque se le diga al modelo que no la use, el riesgo persiste. La solución convencional sería añadir una validación en el handler, pero eso sigue dejando la puerta abierta a que un ataque bien dirigido consiga llamar a la función. La única forma robusta es no registrar esas herramientas en absoluto cuando el modo es solo lectura.
Este enfoque, que llamamos 'seguridad por construcción', implica que la superficie de ataque se define en el momento de arrancar el servidor MCP, no en la descripción de las herramientas ni en las instrucciones del sistema. Al separar la lógica de registro en dos bloques —las herramientas de lectura siempre presentes, y las de escritura condicionadas a una bandera— conseguimos que un servidor lanzado con el parámetro --read-only nunca tenga acceso a las funciones que mutan el estado. Si el modelo, o un atacante que controla la entrada, intenta invocar retry_job o delete_job, el propio protocolo devuelve un error de 'herramienta desconocida'. No hay handler que validar, no hay autorización que eludir: la ruta de escritura simplemente no existe en el proceso.
Pero el registro no es la única capa. Por muy cuidado que esté el código, siempre existe la posibilidad de un error humano o de una futura modificación que introduzca una herramienta inadvertidamente. Por eso la segunda barrera son las credenciales con las que el servidor se conecta a Redis. En lugar de usar un usuario con permisos totales, es mucho más seguro configurar un usuario ACL (Access Control List) que solo tenga acceso a comandos de lectura. Redis permite definir categorías de comandos: +@read habilita todos los comandos de lectura, mientras que -@dangerous elimina aquellos que, aunque sean lecturas, pueden ser peligrosos —como KEYS, que escanea todo el espacio de claves y puede bloquear el servidor. Con esta configuración, incluso si un handler contiene un bug o un nuevo desarrollador añade una herramienta de escritura sin darse cuenta, Redis rechazará la operación con un error NOPERM. La base de datos misma actúa como guardián final.
Si se busca una línea aún más dura, se puede apuntar el servidor MCP hacia una réplica de solo lectura de Redis. En ese caso, cualquier intento de escritura, independientemente del comando o del usuario, recibe un error READONLY. Esta opción es ideal cuando no se puede modificar la configuración ACL o cuando se quiere una separación física total entre las operaciones de lectura y escritura.
Este diseño tiene implicaciones directas en la arquitectura de sistemas que integran agentes de IA con infraestructuras existentes. En Q2BSTUDIO, empresa especializada en desarrollo de aplicaciones a medida, aplicamos este principio cada vez que un cliente necesita conectar modelos de lenguaje a bases de datos en producción. No basta con decirle al modelo 'solo lee'; hay que diseñar el sistema para que no pueda escribir. Eso es especialmente relevante cuando se trabaja con servicios cloud como AWS o Azure, donde las credenciales y los grupos de seguridad deben estar alineados con el principio de mínimo privilegio.
Sin embargo, la seguridad por construcción no es una varita mágica. Un servidor de solo lectura garantiza que los datos no se modifiquen, pero no protege contra otros riesgos igual de importantes. El primero es la divulgación de información: una herramienta de lectura como get_job puede exponer payloads que contengan tokens, direcciones de correo electrónico o identificadores internos. Estos datos, al ser procesados por el modelo y enviados a un servicio externo, podrían filtrar información sensible. Por tanto, es obligatorio sanear o filtrar los campos antes de devolverlos, y aplicar políticas de cifrado y control de acceso adicionales.
El segundo es el costo y la carga operativa. Una consulta de lectura puede ser costosa si recorre miles de trabajos sin paginación, o si un modelo decide ejecutar la misma herramienta en un bucle mientras 'explora'. Sin límites estrictos —tiempos de espera, paginación por defecto, topes de resultados— el servidor puede convertirse en un vector de denegación de servicio para la propia infraestructura. Por eso, junto con el modo de solo lectura, hay que implementar controles de uso: timeout en cada handler, límite de resultados por llamada, y un sistema de rate limiting a nivel de conexión.
El tercer riesgo es la inyección de segundo orden. Los datos que el modelo lee desde Redis pueden contener texto diseñado para influir en su comportamiento. Si el mismo modelo tiene acceso a otras herramientas (por ejemplo, para enviar correos o modificar registros en otra base de datos), leer una cola con payloads maliciosos podría desencadenar acciones no deseadas. Este riesgo no se resuelve con un servidor de solo lectura, sino con una arquitectura que segregue los contextos y límite el alcance de cada herramienta.
Por último, el alcance de la protección es por conexión, no global. Un sistema puede tener múltiples servidores MCP cargados: uno de solo lectura para consultas y otro con permisos completos para administración. Si ambos están disponibles para el mismo modelo, la protección del primero no evita que el modelo invoque herramientas del segundo. La seguridad por construcción debe aplicarse a cada conexión y cada servidor de forma independiente, y la arquitectura general debe asegurar que el modelo nunca tenga acceso simultáneo a ambos si se quiere un control estricto.
En definitiva, la lección es clara: cuando el interlocutor es un modelo de lenguaje, las barreras de seguridad no deben estar escritas en texto, sino soldadas en el cableado del sistema. La combinación de registro condicional, credenciales ACL y réplicas de solo lectura ofrece una defensa en profundidad que no depende de la buena fe del modelo. En Q2BSTUDIO ayudamos a las empresas a diseñar e implementar este tipo de arquitecturas, integrando soluciones de IA con sistemas legacy, automatización de procesos, y plataformas de Business Intelligence como Power BI. Porque la seguridad no es un adjetivo, es una propiedad del diseño.
