La integració de la intel·ligència artificial als processos empresarials ha accelerat l’adopció del Model Context Protocol (MCP), però amb ella sorgeixen reptes d’autorització que van més enllà d’afegir una pantalla d’inici de sessió a cada servidor. En aquest article explorem com dissenyar una arquitectura d’autorització empresarial per a MCP utilitzant Identity Providers (IdP), control d’accés basat en rols (RBAC) i el flux Zero-Touch OAuth, mantenint un enfocament pràctic i adaptable a entorns reals.
L’error principal que cometen moltes organitzacions és tractar l’autorització de MCP com un problema de connectivitat. Quan un equip exposa una eina de cerca, un repositori de codi o un flux de treball d’infraestructura a través d’un servidor MCP, la temptació és delegar tota la seguretat en un client que demana credencials a l’usuari. Això funciona en laboratoris, però en un entorn empresarial amb desenes de servidors, centenars d’usuaris i múltiples clients d’IA, la descentralització genera inconsistències en les polítiques, dificulta l’auditoria i exposa a riscos de privilegis excessius.
La solució no és complicar l’accés, sinó centralitzar l’autoritat de decisió. Aquí entra el concepte d’Enterprise-Managed Authorization, una extensió estable del protocol MCP que permet que l’IdP corporatiu sigui el punt central de política. En lloc de que cada servidor MCP demani consentiment per separat, l’usuari s’autentica una vegada en un client aprovat, i l’IdP emet una asserció d’identitat destinada al servidor MCP específic i als abasts sol·licitats. Aquest flux, anomenat Zero-Touch OAuth, elimina la fricció sense sacrificar el control.
Perquè aquesta arquitectura funcioni en producció, cal distingir quatre identitats: la humana (empleat), la del client MCP (aplicació aprovada), la de la càrrega de treball (agent o procés automatitzat) i la del servidor MCP (recurs protegit). Barrejar-les en una única identitat genèrica d''agent' condueix a privilegis excessius i poca traçabilitat. Per exemple, un enginyer de programari pot utilitzar un assistent de codi aprovat per llegir un repositori, però no hauria de poder escriure canvis des d’un navegador no gestionat ni utilitzar el mateix token per executar fluxos de producció.
El RBAC continua sent la base, però no és suficient. Assignar rols com mcp.source_control.reader o mcp.incident.responder proporciona un vocabulari estable que no depèn de noms de grups de directori que poden canviar. Sobre aquesta base, les polítiques contextuals (estat del dispositiu, ubicació, nivell d’autenticació) estrenyen l’accés. I a nivell de recurs, el sistema de registre downstream, ja sigui un repositori Git, un ERP o un servei al núvol, ha de validar els permisos natius de l’usuari o la càrrega de treball.
Un aspecte crucial és la identitat de càrregues de treball no humanes. Els agents autònoms, els pipelines de CI/CD i els treballs programats no haurien d’utilitzar credencials d’usuari. L’extensió OAuth Client Credentials de MCP, combinada amb assercions JWT signades i fonts d’identitat com clústers de Kubernetes, AWS IAM Roles Anywhere o SPIFFE, permet que cada càrrega de treball tingui una identitat pròpia i limitada. Recomanem segmentar per entorn i propòsit: un agent de remediació en producció no ha de compartir identitat amb un revisor de codi en desenvolupament. Un model de nomenclatura com prod/agents/incidents/executar-runbook-aprovat facilita l’auditoria i l’aïllament d’incidents.
La política d’autorització ha d’avaluar molt més que la pertinença a un grup. Un tuple típic inclou: usuari + client MCP + servidor MCP + abast sol·licitat + força d’autenticació + estat del dispositiu + entorn + risc + moment + estat d’excepció. Aquest enfocament evita que un grup genèric com 'Usuaris d’IA' concedeixi accés a totes les eines. A més, els abasts han de ser estrets i reflectir les operacions reals: tools.list, repository.read, change.propose, change.execute. No existeix un abast que es pugui dir mcp.full_access sense trencar el principi de mínim privilegi.
A la nostra experiència ajudant empreses a implementar aquestes arquitectures des de Q2BSTUDIO, la clau està en començar amb un pilot petit: un client MCP aprovat, un servidor de només lectura, abasts limitats i tokens de curta durada. Un cop validats els fluxos de denegació i auditoria, s’afegeixen càrregues de treball no interactives i posteriorment eines d’alt risc amb aprovació explícita. La integració amb serveis al núvol com AWS o Azure permet escalar la gestió d’identitats i polítiques de forma nativa.
La ciberseguretat en aquest context exigeix protegir els tokens i les assercions: mai no s’han d’incloure al context del model d’IA ni en logs que puguin exposar-se. Les decisions d’autorització s’han de registrar juntament amb l’usuari, la càrrega de treball, el client, el servidor, l’eina invocada i el recurs downstream. Això és especialment rellevant quan parlem d’agents d’IA que poden encadenar múltiples trucades a eines; cada pas ha de ser auditat per separat.
Un altre punt que sovint es passa per alt és la revocació. Tot i que l’IdP centralitzat permet desactivar usuaris en minuts, la finestra real de revocació depèn de la vida del token, la memòria cau del client i el suport d’introspecció. Recomanem establir objectius mesurables, per exemple: després de l’eliminació d’un rol privilegiat, qualsevol nova trucada d’alt risc ha de ser denegada en menys de cinc minuts.
Des de la perspectiva d’intel·ligència de negoci, la integració de MCP amb fonts de dades com Power BI o bases de dades al núvol permet consultes naturals a través d’agents, però requereix que el servidor MCP validi els permisos de fila i columna abans de retornar dades. Aquí és on el RBAC s’ha de combinar amb polítiques d’accés a nivell de registre, i on Q2BSTUDIO ofereix solucions de BI que respecten aquestes jerarquies de seguretat.
En resum, l’autorització empresarial MCP no és un producte que s’instal·la, sinó una arquitectura que es dissenya. Separar identitats, centralitzar la política a l’IdP, utilitzar RBAC com a base, aplicar controls contextuals, assignar identitats de càrrega de treball segmentades i auditar cada decisió són els pilars. El flux Zero-Touch OAuth facilita l’experiència de l’empleat, però no elimina la responsabilitat de l’arquitecte de definir què, qui, com i quan. A Q2BSTUDIO, ajudem les organitzacions a construir aquest model des de l’estratègia fins a la implementació, integrant automatització intel·ligent i governança sense comprometre l’agilitat.
