L'agent d'IA no sortirà al teu registre: hi sortirà qui li va deixar el token

La frase amb la qual això entra en una empresa és «és només un connector». Algú endolla l'assistent al SharePoint, a l'ERP o al sistema de tiquets, i el que es discuteix a la reunió és què sabrà fer. El que no es discuteix és amb quina identitat ho farà. La resposta, quan el connector es munta amb pressa, acaba sent: amb la teva.

No cal imaginar-se ningú actuant de mala fe perquè això acabi malament. N'hi ha prou que d'aquí a tres mesos algú obri el registre d'auditoria del sistema de destinació, vegi una descàrrega gran a les tres de la matinada d'un dissabte i llegeixi, al costat, el nom d'una persona que estava dormint. Ningú no ha mentit. El token va fer exactament allò per al qual es va emetre, i el registre va apuntar exactament a qui hi figurava. La investigació comença per la persona equivocada perquè el disseny ho va decidir així mesos abans, una tarda en què ningú no pensava en registres.

Això no és una opinió nostra: és escrit a la norma, en majúscules

L'estàndard obert sobre el qual s'està construint bona part d'aquella connexió es diu Model Context Protocol (MCP). No és l'únic camí —hi ha API REST directa, connectors natius de fabricant i plataformes d'integració—, però és el que s'està imposant com a terreny comú. La seva especificació es versiona per data, i la revisió vigent a dia d'avui és la 2026-07-28. La vam llegir sencera perquè hi havia una cosa que ens interessava comprovar: què diu exactament sobre les credencials. Diu força, i ho diu amb el vocabulari normatiu dels RFC, aquell en què MUST i MUST NOT no són suggeriments.

A l'apartat de gestió de tokens de l'especificació d'autorització hi ha tres frases seguides que valen per tot l'article. L'última és aquesta: «MCP servers MUST NOT accept or transit any other tokens». Els servidors no han d'acceptar ni fer de trànsit de cap altre token. I al document de bones pràctiques de seguretat hi ha una secció amb nom propi, «Token Passthrough», catalogada literalment com a anti-pattern, que acaba amb una única línia de mitigació: «MCP servers MUST NOT accept any tokens that were not explicitly issued for the MCP server».

Aquí va el que ens sembla a nosaltres, dit com a lectura pròpia: una norma no dedica una secció sencera, amb la seva llista de riscos i la seva mitigació, a prohibir una cosa que ningú no fa. L'antipatró està descrit amb aquell detall perquè és el camí curt. Reenviar el token que ja tens és una línia de codi; demanar-ne un de propi per al connector implica registrar una aplicació, donar-li identitat, decidir permisos i explicar-ho a algú. Quan el sprint va just, ja se sap quin dels dos guanya.

El paràgraf que hauria de llegir qui signa el compliment

El més útil d'aquella secció és la llista de per què, que ve darrere de la prohibició. Un dels blocs es titula «Accountability and Audit Trail Issues» —problemes de rendició de comptes i de traça d'auditoria— i conté aquesta frase, que traduïm i deixem també en original perquè és la que sosté el titular d'aquest article:

«The downstream Resource Server’s logs may show requests that appear to come from a different source with a different identity, rather than the MCP server that is actually forwarding the tokens.»

Els registres del servidor de destinació poden mostrar peticions que semblen venir d'un origen diferent, amb una identitat diferent, en lloc del servidor MCP que en realitat està reenviant els tokens.

— MCP Security Best Practices, revisió 2026-07-28.

Convé separar dues coses que s'assemblen i no són el mateix, perquè un lector tècnic objectarà aquí i té raó a objectar. Una és el reenviament de token: el connector accepta un token que no es va emetre per a ell i el passa tal qual al sistema de destinació. Això és el que la norma prohibeix. L'altra és l'accés delegat, en què l'aplicació té identitat pròpia i actua en nom de una persona amb el seu consentiment. És un mode legítim, és a totes les plataformes i allà és correcte que el nom de la persona aparegui al registre. La queixa de l'especificació no és que hi surti un usuari: és que no hi surti també l'intermediari, perquè el token que arriba a baix és opac i la destinació no pot distingir qui el va presentar.

D'aquí surt la nostra lectura, i la marquem com a tal: quan l'intermediari no hi consta, la investigació d'un incident comença per la persona equivocada. La part bona és que això no s'ha de discutir en cap reunió, perquè es comprova en deu minuts: que algú faci que l'agent llegeixi un document, i després obre el registre d'auditoria del sistema de destinació i mira quin nom hi ha. Si l'agent no hi apareix enlloc, ja tens la resposta. És la prova més barata de tot aquest article i la deixem un altre cop al final, perquè és l'única que cal fer sí o sí.

La mateixa secció adverteix d'una cosa més, que convé llegir a poc a poc: si el servidor passa tokens sense validar-ne els claims —rols, privilegis, audiència—, «un actor maliciós en possessió d'un token robat pot fer servir el servidor com a proxy per exfiltrar dades». I encapçala la llista amb la circumval·lació de controls: els límits de cabal, la validació de peticions i la monitorització de trànsit que tinguis muntats solen dependre de l'audiència del token o d'altres restriccions de la credencial. Amb l'audiència equivocada, aquells controls es queden sense aplicar.

És el mateix error de categoria del qual parlàvem fa uns dies a propòsit d'un privilegi de base de dades que es concedeix pel seu nom i no pel que permet: la decisió es pren mirant l'etiqueta —«connector», «integració», «només lectura»— en comptes de mirar l'abast. La diferència és que allà qui s'equivocava era un administrador llegint una paraula; aquí qui s'equivoca és el registre, que és l'única eina que tens per reconstruir què va passar.

El connector que corre a la teva màquina no fa OAuth. La norma diu que no en faci

Tot això aplica als connectors que parlen per HTTP. Però una part gran del que hi ha instal·lat avui no parla per HTTP: parla per stdio, és a dir, és un procés que el client arrenca a la mateixa màquina i amb el qual s'entén per l'entrada i la sortida estàndard. Per a aquests, l'apartat de requisits del protocol és d'una claredat incòmoda: «Implementations using an STDIO transport SHOULD NOT follow this specification, and instead retrieve credentials from the environment».

Traduït al que hi ha en una empresa: aquell connector no té consentiment, ni audiència, ni abast, ni caducitat. Té l'entorn de la màquina que el va arrencar. El .env amb la clau de l'API. El kubeconfig del portàtil. El sòcol de l'agent SSH. La variable amb el token d'accés personal al repositori que algú hi va posar «per provar» al març. El mateix document de bones pràctiques, a la secció sobre servidors locals, demana als clients que avisin l'usuari que «els servidors MCP corren amb els mateixos privilegis que el client», i arriba a posar com a exemple d'ordre d'arrencada maliciosa un curl que envia ~/.ssh/id_rsa a una URL aliena.

Ja vam escriure sobre aquesta família de sorpreses quan explicàvem que bloquejar l'agent SSH desactivava precisament les restriccions que li havies posat. El patró es repeteix: l'eina que sosté les credencials té un comportament per defecte que ningú no ha llegit, i el comportament per defecte sempre va en la direcció que les coses funcionin, no en la que estiguin tancades.

El permís per defecte és «tot el que hi hagi»

Suposem que el connector sí que fa les coses bé i demana el seu propi token. Queda decidir per a què. L'especificació té un apartat anomenat «Scope Selection Strategy» amb un ordre de prioritat de dos punts. El primer: fer servir el paràmetre scope que el servidor hagi posat a la capçalera WWW-Authenticate de la seva resposta 401. El segon, literal: «If scope is not available, use all scopes defined in scopes_supported from the Protected Resource Metadata document».

Ara la part que cal posar al costat per no fer trampa, perquè l'esglaó ve acotat. La frase següent de la mateixa especificació diu que scopes_supported «està pensat per representar el conjunt mínim de permisos necessaris per a la funcionalitat bàsica», i que la resta es demana després per elevació, quan una operació concreta ho reclama. I el document de bones pràctiques, a la seva secció de minimització de permisos, explica per què existeix aquell segon esglaó: els clients MCP són de propòsit general i no tenen el coneixement de domini necessari per triar permisos pel seu compte, de manera que l'especificació prefereix que la decisió la prenguin el servidor d'autorització i la persona a la pantalla de consentiment. És un repartiment de responsabilitat fet a consciència, i enviar el paràmetre scope és un SHOULD per al servidor, no un MUST.

El que ens sembla a nosaltres és que aquell repartiment té un destinatari real, i no és el que un s'imagina. Qui decideix l'abast és qui prem «Permetre». A la majoria d'empreses que coneixem, aquella persona no és el responsable de seguretat: és qui estava muntant el connector un dimarts a la tarda, amb la pantalla plena de permisos que no havia demanat i un botó verd. I la mateixa especificació sap que el catàleg sol estar inflat, perquè la seva secció de minimització de permisos obre la llista d'errors comuns amb aquest: «publicar tots els permisos possibles a scopes_supported», seguit de «fer servir permisos comodí o òmnibus (*, all, full-access)». La regla està ben escrita. El catàleg és el que gairebé mai no està a l'alçada de la regla.

I sí, l'SDK oficial ha tingut el seu

Hi ha una suposició que gairebé ningú no enuncia en veu alta quan es munta un assistent corporatiu: que si dos empleats parlen amb el mateix assistent, el que veu l'un no ho veu l'altre. Aquella suposició té data de caducitat documentada. El 4 de febrer de 2026 es va publicar l'avís GHSA-345p-7cg4-v4c7, CVE-2026-25536, sobre l'SDK oficial de TypeScript (@modelcontextprotocol/sdk). Puntuació 7,1, vector CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:N. Afecta des de la 1.10.0 fins a la 1.25.3 inclosa; s'arregla a la 1.26.0.

El que feia són dues coses, i totes dues són de reutilització. La primera: quan una sola instància de StreamableHTTPServerTransport atén peticions de diversos clients, els identificadors de missatge JSON-RPC xoquen i les respostes s'encaminen a la connexió HTTP equivocada. La segona: quan una sola instància d'McpServer es connecta a diversos transports, la referència interna this._transport se sobreescriu en silenci, cosa que arrossega respostes finals, notificacions de progrés i peticions de mostreig. En cristià: la resposta d'una persona podia acabar a la pantalla d'una altra.

Convé no exagerar-ho, i ho diem nosaltres que som els qui ho estem explicant. És un 7,1, amb impacte baix en integritat. El vector porta PR:L, que a l'escala CVSS significa que l'atacant necessita privilegis d'usuari bàsic; la nostra lectura d'això, en aquest escenari concret, és que l'atacant és l'altre empleat amb la seva sessió legítima. No hi ha constància pública d'explotació, i està arreglat des del febrer. El que ens sembla útil de la dada és una altra cosa: la separació entre usuaris, que tothom dona per feta, va ser de la 1.10 a la 1.25.3 una propietat del codi i no una garantia del protocol. I que hi ha una pregunta molt concreta i molt barata —«quina versió de l'SDK corre allò?»— que gairebé ningú no fa.

Les set preguntes que fem abans de connectar res

Nosaltres automatitzem amb IA i ens hi guanyem la vida, així que això no és un article en contra. Tenim n8n autoallotjat corrent tasques internes —entre elles la publicació a LinkedIn per webhook— i el tractem com el que és: un servei de producció, inventariat, amb amo i amb finestra d'actualització. Aquesta és la llista que passem abans de donar a alguna cosa automàtica una credencial nostra o d'un client.

1. Amb quina identitat actua? Si la resposta conté el nom d'una persona, parem. Un agent necessita identitat pròpia al directori, amb el seu nom, el seu amo i la seva data de revisió. És més feina. És la feina.
2. Quina audiència porta el token? Si el connector reenvia el mateix token que li dona el client cap a l'API de destinació, està fent exactament el que la norma prohibeix en majúscules. El token cap amunt i el token cap avall són dos tokens diferents, i és així per disseny.
3. Quins permisos va demanar de debò? No el que diu el README: el que va sortir a la pantalla de consentiment i el que figura avui a l'aplicació registrada del directori. Els dos llocs, perquè no sempre coincideixen.
4. On corre i amb quin entorn? Si és stdio, hereta l'entorn del procés que l'arrenca. Aleshores la pregunta deixa de ser sobre el connector i passa a ser sobre la màquina: quines claus hi ha en aquell entorn i qui més hi pot arrencar processos.
5. Quina versió de l'SDK? Per al de TypeScript, 1.26.0 o superior. I amb el número apuntat en algun lloc que no sigui la memòria de qui el va instal·lar.
6. Com s'apaga, i qui l'apaga un dissabte? Un interruptor que només sap accionar la persona que el va muntar no és un interruptor. Ja vam explicar com acaba això a el pilot d'IA que ningú no va apagar: no s'apaguen per decisió, s'apaguen quan algú hi ensopega.
7. Surt al registre amb el seu nom? Prova d'acceptació, sense discussió teòrica: que algú faci que l'agent llegeixi alguna cosa, i després obrir el registre d'auditoria del sistema de destinació i buscar qui hi apareix. Si hi apareix una persona, ja tens el diagnòstic i el tens en deu minuts.

Quan diem que no

Hi ha tres situacions en què recomanem no connectar l'agent, encara que el projecte estigui venut i la demostració hagi agradat. La primera: quan l'única integració disponible és de les que reenvien el token i no hi ha manera de demanar-ne un de propi. Això és construir sobre un antipatró amb nom propi i esperar que el dia de l'incident els registres diguin alguna cosa útil. La segona: quan ningú no sap respondre qui és l'amo de l'agent d'aquí a sis mesos. Un servei sense amo no es manté; s'acumula. La tercera: quan el que hi ha a l'altre costat és un conjunt de dades amb obligacions —expedients de personal, historials, dades de menors— i l'agent demanaria permís de lectura sobre tot el repositori perquè és l'única cosa que ofereix la pantalla.

Dir que no a temps surt barat. Dir-ho tard també té la seva estadística: ja vam escriure sobre la previsió que quatre de cada deu projectes d'agents en empresa es cancel·lin; segons aquella previsió, el pes el portaven el cost i el risc mal calculats per endavant, no la tecnologia. Aquesta conversa, la de amb quina identitat actua, és exactament una d'aquelles que és baratíssima abans i caríssima després. És el que diem aquí des de fa anys amb altres paraules: la fallada és inevitable, l'avaria és una decisió de disseny. Un registre que assenyala qui no va ser no és mala sort; és una decisió que algú va prendre un dimarts sense saber que la prenia.

Nota de fonts

Fonts primàries que hem llegit nosaltres. L'especificació del Model Context Protocol a modelcontextprotocol.io. La pàgina de versionatge ens dona la revisió vigent, 2026-07-28. De l'especificació d'autorització d'aquella revisió surten: el requisit de transport STDIO («Implementations using an STDIO transport SHOULD NOT follow this specification, and instead retrieve credentials from the environment»), l'apartat de gestió de tokens («MCP servers MUST NOT accept or transit any other tokens» i l'obligació de validar que el token es va emetre per al mateix servidor, segons RFC 8707) i la «Scope Selection Strategy» amb el seu ordre de prioritat de dos punts, inclosa la segona opció de fer servir tots els permisos de scopes_supported i la frase immediatament posterior segons la qual aquell camp ha de ser el conjunt mínim necessari per a la funcionalitat bàsica. L'explicació de per què existeix aquell segon esglaó —clients de propòsit general sense coneixement de domini, decisió delegada al servidor d'autorització i a la pantalla de consentiment— no és a l'especificació d'autorització sinó al document de bones pràctiques, a la seva secció de minimització de permisos. D'aquell mateix document de bones pràctiques de seguretat surten la secció «Token Passthrough» —amb la seva línia de mitigació i la llista de riscos, de la qual citem la frase sobre els registres del servidor de destinació i la del token robat fet servir com a proxy d'exfiltració—, la secció de compromís de servidors MCP locals —d'on vénen l'avís que corren amb els mateixos privilegis que el client i l'exemple d'ordre maliciosa amb ~/.ssh/id_rsa— i la llista d'errors comuns de la secció de minimització de permisos.

Vulnerabilitat. De CVE-2026-25536 prenem de l'avís GHSA-345p-7cg4-v4c7 de la base de dades d'avisos de GitHub el títol, la data de publicació (4 de febrer de 2026), la puntuació 7,1, el vector CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:N, el rang afectat (>= 1.10.0, <= 1.25.3), la versió corregida (1.26.0) i la descripció dels dos problemes: la col·lisió d'identificadors de missatge JSON-RPC en reutilitzar una instància de StreamableHTTPServerTransport entre clients, i la sobreescriptura silenciosa de this._transport en connectar una instància d'McpServer a diversos transports. Que no hi hagi constància pública d'explotació és, a data d'avui, el que hem pogut comprovar; no és una garantia.

El que és lectura nostra i no de les fonts. La més important, i la que sosté el titular: l'especificació es queixa que el servidor MCP no aparegui als registres de la destinació; el salt d'aquí a «la investigació comença per la persona equivocada» el fem nosaltres. També són nostres: que una especificació no prohibeixi en majúscules el que ningú no fa, i que per tant el reenviament de tokens sigui freqüent; que el destinatari real del repartiment de responsabilitat sobre els permisos sigui qui prem «Permetre» i no el responsable de seguretat; la lectura de PR:L com «l'altre empleat» en aquest escenari; la lectura que la separació entre usuaris era una propietat del codi i no una garantia del protocol; les set preguntes i els tres casos en què recomanem no connectar. Les citacions es donen en l'original anglès; quan apareixen en català, la traducció és nostra. L'escenari de la descàrrega del dissabte de matinada és un exemple il·lustratiu construït per nosaltres, no un incident concret d'un client. Sobre casa nostra: l'n8n autoallotjat i el seu ús per a tasques internes i publicació a LinkedIn és nostre. Tot s'ha contrastat el 12 de setembre de 2026.

Fotografia de portada: «Network equipment and cables organized in a server rack at a modern office environment during the afternoon», de Shixart1985, publicada a Wikimedia Commons sota llicència Creative Commons CC BY 2.0. L'hem retallada i hi hem superposat els textos de marca.