Seguridad de los datos de los agentes de IA: ¿Qué ocurre cuando los agentes se conectan a los sistemas?

La IA está pasando de generar respuestas a realizar acciones en sistemas reales. Ese cambio transforma la cuestión central de la seguridad. Ya no basta con preguntarse si el modelo es preciso o fiable. También hay que preguntarse cómo se comporta el sistema circundante cuando el modelo malinterpreta una instrucción, recibe una entrada maliciosa o se le concede más autoridad de la que la tarea requiere. Protocolos como MCP facilitan crear conexiones entre agentes y sistemas, pero también hacen que el diseño de esas conexiones sea imposible de ignorar.

Conectar un agente de IA a un sistema empresarial puede exponer distintas categorías de datos a diferentes componentes, como el anfitrión de la IA, el servidor de herramientas, el proveedor de identidad y la aplicación final. MCP define cómo se comunican las partes de esa conexión, pero no determina qué datos almacena, expone o retiene cada implementación.

De las respuestas a las consecuencias

Conectar un agente no crea un único límite de confianza; crea una cadena de ellos: el anfitrión de la IA interpreta la solicitud, un cliente de protocolo selecciona una capacidad, un servidor de herramientas valida y traduce la llamada, un proveedor de identidad establece quién está actuando y el sistema final aplica los permisos y registra el resultado. MCP estandariza parte de esa comunicación, pero no hace que la cadena completa sea segura por sí sola. La seguridad depende de las decisiones que se toman en cada capa.

La primera generación de IA generativa de uso generalizado producía sobre todo cosas para que las personas las revisaran: texto, imágenes, resúmenes y código. Los agentes, en cambio, operan cada vez más herramientas. Envían mensajes, modifican registros, activan flujos de trabajo, mueven dinero y controlan procesos físicos. Una respuesta plausible pero incorrecta es un inconveniente; una acción plausible pero incorrecta puede tener consecuencias inmediatas.

Estándares como MCP permiten que las herramientas sean descubiertas e invocadas mediante interfaces estructuradas. Eso supone una mejora importante frente al raspado de pantalla o las integraciones improvisadas, pero la estructura por sí sola no es una política de seguridad. El diseñador de la herramienta sigue decidiendo qué acciones existen, qué entradas aceptan, qué identidad utilizan y qué evidencias devuelven.

Nos topamos con esta distinción al crear el servidor MCP de ezeep. La impresión hace tangible el problema porque la decisión de un agente puede convertirse en una salida física en cuestión de segundos. La lección, sin embargo, se aplica a cualquier sistema operacional.

Adónde van realmente los datos

La frase "el modelo nunca ve tu contraseña" es útil, pero no describe por completo el flujo de datos. Una conexión de agente típica implica varias categorías de información: credenciales gestionadas por una capa de autenticación, argumentos de herramienta construidos a partir de la petición del usuario, resultados operativos devueltos al modelo, cargas útiles de negocio transferidas al servicio final y registros conservados por uno o más componentes. Normalmente, el modelo recibe la conversación, las descripciones de las herramientas disponibles, los argumentos necesarios para invocar una herramienta seleccionada y el resultado que esta devuelve.

Esas categorías no siguen necesariamente el mismo camino. OAuth puede mantener una contraseña y un token de acceso fuera del contexto del modelo, mientras que el resultado de la herramienta puede exponer nombres de clientes, ubicaciones de dispositivos, valores financieros o metadatos internos del sistema. Un documento puede transferirse directamente entre servicios mientras su nombre de archivo, destino y estado aparecen en la conversación. El anfitrión de la IA, el servidor de herramientas, el proveedor de identidad y el sistema de destino también pueden tener distintas políticas de registro y retención.

Por tanto, no es responsable afirmar de forma universal que "la IA no ve los datos". Las preguntas correctas son qué datos recibe cada capa, por qué los necesita, cuánto tiempo los conserva y si el usuario entiende ese límite. Nuestra propia implementación de MCP nos ofrece ejemplos concretos de estas distinciones, pero el problema de diseño se aplica a todos los sistemas conectados por agentes.

La identidad determina el radio de acción

Un agente no debería tener autoridad independiente. Un agente puede actuar a través de una identidad de servicio compartida o en nombre de un usuario individual. Ninguno de los dos modelos es universalmente correcto. Una identidad compartida encaja en flujos de trabajo desatendidos, pero cada acción hereda el alcance de esa cuenta. La autorización por usuario ofrece un acceso más limitado y una atribución más clara, pero requiere que cada usuario se autentique y que la aplicación gestione correctamente las sesiones individuales. La interpretación que haga el agente de una solicitud nunca debe sustituir a la autorización impuesta por el sistema de destino.

La decisión de ingeniería importante no es qué modelo suena más seguro en abstracto, sino si la identidad encaja con el flujo de trabajo y si sus permisos son más limitados que las consecuencias de un error. En nuestro trabajo con ezeep MCP, soportamos ambos modelos porque un servicio de almacén automatizado y un empleado que imprime de forma interactiva tienen requisitos de identidad realmente distintos.

¿Quién es responsable cuando un agente de IA realiza una acción?

Ese es un problema de diseño del sistema, no simplemente un problema de confianza en el modelo. Una arquitectura más segura combina varios controles: identidades con privilegios mínimos, capacidades restringidas y tipificadas, validación en el sistema posterior, confirmación para acciones con consecuencias, separación entre instrucciones confiables y contenido no confiable, y un registro de auditoría que muestre lo que realmente ha sucedido. Acotar el alcance reduce el daño potencial; la observabilidad y la atribución establecen la responsabilidad después de que ocurre una acción.

Diseñar para la reversibilidad

Una prueba útil para cualquier capacidad de un agente no es solo si la acción está permitida, sino qué ocurre cuando está equivocada. Las operaciones de lectura, los cambios recuperables, los compromisos financieros, las comunicaciones externas y las tareas administrativas destructivas merecen controles distintos. Algunas acciones deben requerir confirmación. Otras deben permitir reversión. Y otras no deberían exponerse al agente en absoluto.

Al desarrollar el servidor MCP de ezeep, decidimos no exponer la eliminación de usuarios, grupos o impresoras, aunque existen APIs REST relacionadas. Eso no hace que las demás herramientas sean inofensivas —las impresiones generan salida física y las herramientas administrativas pueden cambiar accesos—, pero elimina una categoría de errores irreversibles. El principio va más allá de la impresión: el diseño de las capacidades debe reflejar la consecuencia, no solo la disponibilidad técnica.

¿Puede la inyección de indicaciones hacer que un agente de IA ejecute la acción equivocada?

Sí. Un agente puede encontrar instrucciones ocultas en documentos, páginas web, correos electrónicos, tickets de soporte o resultados de herramientas. Esto se conoce comúnmente como inyección indirecta de instrucciones: contenido que debería haberse tratado como datos intenta, en cambio, influir en lo que el agente hace a continuación.

Ese riesgo no se soluciona pidiéndole al modelo que «tenga cuidado». El contenido no confiable no debería poder conceder permisos, cambiar el objetivo del usuario, seleccionar una identidad con más privilegios ni omitir la confirmación. Las entradas de las herramientas requieren validación determinista, las acciones con consecuencias necesitan comprobaciones de política fuera del modelo, y los flujos de trabajo sensibles deben separar claramente las instrucciones confiables del material no confiable.

También importa la cadena de suministro de herramientas. Las descripciones de las herramientas influyen en el comportamiento del modelo, así que conectar un nuevo servidor es en sí mismo una decisión de seguridad —no simplemente un ajuste de conveniencia.

La seguridad se decide en cada capa

Conectar un agente a un sistema real es una decisión de diseño que se toma en cada capa: qué acciones existen, qué identidad utilizan, qué datos ve cada componente, qué se puede deshacer y qué se registra. MCP estandariza parte de esa conversación. El resto depende de las personas que construyen la conexión. En el servidor MCP de ezeep, eso significó soportar tanto identidades de servicio como identidades por usuario y no exponer la eliminación de usuarios, grupos o impresoras. Todo agente se equivocará en algún momento, así que la conexión debe diseñarse para ese momento; y así construimos el servidor MCP de ezeep.

Want to Use ezeep MCP?

Connect our MCP to your agents today.

Start Free Trial