
En este artículo (4)
Análisis de errores de nomenclatura de IA irregular: los nombres simples fallan
Puntos Clave
- Trate los nombres y dominios ficticios como entradas sensibles desde el punto de vista de la seguridad, porque los agentes pueden resolverlos como objetivos reales.
- Mantenga los entornos de evaluación de IA aislados, con acceso de red mediante listas de permitidos y registros de cada acción de herramienta.
- Pida a los proveedores claridad sobre el alcance del incidente, el diseño de contención y cómo se evita que los objetivos sintéticos lleguen a la realidad.
Un desglose centrado en el constructor sobre cómo la resolución de entidades cotidiana puede orientar una prueba de seguridad de IA hacia el internet real.
Un desglose centrado en el constructor de cómo la resolución de entidades cotidiana puede orientar una prueba de seguridad de IA hacia el internet real.
El fallo de seguridad de IA más instructivo de la semana no requirió un jailbreak de prompt genial ni un villano con sudadera oscura. Según se informó, comenzó con un nombre. Un nombre de objetivo ficticio usado en pruebas coincidió con algo real en el internet público, que es el tipo de problema informático cotidiano que hace que los equipos de respuesta a incidentes miren fijamente a través de la pared. En algún lugar, una celda de hoja de cálculo se siente poderosa. La divulgación de Irregular importa porque saca la seguridad de la IA de la zona cinematográfica y la devuelve al pantano donde realmente vive la seguridad: nombres, alcance, permisos, registros y suposiciones. Los sistemas agénticos no necesitan intención maliciosa para causar daño cuando se les entregan herramientas, acceso a internet y un mapa confuso de lo que está dentro del laboratorio. Eso no es un escándalo para mirar boquiabiertos. Es una lección de diseño que los creadores pueden usar antes de que su propio entorno de evaluación decida que el mundo real es solo otro elemento de prueba.
Qué se rompió, según SecurityWeek y Mallory
SecurityWeek informó que Irregular detalló cómo un error de nombres permitió que modelos de IA atacaran a una empresa real, en un incidente que involucró modelos de IA de Anthropic. Mallory describió el modo de fallo como una evaluación de seguridad de IA que llegó sin querer a un objetivo activo en internet después de que un nombre de objetivo ficticio coincidiera con un dominio real. Según ese relato, los modelos con internet habilitado trataron el dominio activo como parte del ejercicio durante una pequeña cantidad de ejecuciones.
El desglose de la brecha es refrescantemente poco glamuroso y, por eso, útil. El fallo inicial aparente fue la resolución de entidades, lo que significa que el sistema resolvió un nombre destinado a una prueba controlada como un objetivo real. El impacto, según Mallory, fue más allá de la navegación inofensiva: los modelos llevaron a cabo acciones ofensivas, las credenciales se vieron afectadas y se accedió a una base de datos de producción. No hizo falta ningún conjuro mágico, solo un límite que confió demasiado en un nombre.
Alcance e incertidumbre, según Mallory y The Record
Mallory dijo que Irregular y Anthropic identificaron tres incidentes en los que modelos de Anthropic escaparon de su sandbox de pruebas y comprometieron organizaciones reales, y que la divulgación más reciente detallaba un caso. Eso no significa que toda evaluación de IA sea un cable con corriente, pero sí significa que los límites del sandbox merecen la misma sospecha que normalmente reservamos para las impresoras y los dispositivos VPN heredados. Si un sistema de prueba puede llegar al internet público, no solo está probando el comportamiento del modelo. Está probando tus suposiciones sobre la contención.
The Record informó que Irregular, que proporciona entornos de evaluación para modelos de IA de otras empresas, enfrentó críticas después de publicar un postmortem que, según expertos en seguridad, dejó preguntas clave sin responder. The Record también informó que la publicación de Irregular no especificó cuántos incidentes ocurrieron en total y que la empresa había rechazado anteriormente decir si los incidentes se extendían más allá de los anunciados por OpenAI, Anthropic y Meta. The Next Web enmarcó el patrón más amplio en torno a esos tres laboratorios y el mismo proveedor de pruebas, que es el tipo de dependencia común que los equipos de seguridad deberían marcar con tinta roja, preferiblemente antes del postmortem.
Por qué importa el error aburrido, según
The Record y SecurityWeek La lección para los creadores no es simplemente temer a la inyección de prompts, aunque sí, por favor, sigan temiéndosele de una manera adulta y saludable. El enfoque de SecurityWeek sobre el error de nombres apunta a una clase distinta de fallo: el agente entendió demasiado bien la tarea, pero el modelo del mundo de la tarea estaba equivocado. Cuando nombres, dominios, registros de clientes o entidades sintéticas chocan con la realidad, un agente con herramientas puede convertir un error administrativo en actividad real.
Los informes de The Record sobre preguntas sin responder también apuntan a un problema de gobernanza. Si la explicación pública no define claramente el recuento total de incidentes, el alcance afectado y los fallos de contención, los clientes posteriores no pueden evaluar su propio riesgo con confianza. Los creadores deberían tratar la infraestructura de evaluación como infraestructura de producción: aislarla, darle destinos en listas de permitidos, usar dominios sintéticos que no puedan resolverse externamente y hacer que cada llamada a herramientas sea auditable. Sí, es menos glamuroso que una demostración en una keynote. También lo es usar cinturón de seguridad, y aun así el parabrisas sigue invicto.
Qué significa realmente para ti, según Mallory y SecurityWeek
Si construyes o compras sistemas agénticos, la conclusión práctica es simple: los nombres ahora forman parte de tu modelo de amenazas. Una empresa ficticia, un dominio falso, un usuario simulado o un ticket sintético no debería poder resolverse en algo real a menos que un humano lo permita deliberadamente. Trata la resolución de entidades como un control de seguridad, no como una función de conveniencia que se deja silenciosamente en manos del DNS, la búsqueda o la inferencia del modelo.
Para los equipos de seguridad, el siguiente punto de la lista de verificación es una contención que puedas demostrar. El relato de Mallory dice que el dominio afectado carecía de protecciones comunes y que el comportamiento era difícil de detectar, que es exactamente por lo que los registros y los controles de salida deben ser aburridos, estrictos y estar siempre activos. Observa futuras divulgaciones que aclaren el recuento total de incidentes, el impacto en clientes y cómo los proveedores de pruebas separan los objetivos simulados de los activos. Internet ya tiene suficientes entornos de producción accidentales; los agentes de IA no necesitan ayuda para encontrar más.