Quan desenvolupem sistemes que integren models de llenguatge (LLM) amb dades operatives, la temptació és confiar en instruccions textuals. Dir al model 'només lectura, no modifiquis' sembla suficient, però qualsevol enginyer que hagi treballat amb agents d'IA sap que una frase és només un suggeriment. Un model pot ignorar-la, ser manipulat per una injecció de prompt o simplement malinterpretar el context. Per això, a Q2BSTUDIO, quan abordem projectes que connecten intel·ligència artificial amb infraestructures reals, apliquem un principi fonamental: la seguretat ha d'estar al cablejat, no a la prosa.
Aquest article explora com construir un servidor MCP (Model Context Protocol) que garanteixi, per construcció, que un LLM només pugui llegir dades de Redis, sense cap possibilitat d'escriure, esborrar o modificar. És una lliçó de disseny que combina desenvolupament d'aplicacions a mida amb les millors pràctiques de ciberseguretat i arquitectura cloud.
El problema de confiar en descripcions
Imaginem un escenari típic: un agent d'IA necessita consultar una cua de treballs a Redis per informar del seu estat. La primera reacció és afegir a la descripció de l'eina 'només lectura, no modifiquis'. Però el model llegeix aquesta frase exactament igual que qualsevol altra: com una cadena de caràcters que pot seguir o no. Si un atacant injecta un payload maliciós en un treball, o si una cadena de raonament complexa porta al model a interpretar erròniament la instrucció, la restricció textual s'esvaeix. Les descripcions són documentació, no controls de permisos.
A Q2BSTUDIO hem après que, quan treballem amb serveis cloud com AWS o Azure, la seguretat ha d'escalar des del codi fins a la infraestructura. En el cas d'un servidor MCP, el punt de control no està a la descripció de l'eina, sinó en dos llocs concrets: la taula de registre d'eines i les credencials que utilitza el manejador.
Registre condicional d'eines
L'API de MCP permet al servidor exposar un conjunt d'eines. El client crida a tools/list i obté els noms i esquemes d'entrada. Quan el model vol actuar, envia tools/call amb un nom i arguments, i el servidor ho ruteja al manejador registrat. Si el nom no està registrat, la resposta és un error: 'eina desconeguda'.
La clau és que només registrem les eines de lectura. Per al nostre inspector de cues, definim quatre eines: list_queues, queue_stats, list_jobs i get_job. Les eines que muten l'estat, com retry_job o delete_job, només es registren si el servidor s'inicia sense el flag --read-only. Amb aquesta bandera activa, aquestes dues crides de registre mai s'executen, i el procés anuncia únicament les quatre eines de lectura. Així, encara que el model inventi o un payload maliciós intenti cridar a delete_job, la resposta serà immediatament un error. No hi ha manejador per executar.
Aquest enfocament és senzill, però robust. Un revisor pot confirmar que la ruta d'escriptura és absent simplement mirant el codi condicional, no confiant en una frase. A Q2BSTUDIO apliquem aquesta mateixa filosofia als nostres projectes d'intel·ligència artificial i agents: la seguretat es converteix en una propietat observable de l'arquitectura.
La segona barrera: credencials que no poden escriure
Registrar només eines de lectura és un bon primer pas, però els manejadors poden tenir errors, i un desenvolupador futur podria afegir una eina que modifiqui dades sense adonar-se'n. Per això afegim una segona capa: la credencial de Redis. Creem un usuari ACL que només té permisos de lectura, i revoquem comandaments perillosos fins i tot entre els de lectura, com KEYS, que pot escanejar tot l'espai de claus i alentir un servidor ocupat.
La configuració és clara: ACL SETUSER inspector on >secret ~* -@all +@read -@dangerous. Això atorga la categoria de comandaments de lectura, però -@dangerous elimina les trampes. Redis classifica GETEX i GETDEL com a escriptures, per tant +@read les exclou automàticament. Si un manejador intenta executar un comandament no permès, Redis el rebutja amb un error NOPERM. La base de dades mateixa es converteix en el respatller final.
Per a un control encara més estricte, es pot apuntar l'inspector a una rèplica de només lectura, que rebutja qualsevol escriptura amb un error READONLY. D'aquesta manera, apilem tres garanties: el model només veu eines de lectura a tools/list, una crida inventada o injectada a una eina d'escriptura no troba manejador, i els manejadors operen amb una credencial que físicament no pot escriure. Cap d'aquestes garanties depèn que el model es comporti bé.
Què no garanteix el mode només lectura
És important ser honest sobre els límits. El mode només lectura assegura que el model no pot modificar la nostra cua, però no significa que sigui segur exposar les dades. Eines com get_job retornen payloads que poden contenir tokens, correus electrònics o identificadors interns. Un model amb accés de lectura és una forma eficient de filtrar aquestes dades a un tercer. Per això, a Q2BSTUDIO sempre combinem aquestes arquitectures amb serveis de ciberseguretat per auditar i netejar la informació sensible abans d'exposar-la.
A més, una lectura pot ser costosa. Llistar tots els treballs pendents en una cua gran pot disparar la latència de producció, i un model pot cridar l'eina en bucle mentre 'explora'. Per això les eines han d'incloure paginació, límits estrictes i timeouts. Aquí també entra en joc el Business Intelligence: monitoritzar l'ús i el rendiment és clau per evitar sorpreses.
Un altre risc és la injecció de segon ordre. Les dades que llegim no són neutrals; un payload de treball pot contenir text dissenyat per influir en el model. Si aquest mateix model té accés a altres eines, llegir la nostra cua pot afectar les seves decisions en altres contextos. Fer que la nostra cua sigui no escribible no mitiga això. És una propietat del conjunt complet d'eines del model, no d'un sol servidor. I finalment, aquest disseny fa que un servidor individual sigui de només lectura per construcció, però no diu res sobre un host que tingui carregat un altre servidor amb capacitat d'escriptura. El radi d'explosió és per connexió, no global.
Conclusió: cablejat sobre paraules
Res d'això és revolucionari. És una aplicació disciplinada de principis bàsics d'enginyeria de programari: registrar només les eines que el mode ha d'exposar, mantenir les mutants darrere d'un interruptor de només lectura perquè mai entrin a la taula, i connectar amb una credencial que no pugui realitzar l'operació que es vol prevenir. Quan el que crida és un model de llenguatge, una frase acurada de 'només lectura, si us plau' és tractada com qualsevol altra cadena. Per això, a Q2BSTUDIO, deixem de gastar la frontera en frases i la col·loquem al cablejat, on es manté ferma tant si el model coopera com si no.
Per a les empreses que busquen integrar agents d'IA amb els seus sistemes de forma segura, aquest enfocament és un pilar. Ja sigui en projectes d'automatització de processos, anàlisi de dades amb Power BI o desplegaments al núvol, la seguretat per construcció és l'única via fiable. A Q2BSTUDIO, ajudem a dissenyar i implementar aquestes arquitectures, combinant desenvolupament d'aplicacions a mida amb intel·ligència artificial, ciberseguretat i cloud.
