L'adopció d'agents intel·ligents en entorns empresarials avança a un ritme vertiginós. Tanmateix, moltes organitzacions cauen en l'error de confondre el protocol amb el control. El Model Context Protocol (MCP) s'ha consolidat com l'estàndard perquè els agents descobreixin i invoquin capacitats empresarials, però no s'ha de tractar com el cervell del sistema. En aquest article, des de l'experiència de Q2BSTUDIO, explorem per què MCP ha de ser el pla d'eines (tool plane) i no el controlador de l'agent (agent controller), i com dissenyar una arquitectura de control que garanteixi seguretat, governança i escalabilitat.
Imaginem un ecosistema on un agent d'IA pot consultar bases de dades, executar scripts al núvol, enviar correus i modificar registres. MCP proporciona una interfície estandarditzada perquè l'agent descripti, invoqui i rebi resultats d'aquestes capacitats. Però quan l'agent proposa una acció —per exemple, reiniciar un servidor en producció—, el protocol per si sol no pot decidir si aquesta acció està autoritzada, si està dins del pressupost o si requereix aprovació humana. Aquí és on entra el pla de control de l'agent (Agent Control Plane).
La separació conceptual és clara: l'agent proposa, el controlador autoritza, MCP transporta la interacció governada, i el runtime executa i verifica. Aquesta distinció és crítica per evitar que un error del model o un atac d'injecció de prompts comprometi tota la infraestructura empresarial. A desenvolupament d'aplicacions a mida, apliquem aquest principi per construir sistemes on l'autoritat resideix en serveis de confiança, no en la capa de raonament de l'agent.
MCP estandarditza el descobriment d'eines, l'accés a recursos, la negociació de capacitats i els contractes d'entrada/sortida. Aquestes característiques el converteixen en un excel·lent pla d'eines empresarial. No obstant això, no ha d'assumir responsabilitats com la gestió d'estats de flux de treball, l'autorització basada en polítiques empresarials, els pressupostos de costos (incloent crides a models, reintents i APIs externes), la detecció de bucles infinits, la verificació de postcondicions o la compensació d'efectes secundaris. Tot això pertany a un controlador d'agent dissenyat com un servei a part.
A Q2BSTUDIO, quan treballem en projectes de cloud AWS/Azure, implementem capes de control que validen cada proposta de l'agent abans d'invocar qualsevol eina MCP. El controlador coneix el context complet de l'usuari, la identitat autenticada, l'abast dels seus permisos, l'entorn (producció, staging, desenvolupament), les polítiques de seguretat vigents i els límits de despesa. Només després d'aquesta validació, el controlador genera un 'sobre d'execució' que inclou tant el que l'agent va proposar com les metadades d'autoritat: clau d'idempotència, identificador de traça, versió de política i evidència d'aprovació (si es requereix). Aquest sobre s'envia al runtime, que l'executa a través de la capa MCP, i verifica el resultat contra el sistema de registre original.
Un dels errors més comuns és permetre que l'agent ompli camps com 'entorn: producció' o 'usuari: admin' dins dels arguments de l'eina. El model no pot provar que aquests valors siguin legítims. L'arquitectura segura separa les dades de proposta (agent) de les dades d'autoritat (runtime). El controlador no ha de copiar mai camps de la proposta al sobre d'autoritat sense validació independent. Per exemple, l'agent pot suggerir 'entorn: producció', però el controlador ha de consultar l'estat del flux de treball per determinar si producció és el destí aprovat.
MCP també introdueix conceptes com Tasks (experimental) i anotacions d'eines. Les Tasks permeten gestionar operacions de llarga durada amb estats (pendent, en progrés, completat, cancel·lat). Però no reemplacen un motor de flux de treball empresarial. Un Task MCP pot reportar l'estat d'una exportació de dades, però no decideix si aquesta exportació s'ha d'executar en paral·lel amb una altra, si necessita un compensador quan falla o si ha d'esperar una aprovació de dues persones. De la mateixa manera, les anotacions (readOnly, destructive, idempotent) són pistes, no controls de seguretat. Un servidor MCP compromès o amb un defecte pot etiquetar una operació com de només lectura quan en realitat modifica dades.
En la pràctica, des de la perspectiva de ciberseguretat, recomanem tractar les eines MCP com a interfícies controlades. El controlador ha de mantenir un registre de servidors MCP aprovats, amb el seu propietari, versió, revisions de seguretat i entorns permesos. Les eines s'han d'exposar dinàmicament segons el context: un agent de només lectura no ha de veure eines d'escriptura. A més, és crucial que els tokens d'autenticació siguin audiència-específics: el token que el client MCP presenta al servidor ha de ser vàlid només per a aquell servidor, i mai s'ha de reenviar a una API descendent sense transformació.
Un altre aspecte fonamental és la verificació independent de resultats. Un 'èxit' retornat per una eina MCP no prova que el resultat empresarial esperat s'hagi produït. Per exemple, si l'agent sol·licita eliminar un registre i el servidor MCP retorna 'success', el runtime ha de consultar el sistema de registre per confirmar que el registre ja no existeix, i emmagatzemar aquesta evidència. Això és especialment important en implementacions de BI/Power BI, on les decisions basades en dades recentment modificades poden propagar errors si no es verifica la integritat de la font.
El flux complet d'una sol·licitud governada comença amb l'agent que interpreta la intenció de l'usuari i construeix una proposta (operació, recurs objectiu, pla d'execució, alternatives). Aquesta proposta s'envia al controlador, que avalua la identitat, les polítiques, els pressupostos i les aprovacions necessàries. Si tot està en ordre, el controlador construeix el sobre d'execució amb l'autoritat i el passa al runtime. El runtime selecciona el servidor MCP adequat (d'entre els registrats i filtrats), invoca l'eina amb els arguments validats, recull la resposta estructurada i executa les comprovacions de postcondició. Finalment, el resultat es retorna al controlador, que actualitza l'estat del flux de treball i, si cal, dispara el següent pas o notifica l'usuari.
Aquesta arquitectura no només millora la seguretat, sinó que també facilita el canvi de model d'IA o de framework d'agents sense haver de refer tota la capa d'integració. MCP actua com un bus d'eines estandarditzat, mentre que el controlador i el runtime són serveis independents que poden evolucionar per separat. A Q2BSTUDIO, apliquem aquest disseny en projectes d'automatització de processos i automatització de processos amb agents, aconseguint que les decisions crítiques quedin sempre en mans de components deterministes i auditables.
Els modes de fallada principals que cal dissenyar contra inclouen: proliferació de servidors MCP sense control, exposició excessiva d'eines a tots els agents, injecció de prompts a través de resultats d'eines, eines massa potents (com executar SQL arbitrari), confusió de credencials (el servidor MCP que reenvia el token del client a un sistema descendent sense canviar la seva audiència), i falsa confiança derivada de l'estandardització (creure que perquè el protocol és estàndard, l'operació és segura).
Per evitar-los, recomanem mantenir un catàleg d'eines dinàmic basat en la identitat del sol·licitant, el tipus de tasca, l'entorn i el nivell de risc; validar cada proposta abans de la invocació MCP; requerir claus d'idempotència generades pel controlador per a operacions repetibles; verificar postcondicions contra sistemes autoritatius; i mantenir un registre de totes les decisions (aprovades, denegades, pendents d'aprovació, pressupost excedit, conflicte d'estat, etc.).
En conclusió, MCP és un pilar fonamental per a la interoperabilitat d'agents empresarials, però no ha de ser el controlador del sistema. L'arquitectura robusta separa el raonament (agent), l'autoritat (controlador), el transport governat (MCP) i l'execució verificada (runtime). Cada capa té responsabilitats diferents i no s'han de barrejar. Des de Q2BSTUDIO, impulsem aquesta visió perquè les empreses puguin desplegar agents d'IA amb confiança, sabent que cada acció està controlada, traçada i recolzada per l'autoritat adequada. Si la teva organització està avaluant com integrar agents intel·ligents en els seus processos, et convidem a contactar amb el nostre equip per dissenyar junts una arquitectura de control adaptada a les teves necessitats.
