Mysterium expuso endpoints de IA, y el autoalojamiento perdió su coartada de seguridad
Mysterium expuso endpoints de IA a una escala que convierte un error de configuración en una advertencia para toda la industria. Sus investigadores identificaron 36.769 sistemas accesibles, mientras que solo 741 devolvieron un desafío de autenticación HTTP.
El estudio del 10 de septiembre abarcó servidores de modelos, interfaces de chat, creadores de agentes y consolas de almacenes vectoriales. Estos componentes conforman la capa operativa entre un modelo de IA y las personas, documentos, credenciales y aplicaciones que lo rodean.
Esto crea un conflicto incómodo para la IA autoalojada. Las empresas suelen ejecutar modelos localmente para mantener el control sobre los prompts y los datos sensibles. Sin embargo, muchas implementaciones parecen ser accesibles sin una barrera a nivel de red, trasladando la confianza hacia la seguridad de la aplicación, la aplicación de parches y una configuración correcta.
La cifra no prueba que los 36.769 sistemas expusieran información privada. Algunas aplicaciones podrían seguir exigiendo a los usuarios iniciar sesión después de cargarse. Sin embargo, los hallazgos muestran que miles de servicios de IA se anuncian directamente a los escáneres de internet.
Esa distinción importa. Una página de inicio de sesión visible sigue siendo una aplicación expuesta que debe resistir nuevas vulnerabilidades, contraseñas robadas, configuraciones predeterminadas débiles y sondeos automatizados. Un servicio detrás de una red privada o una pasarela autenticada presenta un objetivo menor.
Por tanto, la comparación no es simplemente IA local frente a IA alojada. Es control en principio frente a control en la implementación. Los resultados de Mysterium sugieren que las organizaciones están optando por el autoalojamiento sin operar de forma consistente el perímetro de seguridad que hace valioso al autoalojamiento.
Endpoints de IA expuestos por Mysterium en toda la pila operativa de IA
El hallazgo central no es un único producto vulnerable. Es una pila de IA reconocible que puede cartografiarse desde la internet pública.
Mysterium afirmó que sus investigadores utilizaron un índice de escaneo de terceros en lugar de sondear directamente las máquinas identificadas. El censo original buscó huellas de servicios, incluidos títulos de página, texto de respuesta y puertos asociados con software de IA común.
El conjunto de datos final contenía 36.769 endpoints que se identificaban a sí mismos. Los productos de servicio de modelos representaron la mayor parte de esa población, liderados por 18.529 instancias de Open WebUI. Open WebUI ofrece una interfaz basada en navegador para interactuar con modelos de lenguaje alojados localmente.
Solo uno de esos endpoints de Open WebUI devolvió un desafío de autenticación HTTP durante el estudio. Eso no demuestra que las aplicaciones restantes permitieran un acceso irrestricto a las cuentas. Sí demuestra que casi ninguna tenía una barrera HTTP detectable situada delante de la aplicación.
Ollama, un servicio para descargar y ejecutar modelos en hardware local, representó otros 6.935 endpoints confirmados. Según Mysterium, cada uno devolvió de forma anónima la respuesta raíz del producto. De ese grupo, 729 devolvieron un desafío de autenticación.
Los investigadores también identificaron 4.880 endpoints de vLLM, de los cuales tres devolvieron un desafío. vLLM es un servidor de inferencia, lo que significa que acepta solicitudes y las ejecuta mediante un modelo de lenguaje para producir respuestas.
Los grupos más pequeños incluyeron 150 endpoints de LocalAI, 69 servidores llama.cpp y 63 implementaciones de Xinference. Estos productos atienden a públicos distintos, pero comparten un propósito operativo. Hacen que los modelos sean accesibles para aplicaciones o usuarios.
El conjunto de datos fue más allá de la inferencia. Mysterium contabilizó 5.223 endpoints asociados con creadores de agentes y herramientas de flujos de trabajo, incluidos Flowise, RAGFlow, Dify, ComfyUI, n8n, Langflow y Open WebUI Pipelines.
Esa categoría conlleva un perfil de riesgo distinto. Un servidor de inferencia procesa prompts, pero un creador de agentes suele conectar modelos con bases de datos, sistemas de mensajería, servicios en la nube y aplicaciones internas. Puede almacenar tokens o invocar herramientas con permisos reales.
Flowise representó 1.341 endpoints accesibles, ninguno de los cuales devolvió un desafío de autenticación. El estudio también contabilizó 891 implementaciones de RAGFlow, 792 endpoints de Dify, 788 endpoints de ComfyUI y 675 instancias de n8n.
La visibilidad de los almacenes vectoriales fue mucho menor. Los investigadores encontraron 914 consolas Milvus Attu y seis endpoints de Weaviate. Un almacén vectorial guarda representaciones numéricas de contenido para que una aplicación de IA pueda recuperar documentos relevantes durante una conversación.
Estas cifras no deben interpretarse como prueba de que las bases de datos vectoriales rara vez están expuestas. Mysterium indicó que su fuente no escaneó los puertos nativos de dos productos principales. El censo capturó principalmente consolas web visibles, dejando la categoría más sensible desde el punto de vista de los datos mal medida.
El informe también encontró 22.024 respuestas adicionales en el puerto predeterminado de Ollama. Los investigadores las excluyeron del total confirmado porque una respuesta de puerto por sí sola ofrecía evidencia más débil que un banner de producto reconocible.
Esa exclusión conservadora refuerza la conclusión principal. La cifra de 36.769 es un mínimo confirmado dentro de un índice de escaneo, no un inventario completo de la infraestructura pública de IA.
Por qué la seguridad de la IA autoalojada se rompe en el perímetro
El autoalojamiento protege los datos solo cuando la organización también controla quién puede llegar al host.
El argumento a favor de los modelos locales suele comenzar con la custodia de los datos. Los prompts, los documentos cargados, los pasajes recuperados y las respuestas generadas pueden permanecer en equipos controlados por la organización. Este enfoque puede reducir la dependencia de un proveedor externo de modelos.
Sin embargo, la ubicación por sí sola no genera confidencialidad. Un modelo ejecutándose en hardware de la empresa puede seguir siendo público si su servicio escucha en una dirección expuesta a internet. Una implementación interna puede volverse externa mediante una regla de firewall, un grupo de seguridad en la nube, una configuración de contenedor o un túnel configurado apresuradamente.
Muchos productos de IA local escuchan de forma predeterminada solo en la dirección de loopback. Loopback limita las conexiones al software que se ejecuta en la misma máquina. A veces, los operadores cambian esa dirección a 0.0.0.0, lo que permite que el servicio acepte conexiones a través de todas las interfaces de red disponibles.
Ese cambio es útil cuando un desarrollador necesita acceso desde otro dispositivo. Se vuelve peligroso cuando la red circundante también permite tráfico entrante desde internet.
Un proxy inverso puede proporcionar una capa de autenticación antes de que las solicitudes lleguen a la aplicación de IA. Una red privada virtual puede mantener el servicio fuera del espacio de direcciones públicas. Una lista de permitidos de IP puede restringir el acceso a redes autorizadas.
Mysterium encontró poca evidencia de esas protecciones a nivel HTTP. En todo el censo, solo el 2,02 por ciento de los endpoints devolvieron un desafío de autenticación. Cinco consultas de productos quedaron incompletas debido a límites de tasa de la fuente, por lo que los investigadores no asignaron recuentos de desafíos a esos grupos.
La interpretación limitada es importante. Un desafío HTTP no es el único control de seguridad posible. Una aplicación puede cargarse públicamente y aun así aplicar sus propias reglas de inicio de sesión, sesión o autorización.
Sin embargo, depender de la autenticación de la aplicación cambia el modelo de amenazas. La aplicación pasa a ser continuamente accesible para escáneres y atacantes. Cada parche omitido, error de autorización, ruta administrativa expuesta y credencial predeterminada se vuelve más importante.
Los registros recientes de vulnerabilidades muestran por qué esta preocupación es concreta. Los avisos de seguridad de Tenable de 2026 enumeraron problemas de alta gravedad que afectan a Open WebUI y a varios componentes de Flowise.
Los avisos sobre Flowise incluyeron recorrido de rutas, inyección de consultas de grafo, ausencia de autenticación en endpoints de NVIDIA NIM y divulgación de información personal. Avisos independientes cubrieron exposición de credenciales, fallos de autorización y escrituras arbitrarias de archivos en otras herramientas de IA.
Estos registros no significan que cada implementación visible desde internet sea vulnerable. Las versiones, configuraciones y controles compensatorios difieren. Demuestran que la capa de aplicación no puede servir como sustituto permanente del aislamiento de red.
El momento de aplicar parches crea otro problema. Un desarrollador puede lanzar una prueba de concepto útil en minutos y luego dejarla operativa durante meses. Es posible que el servicio nunca entre en el inventario de activos utilizado por los equipos de seguridad e infraestructura.
Ese ciclo de vida produce IA en la sombra: sistemas adoptados o creados sin la supervisión organizativa habitual. El proyecto permanece visible para su creador, pero invisible para los equipos responsables de revisiones de acceso, actualizaciones, registros y respuesta a incidentes.
El resultado es un perímetro de seguridad construido sobre supuestos. El científico de datos asume que el firewall de la nube bloquea el tráfico. El equipo de infraestructura asume que la aplicación requiere autenticación. El propietario de la aplicación asume que la implementación es temporal.
Un escáner de internet pone a prueba esos supuestos sin necesitar contexto organizativo. Si el producto responde, se identifica y presenta una superficie de aplicación, ya ha cruzado un límite que el autoalojamiento debía preservar.
Los creadores de agentes convierten la exposición en riesgo para la cadena de suministro
Los endpoints de IA expuestos más graves hacen más que responder preguntas, porque pueden actuar mediante credenciales y sistemas conectados.
Una cadena de suministro de IA incluye el modelo, los paquetes de software, la infraestructura de servicio, las bases de datos de recuperación, los plugins, las herramientas y los servicios externos utilizados para producir un resultado. Una debilidad en cualquier componente conectado puede afectar al sistema o ampliar el acceso de un atacante.
Las cadenas de suministro de software tradicionales ya conllevan riesgo heredado. Las aplicaciones dependen de paquetes mantenidos por desarrolladores externos, imágenes de contenedor creadas en otros lugares y flujos de trabajo automatizados que contienen credenciales de implementación.
Las aplicaciones de IA añaden prompts, archivos de modelos, contenido de recuperación, instrucciones para agentes y definiciones de herramientas a esa cadena. Algunos de estos artefactos parecen datos, aunque pueden alterar lo que hace un agente.
Fortinet describió las habilidades de los agentes como una nueva capa de dependencias para los asistentes de programación. Su análisis de habilidades señaló que una habilidad puede utilizar instrucciones en lenguaje natural para indicar a un agente que acceda a archivos, ejecute comandos de shell o transmita información.
Ese comportamiento no siempre requiere una vulnerabilidad de software convencional. Una instrucción maliciosa puede volverse operativa cuando un agente confía en ella y tiene permiso para utilizar la herramienta solicitada.
Un creador de flujos de trabajo expuesto a internet combina estos riesgos. Puede revelar qué integraciones utiliza una organización, aceptar entradas no confiables o exponer rutas que interactúan con credenciales almacenadas. Un flujo de trabajo comprometido podría entonces alcanzar sistemas mucho más allá del servidor de IA original.
Pensemos en un asistente de recuperación utilizado por un equipo de ingeniería. La aplicación podría conectarse a un repositorio de código fuente, un almacén de documentación, un rastreador de incidencias y un endpoint de modelo. Su base de datos vectorial podría contener fragmentos de documentos internos.
Si la interfaz pública presenta un fallo de autorización, el premio para el atacante no se limita a inferencia gratuita de modelos. Dependiendo del producto y la configuración, el atacante podría acceder a contenido recuperado, definiciones de flujos de trabajo, metadatos de conexión o tokens.
Un agente de atención al cliente presenta una ruta similar. Podría conectarse al correo electrónico, registros de pedidos, herramientas de mensajería y una base de datos de clientes. Incluso una credencial de alcance limitado se vuelve valiosa cuando el flujo de trabajo puede combinar información entre servicios.
Por eso los 5.223 endpoints de creadores de agentes merecen atención separada de los servidores de modelos. La población más pequeña puede tener un radio de impacto operativo mayor.
El informe de febrero de Tenable sobre riesgo en la nube aporta contexto empresarial. Su telemetría mostró que el 70 por ciento de las organizaciones analizadas había integrado al menos un paquete de IA de terceros o de Model Context Protocol.
Model Context Protocol, o MCP, es un estándar que permite a las aplicaciones de IA conectarse a herramientas y fuentes de datos. Su utilidad proviene de otorgar a los modelos acceso estructurado a capacidades externas.
Tenable también informó que el 18 por ciento de las organizaciones había otorgado permisos administrativos a servicios de IA que rara vez se auditaban. La empresa concluyó que las identidades no humanas, incluidos agentes y cuentas de servicio, presentaban un riesgo medido mayor que los usuarios humanos.
Estos hallazgos proceden de la telemetría de clientes y nube de Tenable, no del censo de internet de Mysterium. Los conjuntos de datos no deben combinarse en una única estimación de prevalencia. En conjunto, muestran dos caras del mismo problema operativo.
Mysterium midió servicios accesibles. Tenable midió permisos, paquetes de terceros y condiciones de identidad dentro de entornos empresariales. La exposición pública se vuelve más relevante cuando el servicio accesible también controla una identidad no humana privilegiada.
La presión recae tanto sobre desarrolladores como sobre equipos de seguridad. Los desarrolladores necesitan acceso rápido a modelos e integraciones. Los equipos de seguridad necesitan un inventario, una propiedad clara, privilegios limitados y evidencia de que cada servicio público tiene una razón deliberada para existir.
Ninguno de los dos objetivos puede lograrse solo mediante políticas del modelo. Que un modelo rechace una solicitud dañina no corrige una consola administrativa pública. Las salvaguardas del proveedor no rotan un token filtrado ni eliminan un contenedor abandonado.
Las organizaciones que usan IA para trabajar con conocimiento interno también deben clasificar lo que entra en los sistemas de recuperación. Una base de conocimientos consultable puede mejorar el acceso a material técnico, pero su almacenamiento y conectores heredan la sensibilidad de ese material.
Por lo tanto, la cuestión de seguridad se desplaza aguas arriba. Antes de que un agente reciba una solicitud, alguien debe decidir qué datos puede recuperar, qué herramientas puede invocar y qué red puede alcanzarlo.
Lo que la cifra de 36.769 no demuestra
El censo demuestra accesibilidad pública, pero no establece que se hayan producido 36.769 intrusiones exitosas o filtraciones de datos.
La medición de internet puede producir una cifra impactante sin responder todas las preguntas de seguridad. Las huellas de producto identifican servicios, mientras que una respuesta HTTP revela algo sobre su perímetro. Ninguna de las dos revela automáticamente el estado interno de autorización de la aplicación.
Es probable que algunos endpoints del conjunto de datos mostraran una página de inicio de sesión. Otros podrían haber restringido funciones importantes después de cargar la interfaz. Algunos podrían haber sido sistemas de investigación, honeypots, demostraciones públicas intencionales o instalaciones de prueba vacías.
Mysterium reconoció este límite. El informe no afirmó que cada aplicación visible permitiera acceso anónimo a funciones privadas. Describió la falta de una barrera de red o HTTP como la exposición común.
Esta limitación impide calcular directamente los registros vulnerados, las organizaciones vulnerables o los usuarios afectados. Los investigadores no publicaron una lista de propietarios de los objetivos, y hacerlo podría crear un riesgo adicional.
La medición de autenticación también varía según el producto. Solo 12 de las 17 categorías de productos tenían recuentos de desafíos resueltos. Un guion en el conjunto de datos indicaba una consulta incompleta, no una ausencia confirmada de autenticación.
El análisis geográfico también fue limitado. Mysterium informó atribución por país únicamente para un subconjunto de respuestas de Ollama en su puerto predeterminado. Cualquier afirmación amplia sobre qué países o industrias están más expuestos iría más allá de la evidencia.
El recuento de endpoints también puede incluir múltiples servicios operados por una organización. A la inversa, un endpoint puede situarse delante de un entorno compartido más amplio. El número de direcciones accesibles no es el número de empresas afectadas.
La cobertura del escáner presenta otra incertidumbre. Un índice, calendario de consultas o huella distintos pueden devolver una población diferente. Los servicios se conectan y desconectan, cambian banners, se trasladan detrás de proxies o reciben parches.
Estas limitaciones no eliminan el hallazgo. Cambian la conclusión de “36.769 sistemas comprometidos” por algo más preciso: miles de servicios de IA reconocibles eran accesibles mediante un índice público de escaneo.
Esa condición es valiosa para los atacantes antes de que comience la explotación. La identificación de productos ayuda a automatizar la correlación de vulnerabilidades. Un escáner puede buscar una interfaz conocida, estimar su versión y probar rutas aplicables a escala.
La diferencia entre exposición y compromiso se parece a una puerta sin llave que da a la calle. Ver la puerta no demuestra que alguien haya entrado. Sí muestra que la propiedad depende en mayor medida de todos los controles interiores restantes.
La cifra de 2,02 por ciento del informe también exige cautela. La autenticación HTTP básica no es intrínsecamente mejor que la autenticación moderna de aplicaciones en todas las arquitecturas. Un proxy mal gestionado puede introducir sus propias debilidades.
El principio más sólido es la defensa en profundidad. Un servicio de IA sensible no debería depender de un único inicio de sesión de aplicación cuando existen redes privadas, gateways autenticados, proxies conscientes de identidad y reglas de entrada limitadas.
También existe un incentivo comercial detrás de algunos de los comentarios más amplios sobre la exposición de la IA. Los proveedores de seguridad se benefician cuando las organizaciones compran productos de descubrimiento, escaneo, identidad y supervisión. Sus recomendaciones deben evaluarse frente a la evidencia técnica.
Mysterium es en sí misma una empresa de VPN, lo que hace que la privacidad de red sea relevante para su negocio. Eso no invalida su conjunto de datos. Hace más importantes los métodos transparentes, las huellas reproducibles y la confirmación independiente.
El estudio publicó sus huellas y explicó los resultados excluidos, las brechas por límites de tasa y las categorías subestimadas. Estas decisiones hacen que la medición central sea más fácil de comprobar que una afirmación basada únicamente en telemetría privada.
El siguiente paso útil de investigación es la validación controlada. Equipos independientes deberían repetir las consultas, muestrear el comportamiento de los endpoints sin acceder a contenido sensible y seguir cómo cambia la población tras la divulgación.
Una cifra decreciente sugeriría que los operadores o mantenedores de software respondieron. Una cifra estable indicaría que el despliegue inseguro es estructural en lugar de temporal.
La verdadera disyuntiva es la velocidad de despliegue frente al control verificable
El estudio de Mysterium sobre endpoints de IA expuestos cuestiona la idea de que el autoalojamiento ofrece privacidad automáticamente.
La IA alojada concentra la confianza en un proveedor. Los clientes dependen de contratos, aislamiento del servicio, controles de retención, políticas de acceso y el programa de seguridad del proveedor.
El autoalojamiento redistribuye esa confianza. La organización controla el hardware y el despliegue, pero también hereda las tareas de parcheado, gestión de identidades, diseño de red, registro, copias de seguridad y respuesta a incidentes.
Puede ser la elección adecuada para información regulada o cargas de trabajo especializadas. No es la opción más fácil por defecto. El servidor local debe operarse como infraestructura sensible, no como un experimento de escritorio que terminó siendo compartido.
La velocidad genera la tensión central. Los marcos de IA están diseñados para reducir la distancia entre una idea y una aplicación funcional. Un investigador puede lanzar una interfaz, adjuntar un modelo, conectar documentos y compartir el resultado rápidamente.
Cada comodidad puede ocultar una decisión operativa. Exponer un puerto facilita la colaboración. Almacenar un token en un flujo de trabajo agiliza la integración. Otorgar permisos amplios evita errores de autorización repetidos.
Esas decisiones se acumulan en un entorno que funciona antes de que alguien haya definido su límite de seguridad. La aplicación se vuelve útil, atrae usuarios y se acerca a producción mientras conserva sus controles experimentales.
Los procesos de seguridad tradicionales también pueden contribuir a la brecha. Si obtener un entorno aprobado tarda semanas, los empleados construirán alrededor del proceso. Bloquear todos los servicios de IA sin proporcionar una vía utilizable fomenta alternativas no gestionadas.
Las organizaciones necesitan una ruta de despliegue lo bastante rápida para competir con la infraestructura en la sombra. Esa ruta debería proporcionar redes privadas, identidad gestionada, almacenamiento de secretos, registro, responsabilidad de parcheado y fechas de expiración de forma predeterminada.
Los experimentos de corta duración merecen fechas de expiración porque los sistemas temporales rara vez se eliminan solos. Una instancia en la nube creada para una demostración puede permanecer en línea después de que su propietario cambie de función u olvide el proyecto.
El inventario debe incluir toda la cadena operativa. Encontrar un servidor de modelos sin su almacén vectorial, motor de flujos de trabajo, host de contenedores y cuentas de servicio deja a los defensores con una imagen fragmentada.
La identidad merece la misma atención. Un agente debería recibir los permisos más limitados necesarios para su tarea. Las credenciales administrativas no deberían convertirse en la respuesta estándar cuando falla una integración.
Las credenciales almacenadas en flujos de trabajo públicos o previamente expuestos deberían rotarse. Eliminar el acceso a internet cierra una vía, pero no invalida un token que un atacante podría ya poseer.
Los registros deben cubrir acciones, no solo conversaciones. Los equipos necesitan saber qué herramienta invocó un agente, qué identidad utilizó, a qué recurso accedió y si la acción coincidía con un flujo de trabajo aprobado.
Esto es especialmente importante cuando las instrucciones del agente proceden de terceros. Una plantilla, plugin o skill importado puede alterar el comportamiento sin parecer código ejecutable. Las revisiones deben examinar tanto los paquetes convencionales como los archivos de control en lenguaje natural.
Los mantenedores de software también enfrentan presión. Las configuraciones seguras por defecto deberían dificultar la exposición accidental. Los productos pueden advertir cuando los servicios se vinculan a interfaces públicas, exigir credenciales en el primer uso y separar las rutas administrativas de los endpoints orientados al usuario.
La documentación importa porque los tutoriales a menudo se convierten en arquitectura de producción. Una guía de inicio rápido que expone un servicio sin explicar las consecuencias de red puede propagar el mismo error a miles de instalaciones.
Los proveedores de nube y modelos siguen formando parte de la comparación. Las plataformas gestionadas pueden reducir el trabajo de configuración, pero introducen riesgos de concentración en el proveedor y de permisos de cuenta. La respuesta no es que un modelo de alojamiento siempre gane.
La elección defendible es aquella cuyos controles pueden verificarse. Una organización debería saber dónde se ejecuta el modelo, quién puede alcanzarlo, qué datos procesa, qué identidades utiliza y con qué rapidez se puede revocar el acceso.
Tres señales mostrarán si la exposición disminuye
La próxima prueba será determinar si los mantenedores y operadores convierten un censo ampliamente difundido en una corrección medible.
La primera señal es un nuevo escaneo de internet que use las mismas huellas. Las medidas más reveladoras serán el total de endpoints confirmados y la proporción protegida por autenticación a nivel de red.
Un menor número de endpoints sugeriría que los operadores eliminaron el acceso público innecesario. Una mayor tasa de autenticación demostraría que los servicios siguieron siendo útiles mientras ganaban un perímetro.
Ningún cambio por sí solo es suficiente. Un endpoint puede desaparecer de una huella porque cambió su banner, mientras sigue siendo accesible. Por ello, los investigadores deberían documentar los cambios en las consultas y preservar mediciones comparables.
La segunda señal es la actuación de los principales mantenedores. Open WebUI merece especial atención porque representaba 18.529 endpoints, aproximadamente la mitad de la población confirmada por Mysterium.
Las advertencias sobre la vinculación pública, las credenciales iniciales obligatorias, las plantillas de despliegue más seguras y una guía más clara sobre proxies inversos reforzarían el argumento general del informe. El silencio o cambios meramente cosméticos en los avisos dejarían el problema operativo prácticamente intacto.
Los creadores de agentes deberían recibir un escrutinio aún mayor. Flowise, RAGFlow, Dify, n8n, Langflow y herramientas similares necesitan configuraciones seguras por defecto que reconozcan su acceso a secretos y sistemas externos.
La tercera señal es la evidencia de vulnerabilidades e incidentes. Nuevos avisos relacionados con autorización, divulgación de credenciales, ejecución remota o acceso de agentes a herramientas mostrarían cómo la exposición pública puede convertirse en una vía de ataque.
La explotación confirmada reforzaría la urgencia, pero los defensores no deberían esperar a que ocurra. La ausencia de incidentes divulgados no demuestra seguridad cuando los propietarios de los activos podrían carecer de registros o visibilidad.
Las organizaciones pueden actuar antes de que lleguen esas señales. Deberían inventariar los servicios de IA, comprobar qué interfaces son accesibles públicamente e identificar a las personas responsables de cada despliegue.
Todo lo que no requiera acceso público debería vincularse a una interfaz privada. Los servicios que deban seguir siendo accesibles deberían situarse detrás de puertas de enlace autenticadas, con identidades limitadas y parches actualizados.
Los creadores de agentes necesitan un tratamiento adicional como infraestructura de secretos. Los equipos deberían revisar las integraciones almacenadas, rotar las credenciales expuestas, inspeccionar los flujos de trabajo importados y registrar las acciones de los agentes en los sistemas conectados.
El recuento de endpoints de IA expuestos de Mysterium acabará quedando desactualizado. Es lo esperable. La cuestión importante es si el próximo recuento reflejará controles mejores o simplemente una colección mayor de servicios ignorados.
Para desarrolladores, compradores empresariales y usuarios de IA, la prueba práctica es sencilla: ¿puede la organización demostrar quién puede acceder a cada sistema y qué puede hacer ese sistema? Si la respuesta depende de suposiciones, el despliegue no está proporcionando el control que prometía el autoalojamiento.
