Quan els agents d'intel·ligència artificial comencen a interactuar amb bases de dades operatives, el primer instint sovint és demanar-los amablement que no facin modificacions. Però confiar en una instrucció textual perquè un model de llenguatge es comporti correctament és com posar un cartell de 'no tocar' davant d'un nen curiós: funciona fins que el nen troba una manera de saltar-se'l. En el món de la integració entre sistemes i models d'IA, especialment quan parlem de cues de treball a Redis exposades a través del protocol MCP (Model Context Protocol), l'única manera real de garantir que un agent no alteri dades és eliminar físicament la possibilitat de fer-ho. Això és exactament el que proposem en aquest article: construir un servidor MCP de només lectura per a Redis on la seguretat no depèn del que el model 'entengui', sinó de com està cablejat el sistema.
El repte comença quan un equip vol que un assistent d'IA, per exemple, pugui inspeccionar l'estat d'una cua de processos per diagnosticar colls d'ampolla o localitzar treballs fallits. El natural és exposar eines de lectura com llistar cues, veure estadístiques, obtenir un treball concret. Però el mateix model que fa servir aquestes eines també podria, si se li demana o si una injecció de prompt ho indueix, intentar reencuar treballs o eliminar-los. Si l'eina per reencuar està registrada, encara que es digui al model que no la faci servir, el risc persisteix. La solució convencional seria afegir una validació al handler, però això segueix deixant la porta oberta a que un atac ben dirigit aconsegueixi cridar la funció. L'única forma robusta és no registrar aquestes eines en absolut quan el mode és només lectura.
Aquest enfocament, que anomenem 'seguretat per construcció', implica que la superfície d'atac es defineix en el moment d'arrencar el servidor MCP, no en la descripció de les eines ni en les instruccions del sistema. En separar la lògica de registre en dos blocs —les eines de lectura sempre presents, i les d'escriptura condicionades a una bandera— aconseguim que un servidor llançat amb el paràmetre --read-only mai tingui accés a les funcions que muten l'estat. Si el model, o un atacant que controla l'entrada, intenta invocar retry_job o delete_job, el mateix protocol retorna un error de 'eina desconeguda'. No hi ha handler a validar, no hi ha autorització a eludir: la ruta d'escriptura simplement no existeix en el procés.
Però el registre no és l'única capa. Per molt cuidat que estigui el codi, sempre existeix la possibilitat d'un error humà o d'una futura modificació que introdueixi una eina inadvertidament. Per això la segona barrera són les credencials amb les quals el servidor es connecta a Redis. En lloc d'usar un usuari amb permisos totals, és molt més segur configurar un usuari ACL (Access Control List) que només tingui accés a comandaments de lectura. Redis permet definir categories de comandaments: +@read habilita tots els comandaments de lectura, mentre que -@dangerous elimina aquells que, tot i ser lectures, poden ser perillosos —com KEYS, que escaneja tot l'espai de claus i pot bloquejar el servidor. Amb aquesta configuració, fins i tot si un handler conté un bug o un nou desenvolupador afegeix una eina d'escriptura sense adonar-se'n, Redis rebutjarà l'operació amb un error NOPERM. La base de dades mateixa actua com a guardià final.
Si es busca una línia encara més dura, es pot apuntar el servidor MCP cap a una rèplica de només lectura de Redis. En aquest cas, qualsevol intent d'escriptura, independentment del comandament o de l'usuari, rep un error READONLY. Aquesta opció és ideal quan no es pot modificar la configuració ACL o quan es vol una separació física total entre les operacions de lectura i escriptura.
Aquest disseny té implicacions directes en l'arquitectura de sistemes que integren agents d'IA amb infraestructures existents. A Q2BSTUDIO, empresa especialitzada en desenvolupament d'aplicacions a mida, apliquem aquest principi cada vegada que un client necessita connectar models de llenguatge a bases de dades en producció. No n'hi ha prou de dir-li al model 'només llegeix'; cal dissenyar el sistema perquè no pugui escriure. Això és especialment rellevant quan es treballa amb serveis cloud com AWS o Azure, on les credencials i els grups de seguretat han d'estar alineats amb el principi de mínim privilegi.
No obstant això, la seguretat per construcció no és una vareta màgica. Un servidor de només lectura garanteix que les dades no es modifiquin, però no protegeix contra altres riscos igualment importants. El primer és la divulgació d'informació: una eina de lectura com get_job pot exposar payloads que continguin tokens, adreces de correu electrònic o identificadors interns. Aquestes dades, en ser processades pel model i enviades a un servei extern, podrien filtrar informació sensible. Per tant, és obligatori sanejar o filtrar els camps abans de retornar-los, i aplicar polítiques de xifratge i control d'accés addicionals.
El segon és el cost i la càrrega operativa. Una consulta de lectura pot ser costosa si recorre milers de treballs sense paginació, o si un model decideix executar la mateixa eina en un bucle mentre 'explora'. Sense límits estrictes —temps d'espera, paginació per defecte, topalls de resultats— el servidor pot convertir-se en un vector de denegació de servei per a la mateixa infraestructura. Per això, juntament amb el mode de només lectura, cal implementar controls d'ús: un timeout a cada handler, un límit de resultats per crida, i un sistema de rate limiting a nivell de connexió.
El tercer risc és la injecció de segon ordre. Les dades que el model llegeix des de Redis poden contenir text dissenyat per influir en el seu comportament. Si el mateix model té accés a altres eines (per exemple, per enviar correus o modificar registres en una altra base de dades), llegir una cua amb payloads maliciosos podria desencadenar accions no desitjades. Aquest risc no es resol amb un servidor de només lectura, sinó amb una arquitectura que segregui els contextos i limiti l'abast de cada eina.
Finalment, l'abast de la protecció és per connexió, no global. Un sistema pot tenir múltiples servidors MCP carregats: un de només lectura per a consultes i un altre amb permisos complets per a administració. Si tots dos estan disponibles per al mateix model, la protecció del primer no evita que el model invoqui eines del segon. La seguretat per construcció s'ha d'aplicar a cada connexió i cada servidor de forma independent, i l'arquitectura general ha d'assegurar que el model mai tingui accés simultani a tots dos si es vol un control estricte.
En definitiva, la lliçó és clara: quan l'interlocutor és un model de llenguatge, les barreres de seguretat no han d'estar escrites en text, sinó soldades al cablejat del sistema. La combinació de registre condicional, credencials ACL i rèpliques de només lectura ofereix una defensa en profunditat que no depèn de la bona fe del model. A Q2BSTUDIO ajudem les empreses a dissenyar i implementar aquest tipus d'arquitectures, integrant solucions d'IA amb sistemes legacy, automatització de processos, i plataformes de Business Intelligence com Power BI. Perquè la seguretat no és un adjectiu, és una propietat del disseny.
