En l'ecosistema actual d'intel·ligència artificial empresarial, els agents autònoms estan transformant la forma en què les organitzacions automatitzen processos, prenen decisions i accedeixen a sistemes crítics. El protocol Model Context Protocol (MCP) s'ha consolidat com un estàndard per connectar aquests agents amb eines i servidors externs. No obstant això, governar correctament el gateway i el servidor MCP és un repte que va molt més enllà d'establir una connexió tècnica. En aquest article explorarem com les empreses poden implementar una capa de control robusta per als seus agents d'IA, integrant solucions d'aplicacions a mida amb les millors pràctiques de seguretat i governança.
El gateway MCP no és un participant natiu del protocol, sinó un patró de desplegament empresarial que actua com a frontera de polítiques entre el controlador de l'agent i els servidors MCP. La seva funció principal és garantir que només els servidors aprovats, les eines permeses i les credencials adequades intervinguin en cada interacció. En un entorn productiu amb desenes de servidors, múltiples entorns (desenvolupament, proves, producció) i diferents sistemes d'identitat, l'absència d'una governança centralitzada pot derivar en fuites de dades, execucions no autoritzades o errors d'auditoria.
Una de les primeres decisions arquitectòniques és establir un catàleg privat de servidors MCP. A diferència d'un registre públic, que només verifica metadades i propietat de l'espai de noms, el catàleg empresarial ha d'incloure l'artefacte exacte (hash del contenidor, commit d'origen, endpoint remot), la classificació de risc de cada eina, les identitats requerides i les condicions d'aprovació. A Q2BSTUDIO recomanem que el procés d'admissió verifiqui no només la identitat del publicador, sinó també el comportament real del servidor en un entorn controlat. Una eina que llegeixi registres acotats es pot classificar com de baix risc, mentre que una que executi ordres shell o accedeixi a dades sensibles requerirà revisions addicionals.
L'exposició d'eines ha de ser dinàmica i basada en context. El gateway no ha de proporcionar al model la llista completa d'eines disponibles, sinó només aquelles que corresponguin a l'agent, la tasca, l'entorn i el nivell de risc. Per exemple, un flux de diagnòstic només necessita eines de només lectura; una acció correctiva pot requerir una eina d'escriptura després d'una aprovació explícita. Aquesta filtració per sol·licitud evita que el model tingui accés innecessari a capacitats perilloses. A més, el gateway ha de mantenir una identitat interna única per a cada eina, incloent l'identificador del servidor i la versió, per evitar col·lisions de noms entre servidors diferents.
La governança d'esquemes és un altre pilar crític. Cada eina MCP té un esquema d'entrada i, opcionalment, de sortida. El gateway ha de validar que les sol·licituds compleixin l'esquema aprovat, rebutjant propietats addicionals no previstes. Un esquema massa permissiu, com 'additionalProperties': true, permet que el model inventi paràmetres que la revisió original mai va considerar. A Q2BSTUDIO apliquem esquemes explícits amb restriccions de format, enumeracions i longituds màximes, i a més verifiquem que els resultats estructurats compleixin l'esquema de sortida. No obstant, la validació sintàctica no és suficient: el servidor MCP ha de realitzar la seva pròpia validació de negoci, com comprovar si el recurs sol·licitat pertany al inquilí correcte o si l'operació està permesa en la finestra de manteniment actual.
La separació d'identitats és essencial per a la seguretat i l'auditabilitat. Un mateix flux involucra l'usuari sol·licitant, l'agent, el gateway, el client MCP, el servidor i el sistema de destí. Col·lapsar totes aquestes identitats en un sol token compartit debilita el control d'accés i dificulta la traçabilitat. La pràctica recomanada és que el gateway emeti credencials separades per a cada capa, utilitzant intercanvi de tokens delegats, identitats de càrrega de treball o credencials de curta durada. El token d'entrada al servidor MCP ha de tenir un públic específic (el servidor) i no s'ha de reenviar aigües avall. A més, el model mai ha de seleccionar ni proporcionar credencials. En els nostres projectes d'IA, implementem polítiques d'identitat que diferencien clarament entre el subjecte humà i la identitat de l'agent, permetent auditories detallades de cada acció.
L'enrutament és una decisió de seguretat, no només tècnica. El gateway no ha d'acceptar destinacions arbitràries proporcionades pel model, com URLs o noms de host. En lloc d'això, ha de resoldre identificadors interns aprovats cap a endpoints concrets, segons l'entorn, la regió i el nivell de confiança del servidor. Una sol·licitud de producció només s'ha de dirigir a una instància de servidor aprovada per a producció. A més, les connexions sortints han de passar per polítiques d'egrés que restringeixin dominis, rangs IP, requisits TLS i límits de velocitat. Els servidors locals, encara que s'executin al mateix host que l'agent, han d'estar aïllats mitjançant contenidors, sistemes de fitxers de només lectura i denegació de xarxa sortint per defecte.
El servidor MCP segueix sent un punt de control de domini independent. El gateway pot autoritzar l'ús d'una eina, però el servidor ha de validar l'estat del recurs, les regles de negoci i les precondicions. Per exemple, el gateway permet cridar restart.service en producció, però el servidor pot denegar-la si hi ha un desplegament actiu o si el servei està marcat com a no interrompible. Aquesta separació de responsabilitats evita que un error en la política del gateway comprometi tot el sistema. A més, els errors s'han de retornar amb contractes estructurats que indiquin si el fall és reintentable, l'estat dels efectes secundaris i una identificació de correlació. La decisió de reintentar ha de basar-se en codi de confiança, no en la interpretació del model.
L'observabilitat ha d'anar més enllà de registrar noms d'eines i temps de resposta. Cada traça ha de connectar la sol·licitud original amb l'ID d'execució del controlador, la identitat de l'usuari, la versió de l'agent, la política aplicada, el catàleg d'eines visible, el hash del contracte, la ruta seleccionada i el resultat final. No obstant, capturar arguments i resultats complets pot exposar dades sensibles. Per això, a Q2BSTUDIO dissenyem sistemes de telemetria amb redacció de camps segons classificació, ús d'identificadors hashejats i emmagatzematge separat per a evidències forenses.
El cicle de vida d'un servidor MCP no acaba amb la seva aprovació inicial. Canvis en el publicador, el paquet, les eines, els esquemes, les credencials o els destins de xarxa han d'activar una revalidació. Un servidor aprovat en desenvolupament no s'ha de promocionar a producció sense passar per les mateixes comprovacions. La reversió a una versió anterior ha de ser possible i provada. De la mateixa manera, la retirada d'un servidor ha d'eliminar la seva entrada del catàleg, les credencials associades i les polítiques d'enrutament. Un servidor depreciat amb un token encara vàlid segueix sent un risc.
Implementar una governança efectiva del gateway i servidor MCP requereix combinar diversos elements: control d'admissió, catàleg privat, filtratge dinàmic d'eines, separació d'identitats, governança d'esquemes, enrutament controlat, aïllament d'execució, contractes d'error estructurats, telemetria granular i gestió del cicle de vida. A Q2BSTUDIO, com a empresa especialitzada en desenvolupament de programari a mida, ajudem les organitzacions a dissenyar i implementar aquestes capes de control sobre plataformes cloud com AWS i Azure, integrant solucions de ciberseguretat i Business Intelligence amb Power BI per monitoritzar el comportament dels agents. El resultat és un ecosistema d'agents IA robust, auditable i preparat per a l'empresa.
En conclusió, el gateway MCP governa la connexió; el servidor fa complir el domini; el controlador autoritza el flux de treball; i el sistema empresarial protegeix el recurs. Cap senyal de confiança aïllada (registre públic, esquema vàlid, token OAuth) és suficient. La confiança en producció només sorgeix quan es combinen control d'artefactes, aprovació per eina, identitat de mínim privilegi, validació de domini, aïllament en temps d'execució, detecció de canvis i verificació operativa. Adoptar aquesta arquitectura permetrà a les empreses escalar els seus agents d'IA amb seguretat i confiança.
