Agentes de IA: 7 errores que debes evitar antes de conectarlos a tus aplicaciones de negocio

El Model Context Protocol (MCP) permite a los agentes de IA leer los datos de la empresa y actuar en sus aplicaciones. Los proyectos se multiplican, a menudo más rápido que los controles que se supone que deben regularlos. A continuación, ofrecemos una visión general de los errores más habituales y de lo que hay que comprobar antes de la puesta en producción.

Asistentes de IA que actúan

Hace tan solo dos años, un asistente de IA servía sobre todo para redactar un correo electrónico o resumir un informe. Hoy en día, se le pide que busque una ficha en el CRM, que abra un ticket o que se ponga en contacto con un proveedor. En definitiva, que actúe.

MCP (Protocolo de contexto de modelos) ha contribuido en gran medida a este cambio. Este protocolo abierto define una forma estándar de conectar una aplicación de IA con herramientas externas. En lugar de programar una integración para cada programa, se instala un servidor MCP que ofrece una serie de funciones. El agente las detecta y las utiliza como mejor le parezca.

Para un equipo de seguridad, la llegada de estos agentes plantea nuevas cuestiones. El agente actúa en nombre de un usuario, con derechos que rara vez se definen con precisión. Cada servidor MCP es un programa más en la red, que a menudo se instala al margen de los circuitos habituales. Y lo que hace el agente depende en parte de lo que lee: un correo electrónico entrante, una página web, un documento enviado por un tercero.

El protocolo en sí mismo rara vez es el motivo del problema. Los problemas casi siempre se deben a la configuración de los agentes, sus herramientas y sus permisos.

Tres ingredientes que no deben mezclarse

Un agente que ha acceso a datos sensibles, que lee contenidos procedentes del exterior y que puede enviar información fuera de la empresa tiene todo lo necesario para que se produzca una fuga de datos. No hace falta piratear un servidor: basta con introducir la orden adecuada en el lugar correcto.

Por separado, cada uno de estos accesos se puede gestionar. El verdadero trabajo de arquitectura consiste en evitar que los tres se encuentren en el mismo agente.

4 puntos de control

Entre el usuario y la aplicación de negocio, la solicitud pasa por la aplicación de IA y, a continuación, por el servidor MCP. Por lo tanto, hay cuatro límites que hay que vigilar. El primero separa al usuario del agente: ¿quién solicita qué y en qué contexto? El segundo se sitúa entre el agente y el servidor MCP: ¿a qué herramientas tiene derecho a acceder este agente? La tercera se refiere al paso del servidor a la aplicación de negocio: ¿bajo qué identidad y con qué derechos? La última, la que más se suele pasar por alto, separa al agente de los datos externos que consume y que pueden influir en sus decisiones.

El hecho de que se autorice una conexión no significa que todo lo que transite por ella también esté autorizado.

Error 1 : agentes con demasiados derechos

Es, con diferencia, el error más común.

Un asistente comercial tiene que preparar las citas de la semana. Solo necesita consultar el CRM, nada más. Sin embargo, para agilizar el proceso, se le ha asignado una cuenta de servicio con la que también puede modificar contratos, eliminar fichas y exportar toda la base de datos. El día en que el agente malinterprete una solicitud o reciba una malintencionada, los daños ya no tendrán nada que ver con la tarea inicial.

La norma es la del mínimo privilegio, pero aplicada herramienta por herramienta. El agente solo debe ver las funciones que necesita; la lectura debe estar separada de la escritura y la eliminación, y su ámbito debe limitarse a los datos útiles: un expediente de cliente, no toda la base de datos.

Sobre todo, estas restricciones deben ser aplicadas por la aplicación de destino. Escribir en la línea de comandos «solo se permite la lectura» no protege contra nada.

Error 2 : servidores instalados sin saber de dónde proceden

Los servidores MCP de código abierto permiten ahorrar un tiempo muy valioso. Sin embargo, se suele olvidar que instalar uno equivale a ejecutar un nuevo programa, con acceso al ordenador, a la red y, en ocasiones, a las aplicaciones internas. Un componente malicioso puede husmear en los archivos, incorporar una dependencia comprometida o desviar las solicitudes del agente.

Y el control no termina el día de la instalación. Una actualización puede modificar de forma silenciosa el comportamiento de un conector validado hace seis meses, o simplemente la descripción de sus herramientas.

A esto se suma un problema que los responsables de seguridad de la información conocen bien desde la llegada de la nube: el TI en la sombra, versión MCP. Los propios empleados conectan su asistente a su correo electrónico, a su espacio de almacenamiento en la nube o a un repositorio de código, sin decírselo a nadie.

Por lo tanto, es necesario elaborar un inventario de los servidores autorizados, con un responsable para cada uno de ellos. Antes de cualquier implementación, se comprueban el editor, las dependencias, la frecuencia de mantenimiento y los permisos solicitados. Se fijan las versiones, y cualquier actualización debe volver a pasar por el proceso de validación. En cuanto a los puestos de trabajo, una lista blanca y un sistema para detectar instalaciones no declaradas completan el dispositivo.

Error 3 : identidades y tokens mal gestionados

El servidor MCP actúa como intermediario entre el agente y las aplicaciones. Por lo tanto, es ahí donde los errores de autenticación causan más problemas.

Primer escollo: enviar tal cual a la API de negocio el token recibido del cliente. Esta práctica, la paso de token, está expresamente prohibida por la especificación MCP.

Segundo escollo: permitir que el servidor actúe con su propia cuenta técnica en lugar de con los derechos del usuario. En ese caso, se convierte en lo que se denomina un diputado desconcertado, un intermediario que realiza por alguien acciones que esa persona nunca habría podido hacer por sí misma.

Tercer escollo, más sutil: cuando todo un equipo comparte el mismo agente, ya nadie sabe quién ha puesto en marcha cada operación.

Si se utiliza OAuth, cada token debe emitirse para el servicio que lo recibe, con ámbitos reducidos al mínimo, y verificarse en cada llamada. La identidad del usuario final debe llegar hasta la aplicación de negocio, de modo que sus autorizaciones se apliquen como de costumbre. En cuanto a los secretos, su lugar está en una caja fuerte, no en un archivo de configuración.

Error 4 : creer lo que lee el agente

Este es el riesgo específico de la IA generativa. Un modelo de lenguaje no distingue bien entre los datos que procesa y las instrucciones que recibe.

Un agente debe resumir un correo electrónico. En algún punto del texto, el remitente ha añadido una frase en la que solicita que se recojan unos documentos internos y se envíen a una dirección externa. Para el modelo, se trata de una instrucción más entre otras. Se habla de’inyección indirecta de combustible, y el’OWASP el primer puesto en su clasificación de riesgos relacionados con los modelos de lenguaje grande (LLM).

Con MCP, las consecuencias alcanzan una nueva dimensión, ya que el agente dispone de herramientas para pasar a la acción. Incluso las descripciones de las herramientas pueden servir como «caballo de Troya»: un servidor malicioso oculta en ellas instrucciones que el modelo vuelve a leer en cada sesión. Se trata del contaminación de herramientas.

Por lo tanto, cualquier contenido externo (correo electrónico, página web, documento, respuesta de una herramienta) debe tratarse como una entrada del usuario en una aplicación web: con recelo. Y las medidas de seguridad deben estar fuera del modelo. Validación de parámetros, lista de destinos autorizados, límites de volumen, aprobación de operaciones sensibles: todo ello funciona incluso cuando la IA se deja engañar.

Error 5 : servidores expuestos sin segmentación

Un servidor MCP mal protegido puede servir de puerta de entrada al resto del sistema de información. Esto es especialmente cierto cuando se ejecuta en el ordenador de un usuario con derechos elevados o cuando puede acceder a prácticamente cualquier dirección de la red.

Algunas configuraciones dejan servicios locales abiertos sin autenticación. Otras permiten ataques SSRF (Falsificación de solicitudes del lado del servidor) : el servidor se ve obligado a consultar recursos internos a los que nunca debería haber tenido acceso, como, por ejemplo, una consola de administración o el servicio de metadatos de un proveedor de servicios en la nube.

Cada servidor debe ejecutarse en una cuenta dedicada, con permisos mínimos y, en función del nivel de confidencialidad de los accesos, en un contenedor o en un entorno aislado. El tráfico saliente pasa por una lista blanca y el acceso a los archivos está restringido. No basta con que el código sea correcto si el entorno de ejecución permite el paso de todo.

Error 6 : agentes abandonados a su suerte

Consultar la ficha de un cliente y dar de baja un contrato no tienen la misma importancia. Sin embargo, algunas arquitecturas permiten que el agente encadene las llamadas sin ningún tipo de restricción. De este modo, puede multiplicar las operaciones, equivocarse de objetivo o cometer una acción irreversible.

También existe el extremo opuesto. Al pedir una confirmación para todo, se consigue que los usuarios hagan clic en «Validar» sin leer. El control existe sobre el papel, pero ya no en la práctica.

Lo más adecuado es clasificar las acciones según su gravedad. Las operaciones habituales y reversibles pueden automatizarse. La validación humana se reserva para lo que realmente importa (eliminaciones masivas, pagos, envío de datos al exterior), con una pantalla que muestra con precisión lo que va a ocurrir. También es necesario establecer límites máximos en el número de llamadas, los volúmenes y los importes, así como disponer de un botón de parada real y probado.

Error 7 : Poner en marcha la producción sin realizar pruebas ni supervisar

Una demostración satisfactoria no prueba gran cosa. Las pruebas funcionales verifican que el agente haga lo que se espera de él. No se plantean qué hace cuando un documento contiene una instrucción conflictiva, cuando una herramienta cambia de comportamiento, cuando se le deniega un permiso o cuando una operación falla en medio de una secuencia.

Estos escenarios deben integrarse en el ciclo DevSecOps, con pruebas de inyección, escalada de privilegios y acceso no autorizado antes de cada puesta en producción.

En producción, cada solicitud de herramienta debe dejar un registro que se pueda aprovechar : quién lo activó, mediante qué agente, hacia qué sistema y con qué resultado. En cambio, no es necesario almacenar en los registros los datos confidenciales propiamente dichos. Estos registros deben enviarse al SOC, junto con alertas sobre señales débiles: volumen inusual, nuevo destino, herramienta que nunca se había utilizado hasta entonces.

Finalmente, Debe estar preparado un procedimiento específico para casos de incidencia : revocación de tokens, desconexión de un servidor, suspensión de un agente.

Acompañar la autonomía, no sufrirla

MCP ha simplificado enormemente la conexión de los agentes con las herramientas de la empresa, lo cual es una buena noticia para los distintos departamentos. Pero un agente con capacidad de actuación también puede equivocarse o ser manipulado. Cuanto más amplio es su margen de maniobra, más caro sale el error.

No sirve de nada acumular instrucciones en la línea de comandos con la esperanza de que el modelo las respete. La protección se construye a lo largo de toda la cadena: identidades, conectores, permisos, datos, acciones y supervisión. En definitiva, un agente merece el mismo nivel de exigencia que cualquier cuenta con privilegios.

Un agente no es digno de confianza por el mero hecho de ser inteligente. Lo es porque se ha diseñado su entorno de tal forma que no pueda hacer lo que le dé la gana.