Tu servidor MCP es seguro. El libro mayor que hay detrás, no.

En un artículo reciente publicado aquí, en Unite.AI, Gil Feig expuso seis buenas prácticas para crear un servidor MCP seguro. Son acertadas, y cualquiera que implemente un servidor MCP debería seguirlas. Su recomendación de asignar a cada integración «su propio rol detallado, limitado estrictamente a los permisos necesarios» es totalmente acertada. También presupone que el sistema del otro extremo dispone de roles detallados. Esto apunta a una suposición más amplia que rara vez se expresa: que los sistemas detrás del servidor pueden protegerse con el mismo nivel de seguridad.

En el software empresarial, a menudo no es posible. Dirijo el equipo de ingeniería responsable de una capa de integración que se conecta a 32 sistemas de contabilidad y ERP, con un servidor MCP opcional encima. A menudo vemos agentes que, de nuestro lado, están bien autenticados, tienen permisos bien delimitados y cuentan con registros adecuados, pero que escriben en sistemas incapaces de saber siquiera que intervino un agente.

Este artículo trata de esa segunda parte del problema: qué ofrecen realmente los sistemas de origen, qué se puede controlar desde la capa de integración y dónde termina ese control.

Dónde termina la especificación MCP

La especificación de autorización de MCP define claramente sus propios límites. El servidor MCP es un servidor de recursos OAuth para sus clientes. Cuando llama a una API de origen, actúa como un cliente OAuth independiente, con un token distinto emitido por el sistema de origen. Está expresamente prohibido reenviar el token del cliente.

Ese es el diseño correcto. También significa que todo lo relacionado con la llamada al sistema de origen —incluidos quién puede hacer qué y cómo queda registrado— depende por completo de dicho sistema. La especificación no puede resolver lo que el sistema de origen no ofrece.

Lo mismo ocurre con las directrices de OWASP sobre el exceso de autonomía. Recomiendan limitar al mínimo necesario los permisos que tienen las extensiones de un agente en otros sistemas y ejecutar las acciones en el contexto del usuario en cuyo nombre actúan. Ambas recomendaciones son acertadas. Las dos presuponen que el otro sistema permite definir los permisos mínimos y el contexto del usuario.

Qué ofrecen realmente los sistemas de origen

Así son, desde la perspectiva de un integrador, los 32 sistemas de contabilidad y ERP a los que nos conectamos.

Un tercio no ofrece OAuth

21 de los 32 usan OAuth. Los otros 11 dependen de credenciales estáticas: claves de API, nombre de usuario y contraseña, o un par de tokens. Algunas de esas claves nunca caducan. Un sistema de uso extendido documenta que sus tokens de API tienen una vigencia ilimitada mientras exista el usuario.

Vigencia prolongada, pocas opciones de revocación

OAuth ayuda menos de lo que cabría esperar. Un proveedor emite tokens de actualización con una vigencia de aproximadamente 20 años. Se trata de una credencial diseñada para durar más que el agente que la utiliza, el marco de trabajo en el que se creó el agente y, muy probablemente, la persona que hizo clic en «permitir». En otro sistema, ni siquiera caducan los tokens de acceso.

Y, una vez que una credencial está en circulación, la pregunta es quién puede desactivarla. El estándar para hacerlo, la revocación de tokens OAuth (RFC 7009), existe desde 2013. Sin embargo, aproximadamente cuatro de cada diez sistemas no ofrecen al integrador ningún medio técnico para revocar credenciales. Todos los sistemas que usan claves de API forman parte de ese grupo. La única opción restante es pedirle al cliente que elimine el acceso manualmente.

Permisos generales, sin identidad del agente

La mayoría de las claves estáticas heredan sin más todos los permisos del usuario que las creó; solo unos pocos sistemas permiten restringir una clave a puntos de conexión específicos. Muchos sistemas OAuth tienen ámbitos, pero suelen ser generales, del tipo «contabilidad: lectura y escritura». Y en ninguno de los 32 sistemas encontramos una forma de registrar mediante la API, en una misma transacción, tanto al agente como a la persona en cuyo nombre actúa. Los agentes externos aparecen como el usuario que los conectó o como un usuario genérico del sistema. Es revelador que, cuando un proveedor incorpora agentes en su propio producto, como ha hecho Microsoft en Business Central, les asigne cuentas de usuario específicas. Es el mismo enfoque que recomiendo más adelante, aunque reservado únicamente a los agentes del propio proveedor.

Qué puede imponer la capa de integración

Esto no significa que haya que darse por vencido. Entre el agente y el sistema de contabilidad, se puede controlar casi todo:

• credenciales por agente para acceder a la propia capa
• ámbitos propios, por ejemplo, acceso de solo lectura a las facturas
• un registro de auditoría de cada llamada del agente, con la persona en cuyo nombre actuó
• claves de idempotencia para que un agente que reintenta una operación no registre dos veces la misma factura
• límites de frecuencia por agente
• pasos de aprobación antes de cualquier escritura

Nada de esto depende de las funciones que admita el sistema de destino. Hoy es posible contar con una capa de acceso eficaz en el nivel de integración y, si se permite que los agentes se acerquen a datos financieros, debería crearse una.

Dónde termina

Lo que no se puede hacer es extender esa capa más allá de los límites del sistema. Ahí fallan tres cosas.

Atribución

Dentro del sistema de contabilidad, la operación del agente aparece como realizada por quien autorizó la conexión o por un usuario técnico. Quien audite ese sistema verá un asiento registrado por ese usuario. No podrá saber si lo hizo una persona o un agente. Para el libro mayor, un agente que registra 400 facturas a las 3:00 a. m. es indistinguible de un gerente de finanzas muy diligente. Para reconstruir lo ocurrido, hay que consultar los registros del integrador, que pertenecen a una cadena de confianza distinta de la del sistema de registro. En una investigación forense o una auditoría, eso nos deja en una posición débil.

La mayoría de las organizaciones tampoco está más avanzada en este aspecto. En una encuesta de Cloud Security Alliance, solo el 28 % de las personas encuestadas afirmó que podía rastrear de forma fiable las acciones de los agentes hasta una persona o un sistema en todos los entornos, y el 44 % usa o planea usar claves de API estáticas para sus agentes.

Privilegio mínimo

Se puede imponer que un agente solo lea facturas. Pero si el sistema de destino no tiene ámbitos, las credenciales que hay detrás de la capa siguen teniendo acceso total. Quien las obtenga podrá eludir por completo la capa y todas las reglas que hayas definido en ella.

Revocación

Puedes desactivar tu propio agente al instante. Eso no sirve de nada si se han vulnerado las credenciales del propio sistema de destino. Y, en los cuatro de cada diez sistemas que no tienen un punto de conexión para la revocación, el interruptor de emergencia es un correo electrónico al cliente.

La solución práctica: un usuario exclusivo para el agente

Lo más útil que puedes hacer hoy no tiene nada de glamuroso: crear un usuario exclusivo para el agente en el sistema de destino y conectarlo únicamente a través de ese usuario.

Funciona en todos los sistemas que permiten crear usuarios y aporta tres cosas que la capa de integración no puede ofrecer:

• Atribución en el sistema de registro. Los asientos aparecen como «agente de cuentas por pagar», no como si los hubiera registrado el gerente de finanzas que hizo clic en «conectar» hace seis meses.
• Una vía de revocación, incluso sin una API para ello. El cliente puede desactivar el usuario desde la interfaz, lo que funciona incluso en sistemas que no ofrecen un punto de conexión para la revocación.
• Privilegio mínimo parcial. Cuando el sistema cuenta con algún modelo de roles, a menudo se puede limitar al usuario del agente a los módulos que realmente necesita.

Los costos son reales. Alguien tiene que crear el usuario manualmente durante la incorporación, lo que añade fricción justo en el peor momento. Cerca de la mitad de los sistemas cobran por cada usuario adicional, desde unos pocos euros al mes en herramientas para pequeñas empresas hasta más de cien euros en un ERP completo. Varios otros limitan la cantidad de usuarios según el plan, así que añadir uno puede implicar contratar un plan más caro para toda la empresa. Además, un usuario de servicio del que nadie se responsabiliza se convierte en un riesgo por sí mismo y pasa a formar parte de la proliferación de identidades no humanas que Unite.AI ya ha abordado. Como cualquier otra cuenta, necesita una persona responsable y una fecha de revisión.

Tampoco resuelve la falta de ámbitos en los sistemas que no los tienen. Pero devuelve la atribución y la revocación al sistema que realmente consultan los auditores.

La solución estructural: identidad delegada

La solución correcta ya existe sobre el papel. Intercambio de tokens OAuth 2.0 (RFC 8693) distingue entre suplantación y delegación. Con la delegación, el agente conserva su propia identidad y el token registra que actúa en nombre de una persona mediante la declaración «act».

Aplicado a la contabilidad, esto significaría lo siguiente:

• el libro mayor registra que este agente hizo el asiento en nombre de esta persona
• los ámbitos se conceden para cada delegación, no para cada usuario
• se puede revocar una delegación concreta sin modificar la cuenta de la persona

Por lo que pude averiguar, ninguno de los 32 sistemas admite algo parecido. Así que, por ahora, sigue siendo una meta, no una opción. Esto convierte la propuesta en una petición para los proveedores de software de contabilidad y ERP, no en una tarea para los integradores: los agentes ya están registrando operaciones en los libros mayores, y sus API deberían poder indicarlo.

Qué hacer antes de que un agente acceda a un libro mayor

Si conectas agentes a sistemas de contabilidad o ERP, sigue esta breve lista de comprobación:

1. Identifica el modelo de credenciales de cada sistema de destino. ¿Usa OAuth o una clave estática? ¿Cuánto tiempo dura la credencial? ¿Tiene ámbitos? ¿Se puede revocar?
2. Implementa igualmente tu propia capa de acceso. La identidad por agente, los ámbitos, la idempotencia y las aprobaciones son responsabilidad de tu lado, independientemente de lo que ofrezca el sistema de destino.
3. Usa un usuario exclusivo para el agente siempre que el sistema lo permita. Asume el esfuerzo de incorporación y el costo de la licencia como el precio de la atribución.
4. Mantén un registro de auditoría propio que permita detectar cualquier manipulación. En muchos sistemas, será el único registro de que intervino un agente.
5. Documente el riesgo residual. Si un sistema no ofrece ámbitos de autorización ni revocación, dígaselo a su cliente y anótelo en su propio registro de riesgos.

El límite es la clave

Proteger su servidor MCP es necesario, pero no suficiente. La seguridad de un agente que escribe en un libro mayor se decide en el límite entre su capa y el sistema de registro, y hoy ese límite lo determinan los sistemas, no usted.

La buena noticia es que la brecha está claramente definida. Las normas existen. Lo que falta es que los sistemas que llevan los libros las admitan.