Una pregunta per a la propera reunió del comitè tècnic: quants servidors MCP hi ha configurats avui als portàtils del vostre equip, en quina versió i amb quines credencials? El més probable és que ningú no la sàpiga respondre. No perquè ningú no se n'hagi preocupat, sinó perquè no hi ha cap lloc on mirar-ho.
Un desenvolupador vol que el seu assistent llegeixi els tiquets del gestor de projectes. Busca el servidor MCP corresponent, copia quatre línies al fitxer de configuració de Claude Code, Cursor o VS Code, enganxa el seu token personal en una variable d'entorn i reinicia. Deu minuts. A partir d'aquell moment hi ha un programa d'un tercer executant-se a la seva màquina, amb la seva identitat, connectat a un sistema de l'empresa i a un model que decideix quan fer-lo servir. Ningú més no ho sap, i no per descuit: cap dels processos de l'empresa no estava pensat per assabentar-se'n.
La tesi d'aquesta peça és que l'error no és instal·lar servidors MCP, que són útils, sinó tractar-los com una extensió de l'editor. Un servidor MCP és una integració amb credencials, i la pregunta no és si és segur, sinó si es governa com la resta d'integracions. Avui gairebé mai no és així.
El que s'instal·la amb aquestes quatre línies
MCP (Model Context Protocol) és el protocol amb què un assistent d'IA es connecta a eines i dades externes. Un servidor MCP exposa aquestes eines: llegir el correu, consultar una base de dades, obrir un pull request. Molts s'executen en local, arrencats pel mateix client amb una ordre del tipus npx paquet-mcp, que descarrega el paquet del registre públic i l'engega.
La documentació de bones pràctiques de seguretat de la mateixa especificació ho diu sense embuts: els clients han d'avisar que els servidors MCP s'executen amb els mateixos privilegis que el client i, quan s'instal·len amb un clic, mostrar l'ordre exacta que s'executarà, sense retallar-la. És a dir, tenen accés al mateix que l'usuari: els seus fitxers, les seves claus SSH i les variables d'entorn amb els tokens de la resta de servidors.
I aquests tokens solen ser dels que tenen més abast. L'octubre de 2025, Astrix va analitzar 5.205 repositoris de servidors MCP: al voltant del 88% necessita credencials, el 53% es basa en claus d'API estàtiques o tokens personals d'accés, el 79% de les claus es passen com a simples variables d'entorn i només el 8,5% fa servir OAuth. Traduït: el normal és que un servidor MCP funcioni amb un token personal, de llarga durada, desat en text pla al portàtil d'algú.
Per què no el veu cap control
Una empresa mitjana té, encara que no en digui així, diversos filtres pels quals passa qualsevol integració nova. El servidor MCP els esquiva tots, i no per mala fe de ningú: simplement entra per una porta que aquests filtres no miren.
| Control habitual | Què revisa | Per què no veu el servidor MCP |
|---|---|---|
| Revisió de codi | El que entra al repositori | La configuració viu a la carpeta personal de l'usuari, no al repositori |
| Inventari de dependències | Els fitxers de bloqueig i l'SBOM del producte | El paquet no és una dependència del producte; sovint es descarrega sense versió fixada cada vegada que arrenca |
| Compres i proveïdors | Contractes i avaluacions de tercers | És gratuït i de codi obert: no hi ha cap factura que activi la revisió |
| Gestió d'identitats | Aplicacions connectades als comptes corporatius | Amb un token personal no es registra cap aplicació nova: el servidor actua com l'usuari |
| Política d'ús d'IA | Quins assistents i quines dades es poden fer servir | Sol aprovar l'assistent, no el que s'hi connecta |
Elaboració pròpia d'onext
L'última fila és la més freqüent. Moltes empreses ja tenen una política sobre quins assistents d'IA estan permesos, com la que proposàvem a shadow AI. Però aprovar Claude Code o Copilot diu poc sobre el que la gent hi connecta després. És com aprovar un navegador i no preguntar mai quines extensions té. OWASP n'ha posat nom a la seva llista de riscos específica de MCP: Shadow MCP Servers, el novè de deu.
Quatre errors reals, i cap no és del model
A la peça sobre injecció de prompts analitzàvem com un text hostil converteix un agent amb massa permisos en una fuita. Aquest risc existeix, però no és l'únic. Els quatre casos següents no necessiten que el model s'equivoqui en res. Fallen abans: en què s'ha instal·lat, d'on ha sortit i qui l'ha canviat.
El paquet que era legítim fins que va deixar de ser-ho. El setembre de 2025, Koi Security va trobar el que es considera el primer servidor MCP maliciós en circulació: postmark-mcp, un paquet d'npm que imitava la integració del servei de correu Postmark. Durant quinze versions va funcionar correctament. La 1.0.16, publicada el 17 de setembre, hi va afegir una línia que enviava en còpia oculta a una adreça de l'atacant tots els correus que en sortien. Segons CSO Online, el paquet tenia unes 1.500 descàrregues setmanals. Qui l'hagués revisat a la versió 1.0.15 l'hauria aprovat, i amb raó.
La descripció que l'usuari no veu. L'abril de 2025, Invariant Labs va descriure el tool poisoning: instruccions amagades a la descripció d'una eina, invisibles per a l'usuari però visibles per al model. Al mateix treball en descrivien dues variants: el rug pull, en què el servidor canvia la descripció després que l'usuari l'hagi aprovat, i el shadowing, en què un servidor maliciós manipula com es fan servir les eines d'un altre servidor de confiança. L'especificació de MCP en recull la lliçó: les descripcions de comportament de les eines s'han de considerar no fiables tret que vinguin d'un servidor de confiança.
La peça d'infraestructura que ningú no mira. El juliol de 2025, JFrog va publicar la CVE-2025-6514 a mcp-remote, un paquet que fa de pont per connectar clients locals amb servidors MCP remots: connectar-se a un servidor no fiable permetia executar ordres del sistema operatiu a la màquina de l'usuari. Puntuació CVSS de 9,6, i més de 437.000 descàrregues segons The Hacker News. Ningú no tria mcp-remote com a eina; ve de sèrie a les instruccions d'instal·lació de molts servidors.
El servidor oficial del proveïdor. Asana va llançar el seu servidor MCP l'1 de maig de 2025. El 4 de juny va detectar un error que podia exposar informació d'un client a usuaris d'altres organitzacions; el va desconnectar del 5 al 17 de juny i va avisar els clients afectats, uns mil segons va dir un portaveu a BleepingComputer. No era un paquet pirata ni un atac: era el servidor oficial, d'un proveïdor seriós, amb un error d'aïllament.
La fitxa de cada servidor
La conseqüència pràctica és tractar cada servidor MCP com qualsevol altra integració: amb una fitxa. No és la mateixa que la fitxa de permisos de cada eina que proposàvem per dissenyar un agent; aquella decideix què pot fer un sistema que algú ha dissenyat. Aquesta respon una pregunta anterior: què hi ha instal·lat a l'empresa, i de qui és.
| Camp | Què s'hi anota | Quin error talla |
|---|---|---|
| Origen | Qui publica el paquet i si és el proveïdor del sistema al qual es connecta | El paquet que imita una marca, com postmark-mcp |
| Versió fixada | Una versió concreta, mai «l'última»; les actualitzacions s'aproven | La versió 16 maliciosa d'un paquet amb quinze versions netes |
| Descripcions revisades | Les descripcions de les eines es llegeixen en aprovar i es comparen en actualitzar | El tool poisoning i el rug pull |
| Credencial pròpia | Un token emès per a aquest servidor, amb abast mínim i caducitat; mai el token personal d'algú | La mida de l'incident quan falla el servidor oficial, com a Asana |
| On s'executa | En local, amb els privilegis de l'usuari, o en remot, i a través de quins components | Les peces intermèdies que ningú no ha triat, com mcp-remote |
| Propietari | Una persona que respon del servidor i decideix les seves actualitzacions | L'avís de seguretat que arriba i ningú no sap a qui afecta |
Sis camps per servidor. Caben en un full de càlcul i es mantenen com qualsevol altre inventari
El quart camp mereix una línia a part, perquè l'especificació ja l'exigeix per als servidors remots. Des de la revisió de juny de 2025, i també a la vigent de juliol de 2026, l'autorització de MCP prohibeix l'anomenat token passthrough: un servidor MCP ha de validar que el token s'ha emès per a ell i no n'ha d'acceptar ni reenviar cap altre. La lògica de fons és la que apliquem a qualsevol integració: cada peça amb la seva credencial, perquè l'abast del token sigui l'abast de l'incident i prou. Copiar el token personal d'un administrador en una variable d'entorn és exactament el contrari.
Els dos primers camps són la mateixa disciplina que demanàvem per a les dependències que proposa un assistent: saber qui publica el que s'executa i no deixar que la versió canviï tota sola. La diferència és que aquí no hi ha ni tan sols un fitxer de bloqueig per revisar. Cal crear-lo.
El control és a la configuració administrada, no en un PDF
Una fitxa que només viu en un full de càlcul és documentació. Es converteix en control quan el client es nega a arrencar el que no hi és. Els clients principals ja ho permeten:
- Claude Code admet un fitxer
managed-mcp.json, desplegat per l'administrador en una ruta del sistema, amb llistes de servidors permesos i denegats i l'opció de permetre només els gestionats. - GitHub Copilot aplica llistes de servidors permesos i denegats des de la configuració gestionada de l'empresa a VS Code, la CLI i la seva aplicació. Ho va anunciar com a disponible de manera general el 6 d'agost de 2026; la primera versió, per a VS Code Insiders, era del setembre de 2025.
- Cursor permet, al pla Enterprise, que l'equip controli des del tauler d'administració quins servidors MCP poden fer servir els seus membres.
Gairebé un any entre la primera versió i la disponibilitat general en el cas de GitHub diu una cosa útil: els controls corporatius arriben després de l'adopció, no abans. Si l'equip fa des de 2025 que connecta servidors, la llista de permesos d'avui arriba sobre un parc instal·lat que ningú no ha inventariat. Per això l'ordre importa: primer l'inventari, després la llista.
I el registre oficial? El MCP Registry, llançat en preview el 8 de setembre de 2025, és un catàleg obert de servidors públics, útil per saber què existeix. Però la seva moderació funciona per denúncia: la comunitat assenyala els servidors maliciosos i els mantenidors els retiren després. No és una revisió de seguretat prèvia, i els autors ho diuen: preveuen subregistres privats a les empreses amb requisits estrictes. Aquest subregistre privat és, a la pràctica, la llista de fitxes de la taula anterior.
La lliçó incòmoda: la llista de permesos no n'hi ha prou
Seria còmode tancar aquí, amb la llista de permesos com a solució. Els mateixos casos ho desmenteixen. Una llista de permesos hauria aprovat postmark-mcp abans de la versió 1.0.16, i no hauria fet res contra l'error del servidor oficial d'Asana, que seria el primer de qualsevol llista. La llista decideix què s'instal·la. No decideix quina versió s'executa demà ni quant pot tocar quan falla.
Per això la fitxa té sis camps i no un. La versió fixada talla el primer cas; la credencial pròpia, amb l'abast mínim, limita el segon. Cap de les dues no depèn d'endevinar quin servidor és maliciós, que és justament el que ningú no pot fer el dia de la instal·lació. És la mateixa idea que recorre el mínim exigible de governança d'IA: controls que funcionen encara que falli la previsió.
I una advertència en l'altre sentit: prohibir MCP no és una alternativa. Els servidors són útils, i per això s'instal·len. Si el procés d'alta triga tres mesos, la gent continuarà connectant servidors en un altre client o amb el compte personal, i l'inventari tornarà a estar buit. L'objectiu no és frenar l'adopció, sinó que el camí aprovat sigui més còmode que la drecera: una llista inicial curta amb els servidors que ja es fan servir, versions fixades, credencials emeses per a cadascun i una alta que trigui dies. És la mateixa conclusió a la qual arribàvem en comparar Claude, Cursor i Copilot per a empreses: l'eina importa menys que el sistema que l'envolta.
Preguntes freqüents
Què és un servidor MCP i per què afecta la seguretat de l'empresa?
Un servidor MCP (Model Context Protocol) és un programa que dona a un assistent d'IA accés a una eina o a unes dades: el correu, el repositori, la base de dades, el CRM. En la majoria de casos s'instal·la afegint unes línies a un fitxer de configuració del portàtil i s'executa amb els mateixos permisos que l'usuari. És una integració amb credencials, i no passa per cap dels controls pels quals passen les altres integracions de l'empresa.
En què es diferencia un servidor MCP d'una dependència de codi?
Una dependència entra pel fitxer de bloqueig del projecte, es veu en un pull request i apareix a l'inventari de programari. Un servidor MCP viu a la configuració local de cada persona, fora del repositori, i sovint s'arrenca amb una ordre que descarrega l'última versió del paquet cada vegada. Té els mateixos riscos de cadena de subministrament que una dependència, però cap dels controls.
Què és el tool poisoning a MCP?
És un atac descrit per Invariant Labs l'abril de 2025: el servidor amaga instruccions a la descripció d'una eina, que l'usuari no veu i el model sí que llegeix. Una variant, el rug pull, consisteix a canviar aquesta descripció després que l'usuari hagi aprovat el servidor. Per això la mateixa especificació de MCP demana tractar les descripcions de les eines com a no fiables tret que vinguin d'un servidor de confiança.
Serveix el registre oficial de MCP per saber quins servidors són segurs?
No per si sol. El MCP Registry, llançat en preview el setembre de 2025, és un catàleg obert de servidors públics. La seva moderació es basa en el fet que la comunitat denunciï servidors maliciosos perquè es retirin després, no en una revisió de seguretat prèvia. Els mateixos autors preveuen que les empreses amb requisits estrictes tinguin subregistres privats amb la seva pròpia llista.
Com es limita quins servidors MCP pot fer servir l'equip?
Amb la configuració administrada de cada client, no amb una política en un document. Claude Code admet un fitxer managed-mcp.json amb llistes de servidors permesos i denegats; GitHub Copilot ofereix llistes de permesos a la configuració d'empresa, disponibles de manera general des de l'agost de 2026 per a VS Code, la CLI i la seva aplicació; i Cursor ho permet al pla Enterprise. La llista s'acompanya de versions fixades i d'un camí curt per demanar servidors nous.
Convé prohibir els servidors MCP?
No. Prohibir una cosa útil només la treu de la vista: la gent la continuarà fent servir amb el compte personal o en un altre client. El que funciona és un inventari, una llista curta de servidors aprovats amb la versió fixada i credencials pròpies, i un procés d'alta que trigui dies, no mesos. L'objectiu és que el camí aprovat sigui més còmode que la drecera.
Fonts
- Model Context Protocol, especificació revisió 2026-07-28: «Authorization» i «Security Best Practices».
- Luca Beurer-Kellner i Marc Fischer (Invariant Labs), «MCP Security Notification: Tool Poisoning Attacks», 1 d'abril de 2025.
- Tal Skverer (Astrix Security), «State of MCP Server Security 2025», 15 d'octubre de 2025.
- Postmark, «Information regarding malicious postmark-mcp package», 25 de setembre de 2025; Shweta Sharma, CSO Online, 26 de setembre de 2025; Ravie Lakshmanan, The Hacker News, 29 de setembre de 2025.
- JFrog Security Research, CVE-2025-6514 a mcp-remote, 9 de juliol de 2025; The Hacker News, 10 de juliol de 2025.
- Bill Toulas, «Asana warns MCP AI feature exposed customer data to other orgs», BleepingComputer, 18 de juny de 2025.
- OWASP, MCP Top 10 (beta, 2025) i Top 10 for Agentic Applications for 2026, 9 de desembre de 2025.
- David Soria Parra i altres, «Introducing the MCP Registry», 8 de setembre de 2025.
- Documentació d'administració: Claude Code, GitHub Copilot (6 d'agost de 2026) i Cursor.
Jordi García és Tech Lead a onext. Treballa a portar la IA a producció governada en equips de desenvolupament i de producte —amb Spec-Driven Development, enginyeria de context i verificació humana a cada pas— i signa els insights tècnics d'onext sobre mètode, qualitat i cost de la IA aplicada.
LinkedIn →