Black Kite detectó vulnerabilidades críticas en el 34,2% de las empresas de IA analizadas

Un equipo conecta un asistente de IA a un repositorio para que analice errores y proponga correcciones. El asistente recibe un token de acceso, lee código y, en ocasiones, ejecuta comandos. Ahora la seguridad del proyecto también depende de cómo almacene ese token el proveedor y de cómo proteja su propia infraestructura. La calidad de las respuestas del modelo no dice nada al respecto.

Un artículo de ZDNet del 10 de noviembre recoge los resultados de un informe de Black Kite sobre proveedores de IA. De las 18 160 empresas analizadas, el 34,2% tenía al menos una vulnerabilidad crítica sin corregir. Para desarrolladores y fundadores, es un motivo para revisar qué puertas tienen ya abiertas los servicios externos: desde la lectura de consultas de clientes hasta la modificación de código y el acceso a la infraestructura de producción.

Qué encontraron los investigadores

La muestra abarca empresas de distintos tamaños, desde equipos pequeños hasta organizaciones con más de mil empleados. Incluye desarrolladores de aplicaciones, empresas que ejecutan proyectos de implantación de IA, servicios sectoriales y proveedores de datos, capacidad de cómputo y modelos. Se excluyeron las empresas que solo utilizan IA de forma ocasional.

Además de las vulnerabilidades críticas, los investigadores detectaron problemas con DMARC en el 61,7% de las empresas y deficiencias en DKIM en el 37,3%. Son mecanismos de autenticación del correo electrónico. Los errores de configuración pueden facilitar la suplantación de correos y el phishing: por ejemplo, cuando un empleado recibe una supuesta solicitud interna para volver a autorizar una integración.

Otro 29,7% de las empresas obtuvo una calificación de alta susceptibilidad a ataques de ransomware según el índice de Black Kite. Conviene interpretar bien esta cifra: es una evaluación del riesgo, no el porcentaje de organizaciones cuyos sistemas ya han cifrado los delincuentes. Del mismo modo, la presencia de una vulnerabilidad crítica no demuestra por sí sola que permita acceder a los datos de un cliente concreto.

La reseña también señala que se vincularon credenciales corporativas robadas con el 6,8% de los proveedores de la muestra. Un hallazgo así exige comprobar si las contraseñas siguen siendo válidas, revisar las sesiones activas y verificar la autenticación multifactor. No equivale a confirmar que se hayan comprometido todos los sistemas de los clientes.

Cómo el problema del proveedor se convierte en el suyo

Imaginemos un asistente de soporte conectado al CRM. Para preparar un borrador de respuesta, necesita el texto de la consulta y unos pocos campos de la ficha del cliente. Sin embargo, durante la configuración, el equipo concede al servicio la capacidad de exportar toda la base de datos y modificar registros para poner en marcha el piloto más rápido.

Si un atacante consigue acceder al proveedor, las consecuencias dependerán de esos permisos. Poder leer consultas individuales y poder exportar la base de datos de clientes implican daños potenciales de distinta magnitud. Por eso resulta útil evaluar cada integración con una pregunta concreta: ¿qué podría hacer alguien que se apoderara de su token?

Un análisis independiente de componentes MCP que menciona ZDNet recoge 1 732 hallazgos de seguridad. De ellos, el 48,8% se clasificó como de gravedad alta o crítica, incluidas posibilidades de inyección de código y comandos. Es el porcentaje de hallazgos de un análisis separado. No permite concluir que el 48,8% de todos los servidores MCP o de las empresas sea vulnerable.

MCP permite conectar aplicaciones de IA con herramientas y sistemas empresariales. La revisión práctica debe centrarse en su implementación: quién puede invocar una herramienta, qué argumentos acepta y con qué permisos se ejecuta la acción.

Qué revisar antes de la próxima conexión

Empiece por elaborar una lista de los servicios de IA a los que ya se ha concedido acceso. Para cada uno, registre quién es su responsable dentro del equipo, a qué datos puede acceder, qué acciones tiene permitidas y cómo desactivar rápidamente la integración. Esa lista convierte el debate sobre seguridad en una tarea de ingeniería concreta.

Después, reduzca los permisos a los necesarios para el flujo de trabajo. Si un asistente prepara borradores, cada permiso para enviar mensajes, modificar registros o ejecutar comandos debería justificarse por separado. Para las acciones peligrosas, conviene prever la confirmación de una persona y un registro de operaciones.

Pregunte al proveedor cómo corrige las vulnerabilidades críticas, protege las cuentas y comunica los incidentes. Repetir la revisión resulta especialmente útil cuando se amplía el acceso: ayer el servicio leía documentación; hoy puede escribir en el repositorio.

El informe tiene limitaciones: la reseña disponible no permite comparar el riesgo de las empresas de IA con el de los proveedores SaaS convencionales ni evaluar la seguridad de un producto concreto. Sí aporta un motivo claro para revisar los permisos. Antes de ampliar un piloto, compruebe si el acceso del servicio se corresponde con la tarea para la que lo conectó.