Ir al contenido

Seguridad MCP: conectar la IA a su ERP, sí, pero no de cualquier manera

Fallos publicados, lo que dice la especificación y las seis salvaguardas que aplico a mi propio ERP.
10 de noviembre de 2026 por
Seguridad MCP: conectar la IA a su ERP, sí, pero no de cualquier manera

El 15 de abril de 2026, OX Security describió un fallo «por diseño» en la forma en que se lanzan los servidores MCP locales; el 16 de mayo, la Cloud Security Alliance publicó un libro blanco sobre la superficie de ataque de los agentes de IA. ¿Debe renunciar a conectar un agente a su ERP? No: la seguridad MCP depende menos del protocolo que de la forma de conectarlo. Derechos mínimos, solo lectura por defecto, ensayo en seco, copia de seguridad, registro de acciones y validación humana de cada escritura: es lo que practico cada día con mi propio ERP.

Lo esencial

  • MCP (Model Context Protocol) se ha convertido en el enchufe estándar entre los agentes de IA y el software de gestión. Desde diciembre de 2025 lo gobierna una fundación de la Linux Foundation, y Odoo 20 lo ofrece para conectarse a la base de datos.
  • Los fallos publicados en 2025 y 2026 no rompen ningún cifrado: explotan la confianza depositada en un servidor instalado, en la descripción de una herramienta o en una cuenta con demasiados privilegios.
  • La propia especificación lo dice: un humano debería poder rechazar siempre la llamada a una herramienta, y el uso de las herramientas debería quedar registrado.
  • Un agente nunca tiene más derechos que la cuenta con la que se conecta. Ahí es donde se decide todo.
  • Seis salvaguardas bastan para que la conexión sea razonable en una pyme, y ninguna exige herramientas costosas.

Qué está pasando: MCP se impone y los investigadores prueban sus límites

Anthropic presentó el Model Context Protocol el 25 de noviembre de 2024 como «un nuevo estándar para conectar los asistentes de IA con los sistemas donde viven los datos». La idea: un pequeño programa, el servidor MCP, expone a la IA «herramientas» (buscar una factura, crear un contacto, leer una base de datos) que ella puede llamar por sí misma. El 9 de diciembre de 2025, el protocolo pasó a la Agentic AI Foundation, creada dentro de la Linux Foundation con Anthropic, OpenAI y Block; el comunicado contaba entonces más de 10 000 servidores MCP publicados. Los editores de software siguen el movimiento: las notas de la versión 20 de Odoo, publicadas en septiembre de 2026, anuncian la conexión a la base de datos «vía MCP». La versión actual de la especificación es del 28 de julio de 2026.

Los investigadores de seguridad no se han quedado atrás. Tres episodios resumen los riesgos.

Un conector falso que copiaba los correos

En septiembre de 2025, un paquete npm llamado «postmark-mcp», que se hacía pasar por el conector del servicio de correo Postmark, añadió en su versión 1.0.16 una línea que enviaba con copia oculta cada correo a un servidor externo. El 25 de septiembre de 2025, Postmark confirmó que no tenía nada que ver con ese paquete, que se había ganado la confianza de sus usuarios durante quince versiones. Nadie pirateó la IA: se le dio una herramienta trampa, y la usó con normalidad.

Un fallo «por diseño» en el lanzamiento local

El 15 de abril de 2026, OX Security publicó una investigación sobre el transporte STDIO, el que lanza un servidor MCP como un programa en su equipo a partir de un archivo de configuración. Si un dato no controlado llega a esa configuración, puede ejecutar cualquier comando. OX estima la exposición en más de 150 millones de descargas y hasta 200 000 instancias. Según OX, Anthropic se negó a modificar la arquitectura del protocolo y consideró ese comportamiento «esperado»: corresponde al desarrollador controlar lo que se lanza.

El «confused deputy» y el envenenamiento de herramientas

El 16 de mayo de 2026, la Cloud Security Alliance publicó un libro blanco sobre tres familias de riesgos: el envenenamiento de herramientas (instrucciones ocultas en la descripción de una herramienta, que la IA lee y sigue), el «confused deputy» (un servidor que actúa con derechos más amplios de lo que el usuario quería realmente) y la cadena de suministro (paquetes y registros públicos). El documento, que la propia CSA presenta como una investigación rápida asistida por IA, aún no validada por sus procesos oficiales, recomienda cuatro controles: aprobar y versionar las definiciones de herramientas, limitar los derechos de cada llamada, aplicar una política en el momento en que se llama a la herramienta y registrar todas las llamadas.

Qué cambia para usted: la seguridad MCP se decide en la instalación

Para el director de una pyme, la lección no es «MCP es peligroso». Es que conectar un agente a su ERP equivale a firmar un poder. El agente lee lo que su cuenta puede leer y modifica lo que su cuenta puede modificar. Si recibe una instrucción trampa, oculta en un correo, una factura en PDF o la descripción de una herramienta, la ejecutará con esos mismos derechos.

La especificación MCP lo reconoce con todas las letras. Pide que haya «siempre» un humano capaz de rechazar la llamada a una herramienta, que las aplicaciones pidan confirmación para las operaciones sensibles y registren el uso de las herramientas, y que las descripciones que proporciona un servidor se consideren no fiables mientras ese servidor no lo sea. El protocolo no puede imponer estas reglas: le corresponde a quien instala aplicarlas.

Tres preguntas bastan para saber dónde está usted. ¿Con qué cuenta se conecta el agente? ¿Puede escribir sin que nadie valide? ¿Sabrá decir mañana lo que hizo hoy?

Lo que he aprendido

Dirijo mi ERP en lenguaje natural desde mi migración a Odoo Community, contada en Odoo Community vs Enterprise: mi migración: un servidor MCP conecta Odoo con Claude, yo pido, la IA hace el trabajo, yo verifico. También escribí un servidor MCP para la herramienta de notas SiYuan, publicado en código abierto (Servidor SiYuan MCP). Al escribirlo vi un servidor MCP por dentro: un programa que traduce las peticiones de la IA en llamadas al software, con exactamente los derechos que se le dan. El mío escribe directamente en los archivos de las bases de datos de SiYuan, porque la API oficial no lo permitía. Es útil, y muestra bien que un servidor hace lo que sus accesos le permiten, no solo lo que promete su descripción.

El marco más completo es el de mi contabilidad, descrito en Automatizar la contabilidad con IA. El agente redacta un plan, lo ejecuta primero en seco (todo se calcula y luego se anula), yo lo reviso, y después lo ejecuta de verdad tras una copia de seguridad automática de la base. Los controles de importación se niegan a escribir ante la menor diferencia, y ningún gasto sin justificante se registra sin mi acuerdo.

Esa regla la aprendí por las malas. Durante la migración, una primera prueba de sincronización con mi agenda personal borró cuatro eventos. Una prueba en un sistema externo sigue siendo una escritura. Desde entonces, no se escribe nada allí sin validación explícita.

Qué hacer en concreto

1. Dar al agente su propia cuenta, con derechos mínimos

Cree un usuario técnico dedicado, limitado a las aplicaciones y empresas que el agente necesita, sin derechos de administración. Nunca la cuenta del director ni la del administrador: si se cuela una instrucción trampa, ese perímetro es lo que limita los daños.

2. Empezar en solo lectura

Las primeras semanas, el agente busca, resume, concilia y propone, pero no escribe. Después abre usted la escritura, aplicación por aplicación, cuando sepa lo que espera de ella.

3. Exigir un ensayo en seco antes de cada escritura

Toda modificación pasa primero por una simulación que muestra lo que se crearía o cambiaría, y que luego se anula. Si la herramienta no sabe simular, el agente presenta al menos la lista exacta de las escrituras previstas.

4. Hacer una copia de seguridad antes de escribir

Una copia de seguridad de la base, con la restauración probada, antes de cualquier lote de escrituras. Es lo que convierte un error en un simple contratiempo.

5. Llevar un registro de las acciones

Cada llamada a una herramienta debe dejar rastro: quién, cuándo, qué y con qué resultado. Una cuenta dedicada ya ayuda, porque todas sus modificaciones llevan su nombre en el historial del ERP.

6. Mantener a un humano para validar las escrituras

El agente prepara, una persona valida. Instale solo servidores MCP de origen verificado, el del editor o un código que usted haya revisado, y considere cualquier documento entrante como posible fuente de instrucciones trampa.

Preguntas frecuentes

¿Es seguro conectar un agente de IA a mi ERP mediante MCP?

Sí, si lo trata como a un nuevo colaborador al que se le otorga un poder: una cuenta a su nombre, derechos limitados, escrituras validadas y un registro. Los incidentes publicados explotan cuentas con demasiados privilegios o servidores instalados sin verificación.

¿Es más seguro el servidor MCP que ofrece mi editor de software?

Elimina el riesgo del conector falso, y eso cuenta. Pero sigue actuando con los derechos de la cuenta que usted le confía: las salvaguardas siguen siendo cosa suya.

¿Hay que alojar la IA en casa para estar tranquilo?

No necesariamente. El modelo puede ser un servicio externo si los datos que ve le resultan aceptables y si los derechos, la validación y el registro quedan de su lado. La verdadera pregunta es qué puede hacer el agente, más que dónde piensa.

Para ir más lejos

Implanto agentes de IA conectados a Odoo y a sus herramientas de negocio, con estas salvaguardas desde el principio: vea las aplicaciones de negocio y la infraestructura que las sostiene. Para hablar de su caso, reserve una llamada de 20 minutos.

Fuentes

Etiquetas: seguridad MCP, Model Context Protocol, agentes de IA, ERP, Odoo, ciberseguridad, pyme

Ley suiza de protección de datos e IA: ya se aplica, y llegan normas sobre la IA en 2027
Lo que la ley suiza ya exige cuando usa la IA, lo que prepara el Consejo Federal y seis pasos para cumplir sin esperar.