MCP de tercers: auditoria de 30 minuts abans de connectar-lo

Abans de connectar un servidor MCP de tercers al teu agent de codi, comprova en menys de mitja hora qui el manté i des de quan, quins permisos de fitxer, xarxa i shell reclama enfront dels que realment necessita, i si les seves descripcions d'eines poden injectar instruccions ocultes al model. Sense aquestes tres capes, el servidor llegeix les teves credencials amb els mateixos permisos que el teu agent.

Un servidor MCP no és una llibreria que importes i que executa codi en un sandbox del llenguatge: és un procés independent que el teu agent inicia i amb qui conversa per stdio o HTTP, i aquest procés hereta les variables d'entorn, el sistema de fitxers i la identitat de xarxa de qui l'ha llançat. Si el teu agent de codi corre amb el teu usuari del sistema i té accés a claus d'API, tokens de desplegament o credencials de bases de dades en variables d'entorn, el servidor MCP que connectes les pot llegir sense que el protocol ho impedeixi, perquè no defineix un límit d'aïllament per defecte. Això contrasta amb extensions de navegador o apps mòbils, que declaren permisos en un manifest que el sistema operatiu o la botiga revisen abans d'instal·lar. En MCP aquesta capa de revisió encara no existeix de forma estandarditzada: cada servidor decideix quines eines exposa i què pot fer cadascuna, i el client —el teu agent— confia en aquesta declaració. La majoria dels servidors MCP publicats en registres comunitaris no passen cap procés de signatura ni auditoria de codi abans d'aparèixer llistats. Connectar-ne un equival, en superfície d'atac, a donar permisos d'execució de codi arbitrari a un paquet d'npm o PyPI que ningú ha revisat, amb l'agreujant que aquest codi pot actuar directament sobre els teus sistemes en producció si l'agent té aquests accessos.

Divideix l'auditoria en tres blocs de deu minuts i no en saltis cap encara que el servidor sembli fiable a primera vista. El primer bloc mira qui ha escrit el codi i des de quan; el segon mira què pot fer aquest codi un cop connectat al teu agent i com aïllar-lo; el tercer defineix com el desconnectaràs si alguna cosa surt malament. Cap dels tres substitueix els altres: un mantenidor de confiança pot publicar un servidor amb permisos excessius per descuit, i un servidor amb permisos mínims pot venir d'un compte creat la setmana passada per robar credencials de desenvolupadors que confien que 'sembla un projecte seriós'. Aquest ordre importa perquè cada bloc filtra riscos diferents i barats de detectar abans d'invertir temps en el següent. Si el servidor falla el primer bloc, no continuïs: no hi ha configuració d'aïllament que compensi un codi d'origen dubtós. Guarda els resultats dels tres blocs en un document breu perquè no hagis de repetir tota l'auditoria cada vegada que un altre membre de l'equip vulgui fer servir el mateix servidor.

Minut 0-10: procedència i superfície de codi

• Repositori públic amb historial de commits real, no un únic commit inicial amb tot el codi ja escrit.
• Mantenidor identificable amb activitat prèvia, no un perfil creat la mateixa setmana que el paquet.
• Llicència declarada i dependències llistades a package.json o requirements.txt sense ofuscar.
• Sense binaris precompilats que no tinguin el codi font corresponent al repositori.
• Issues de seguretat oberts revisats un per un, no només els que apareixen tancats sense explicació.

Minut 10-30: què demana, què pot tocar i com aïllar-lo

• Llista exacta d'eines (tools) que exposa el servidor i quins arguments accepta cadascuna.
• Si alguna eina permet executar shell, escriure fora d'un directori de treball acotat, o fer peticions HTTP sortints sense llista blanca de dominis.
• Grep de process.env / os.environ al codi font per veure quines variables d'entorn llegeix en arrencar.
• Trucades sortints a dominis de telemetria o analytics no documentats al README.
• Si demana credencials amb més abast del que necessita la tasca, com un token d'administrador quan només cal lectura.
• Executa'l primer en un contenidor o VM separada de l'entorn amb credencials reals, mai a la mateixa màquina que l'agent en producció.
• Usa credencials d'abast mínim i revocables mentre duri la prova, i defineix per endavant com matar-lo si alguna cosa surt malament.

Hi ha un patró que cap checklist de 'permisos en instal·lar' captura: el rug pull d'eines MCP. Un servidor pot superar la teva auditoria inicial amb una definició d'eina inofensiva i, setmanes després, amb una actualització silenciosa de versió, canviar la descripció o el comportament d'aquesta mateixa eina sense que el teu agent torni a demanar aprovació, perquè la majoria de clients MCP només confirmen la primera vegada que veuen un nom d'eina, no cada vegada que canvia la seva definició. Això significa que auditar un servidor MCP no és un esdeveniment únic d'instal·lació, sinó que exigeix fixar la versió —pin de versió o hash del paquet— i revisar el diff abans de cada actualització, igual que faries amb una dependència crítica de producció. El mateix protocol no obliga a signar versions ni a notificar canvis de forma verificable, així que la responsabilitat de detectar-ho recau completament en qui l'ha instal·lat. Un simple hash del paquet guardat juntament amb la data d'auditoria n'hi ha prou per saber, mesos després, si el que corre avui és el mateix que vas aprovar aleshores. A la pràctica, molt pocs equips tracten els seus servidors MCP amb el mateix rigor de control de versions que apliquen a les seves dependències de backend, precisament perquè la promesa de MCP és la instal·lació sense fricció, i aquí hi ha la tensió real del protocol.

No recomanem auditar amb el mateix nivell de profunditat cada servidor MCP que un equip prova. Si ho féssiu, ningú faria servir MCP: la fricció mataria l'eina que se suposa que estalvia temps. El que sí defensem és classificar per nivell de risc abans de decidir quant temps invertir a revisar cadascun.

Aquesta guia de 30 minuts té sentit per a un servidor MCP que tindrà accés a credencials de producció, al teu repositori de codi amb permisos d'escriptura, o a sistemes de clients. No té sentit aplicar-la igual a un servidor MCP que només consulta la documentació pública d'una llibreria, corre en un entorn de proves sense secrets reals, o l'uses cinc minuts per a un experiment personal que després desinstal·les. Tractar cada instal·lació com si fos un desplegament a producció genera fatiga de seguretat: l'equip deixa d'auditar res perquè auditar-ho tot és inviable, que és exactament el resultat contrari al que es busca. Nosaltres mateixos, en proves internes ràpides, saltem passos d'aquest checklist quan l'entorn està completament desconnectat de dades reals, no per mandra, sinó perquè el risc real en aquest cas és pràcticament zero. La clau està a decidir, abans d'instal·lar res, quins accessos tindrà l'agent que fa servir aquest MCP, i reservar l'auditoria completa per als casos on aquests accessos inclouen alguna cosa que no et pots permetre perdre.

• Classifiquem el servidor pel nivell d'accés que tindrà: només lectura de documentació, escriptura en repositoris, o accés a producció.
• Revisem el codi font complet quan tocarà credencials o infraestructura real, no només el README.
• El provem primer en un entorn aïllat, sense connexió als sistemes del client.
• Documentem quines eines exposa i fixem la versió abans de donar llum verda per a ús continuat.