Cuando desarrollamos sistemas que integran modelos de lenguaje (LLM) con datos operativos, la tentación es confiar en instrucciones textuales. Decirle al modelo 'solo lectura, no modifiques' parece suficiente, pero cualquier ingeniero que haya trabajado con agentes de IA sabe que una frase es solo una sugerencia. Un modelo puede ignorarla, ser manipulado por una inyección de prompt o simplemente malinterpretar el contexto. Por eso, en Q2BSTUDIO, cuando abordamos proyectos que conectan inteligencia artificial con infraestructuras reales, aplicamos un principio fundamental: la seguridad debe estar en el cableado, no en la prosa.
Este artículo explora cómo construir un servidor MCP (Model Context Protocol) que garantice, por construcción, que un LLM solo puede leer datos de Redis, sin posibilidad alguna de escribir, borrar o modificar. Es una lección de diseño que combina desarrollo de aplicaciones a medida con las mejores prácticas de ciberseguridad y arquitectura cloud.
El problema de confiar en descripciones
Imaginemos un escenario típico: un agente de IA necesita consultar una cola de trabajos en Redis para informar de su estado. La primera reacción es añadir en la descripción de la herramienta 'solo lectura, no modifiques'. Pero el modelo lee esa frase exactamente igual que cualquier otra: como una cadena de caracteres que puede o no seguir. Si un atacante inyecta un payload malicioso en un trabajo, o si una cadena de razonamiento compleja lleva al modelo a interpretar erróneamente la instrucción, la restricción textual se desvanece. Las descripciones son documentación, no controles de permisos.
En Q2BSTUDIO hemos aprendido que, cuando trabajamos con servicios cloud como AWS o Azure, la seguridad debe escalar desde el código hasta la infraestructura. En el caso de un servidor MCP, el punto de control no está en la descripción de la herramienta, sino en dos lugares concretos: la tabla de registro de herramientas y las credenciales que utiliza el manejador.
Registro condicional de herramientas
La API de MCP permite al servidor exponer un conjunto de herramientas. El cliente llama a tools/list y obtiene los nombres y esquemas de entrada. Cuando el modelo quiere actuar, envía tools/call con un nombre y argumentos, y el servidor lo rutea al manejador registrado. Si el nombre no está registrado, la respuesta es un error: 'herramienta desconocida'.
La clave está en que solo registramos las herramientas de lectura. Para nuestro inspector de colas, definimos cuatro herramientas: list_queues, queue_stats, list_jobs y get_job. Las herramientas que mutan el estado, como retry_job o delete_job, solo se registran si el servidor se inicia sin el flag --read-only. Con esa bandera activa, esas dos llamadas de registro nunca se ejecutan, y el proceso anuncia únicamente las cuatro herramientas de lectura. Así, aunque el modelo invente o un payload malicioso intente llamar a delete_job, la respuesta será inmediatamente un error. No hay manejador que ejecutar.
Este enfoque es simple, pero robusto. Un revisor puede confirmar que la ruta de escritura está ausente simplemente mirando el código condicional, no confiando en una frase. En Q2BSTUDIO aplicamos esta misma filosofía en nuestros proyectos de inteligencia artificial y agentes: la seguridad se convierte en una propiedad observable de la arquitectura.
La segunda barrera: credenciales que no pueden escribir
Registrar solo herramientas de lectura es un buen primer paso, pero los manejadores pueden tener errores, y un desarrollador futuro podría añadir una herramienta que modifique datos sin darse cuenta. Por eso añadimos una segunda capa: la credencial de Redis. Creamos un usuario ACL que solo tiene permisos de lectura, y revocamos comandos peligrosos incluso entre los de lectura, como KEYS, que puede escanear todo el espacio de claves y ralentizar un servidor ocupado.
La configuración es clara: ACL SETUSER inspector on >secret ~* -@all +@read -@dangerous. Esto otorga la categoría de comandos de lectura, pero -@dangerous elimina las trampas. Redis clasifica GETEX y GETDEL como escrituras, por lo que +@read las excluye automáticamente. Si un manejador intenta ejecutar un comando no permitido, Redis lo rechaza con un error NOPERM. La base de datos misma se convierte en el respaldo final.
Para un control aún más estricto, se puede apuntar el inspector a una réplica de solo lectura, que rechaza cualquier escritura con un error READONLY. De esta forma, apilamos tres garantías: el modelo solo ve herramientas de lectura en tools/list, una llamada inventada o inyectada a una herramienta de escritura no encuentra manejador, y los manejadores operan con una credencial que físicamente no puede escribir. Ninguna de estas garantías depende de que el modelo se comporte bien.
Qué no garantiza el modo solo lectura
Es importante ser honesto sobre los límites. El modo solo lectura asegura que el modelo no puede modificar nuestra cola, pero no significa que sea seguro exponer los datos. Herramientas como get_job devuelven payloads que pueden contener tokens, correos electrónicos o identificadores internos. Un modelo con acceso de lectura es una forma eficiente de filtrar esos datos a un tercero. Por eso, en Q2BSTUDIO siempre combinamos estas arquitecturas con servicios de ciberseguridad para auditar y limpiar la información sensible antes de exponerla.
Además, una lectura puede ser costosa. Listar todos los trabajos pendientes en una cola grande puede disparar la latencia de producción, y un modelo puede llamar a la herramienta en bucle mientras 'explora'. Por eso las herramientas deben incluir paginación, límites estrictos y timeouts. Aquí también entra en juego el Business Intelligence: monitorizar el uso y el rendimiento es clave para evitar sorpresas.
Otro riesgo es la inyección de segundo orden. Los datos que leemos no son neutrales; un payload de trabajo puede contener texto diseñado para influir en el modelo. Si ese mismo modelo tiene acceso a otras herramientas, leer nuestra cola puede afectar sus decisiones en otros contextos. Hacer que nuestra cola sea no escribible no mitiga eso. Es una propiedad del conjunto completo de herramientas del modelo, no de un solo servidor. Y por último, este diseño hace que un servidor individual sea de solo lectura por construcción, pero no dice nada sobre un host que tenga cargado otro servidor con capacidad de escritura. El radio de explosión es por conexión, no global.
Conclusión: cableado sobre palabras
Nada de esto es revolucionario. Es una aplicación disciplinada de principios básicos de ingeniería de software: registrar solo las herramientas que el modo debe exponer, mantener las mutantes detrás de un interruptor de solo lectura para que nunca entren en la tabla, y conectar con una credencial que no pueda realizar la operación que se quiere prevenir. Cuando el llamante es un modelo de lenguaje, una frase cuidadosa de 'solo lectura, por favor' es tratada como cualquier otra cadena. Por eso, en Q2BSTUDIO, dejamos de gastar la frontera en frases y la colocamos en el cableado, donde se mantiene firme tanto si el modelo coopera como si no.
Para las empresas que buscan integrar agentes de IA con sus sistemas de forma segura, este enfoque es un pilar. Ya sea en proyectos de automatización de procesos, análisis de datos con Power BI o despliegues en la nube, la seguridad por construcción es la única vía confiable. En Q2BSTUDIO, ayudamos a diseñar e implementar estas arquitecturas, combinando desarrollo de aplicaciones a medida con inteligencia artificial, ciberseguridad y cloud.
