Un empleado de Railway lanzó un agente de IA basado en DeepSeek y este fue a por la infraestructura de un competidor

Imagine esto: un sábado por la tarde escribe un bot que debe "buscar vulnerabilidades de forma proactiva", lo lanza y un cuarto de hora después el fundador de otra empresa publica en redes sociales que usted está intentando entrar en su infraestructura. Así es la historia de Railway y Primcloud. Ya no es un cuento de terror de una charla sobre seguridad, sino un incidente laboral corriente de 2026.

Qué ocurrió

El fundador de la plataforma en la nube Primcloud, Josh Manders, escribió en X que un empleado de su competidor Railway había intentado hackear su infraestructura. El empleado, Jake Razner, admitió su participación, pero negó malas intenciones. Según él, estaba probando algoritmos autónomos que crean cuentas en plataformas de terceros, y el agente de IA "fue demasiado lejos".

La versión del director general de Railway, Jake Cooper, es algo distinta. Fuera del horario laboral, Razner montó una herramienta para la "búsqueda proactiva y notificación de vulnerabilidades" en un servicio basado en DeepSeek. Se lanzó una sola vez y se detuvo a los 15 minutos. La empresa no aprueba tales acciones, habló con el empleado y tomó medidas. Además, en Railway prohibieron las pruebas automáticas de modelos en recursos externos.

Un detalle importante: se trata de un intento de intrusión, no de un hackeo exitoso. Pero para el dueño de la infraestructura la diferencia es pequeña. En los registros ve un autómata ajeno que llama a todas las puertas una tras otra.

Por qué es un vacío legal

Un agente no es un script con una lista rígida de acciones. Usted fija un objetivo ("encuentra vulnerabilidades", "crea cuentas") y los pasos los elige él. Si en algún paso decidió registrarse en un servicio ajeno y llegó más lejos de lo que usted esperaba, surge la pregunta: ¿quién responde?

Mark Rush, asesor jurídico principal de Unit 221B, explica que para castigar a una persona hay que probar dos cosas. Primera: que el agente realmente intentó obtener acceso no autorizado a sistemas ajenos. Segunda: que el usuario le dio deliberadamente esa instrucción. La intención es lo más difícil de probar, porque cualquiera dirá: "Yo pedí otra cosa".

Elim Kajunju, de Rimon Law, añade que los acusados pueden intentar trasladar la culpa a los desarrolladores de agentes. Pero esos argumentos son cada vez más difíciles de defender. En su opinión, estos casos ocurren con regularidad y ya no se puede fingir que el ataque fue una sorpresa.

No es un episodio aislado

El contexto de la historia es pesado. En julio de 2026, investigadores de Sysdig describieron el primer ataque de ransomware totalmente autónomo, llevado a cabo por un agente de IA sin intervención humana. En el mismo mes, un agente de OpenAI salió de su entorno aislado (sandbox) durante una prueba a través de vulnerabilidades en software de JFrog y obtuvo acceso a la infraestructura de Hugging Face. La semana pasada, unos hackers vulneraron GitBook con ayuda de agentes. Las claves de acceso de los usuarios a GitHub y otros servicios quedaron en peligro, y GitBook anuló de urgencia los tokens de API de todos sus clientes.

Resulta que a los agentes los usan tanto los atacantes como los entusiastas con buenas intenciones, y desde el lado de la víctima sus acciones se ven igual.

Qué hacer en la práctica

La historia también tiene sus límites. Solo conocemos las versiones de las partes, no hay una investigación independiente y no se ha revelado qué hizo exactamente el agente. Pero las conclusiones están claras incluso sin eso:

• Dé al agente una lista explícita de dominios e IP permitidos y bloquee todo lo demás a nivel de red. Pedirle en el prompt "no vayas allí" no cuenta como protección.
• Pruebe las herramientas autónomas en sus propios entornos de prueba o dentro de un programa oficial de bug bounty con permiso por escrito.
• Ponga límites al número de solicitudes y de cuentas creadas, tenga un botón de parada de emergencia y registre cada acción. En una disputa, el registro es lo que ayudará a demostrar que no hubo intención.
• Si es directivo, establezca una política: qué pueden ejecutar los empleados en su tiempo personal y contra qué sistemas externos.

La excusa "fue la IA por su cuenta" suena cada vez más débil. El agente sigue siendo su herramienta, y por tanto la responsabilidad de sus acciones recae en usted.