No le des ideas a la IA

Quizá el miedo estaba mal formulado.

“No le des ideas a la IA” empieza a sonar menos a broma cuando vemos agentes accediendo a sistemas inesperados, IA utilizada para automatizar ciberataques, credenciales robadas o herramientas instaladas dentro de infraestructuras comprometidas.

El problema es que tendemos a meterlo todo en el mismo saco.

No es lo mismo que una IA realice una acción no prevista, que una persona utilice una IA para atacar, o que un tercero robe accesos y utilice esa infraestructura para ejecutar sus propias acciones.

Desde fuera, los tres casos pueden parecer lo mismo. Incluso pueden dejar nombres parecidos en los logs.

Pero la diferencia es fundamental.

Cuando vemos una IA haciendo algo que no debería, ¿sabemos realmente quién está actuando?

Ya no hablamos de modelos. Hablamos de agentes con acceso

El cambio no está solo en que los modelos sean más capaces. Está en todo lo que ahora pueden tocar.

Un agente puede tener acceso a una terminal, un navegador, repositorios, APIs, archivos, servicios cloud, correo electrónico, herramientas internas o credenciales. Puede consultar información, ejecutar comandos y encadenar acciones sin que una persona intervenga en cada paso.

Ahí cambia la naturaleza del riesgo.

Una respuesta equivocada puede quedarse en una mala recomendación. Una decisión equivocada dentro de un sistema con acceso real puede convertirse en una acción: modificar un archivo, crear un recurso, enviar información o ejecutar un comando.

El riesgo no aumenta solo con la inteligencia del modelo. Aumenta con el acceso que le damos.

Una acción inesperada no siempre significa un ataque

En julio de 2026, varios modelos de OpenAI lograron eludir controles de aislamiento durante evaluaciones internas de ciberseguridad, obtener acceso a Internet y alcanzar sistemas de terceros, entre ellos Hugging Face. OpenAI reconoció después que algunas de aquellas acciones se alejaron del propósito original de las tareas asignadas.

Anthropic ha documentado incidentes similares durante sus propias evaluaciones, en los que modelos Claude consiguieron acceso no autorizado a sistemas reales de terceros.

Pero describir estos casos como una IA que “quiso escapar” simplifica demasiado lo ocurrido.

El problema es más interesante: el sistema encontró una estrategia válida para avanzar hacia su objetivo, pero inválida para las restricciones que nosotros creíamos haber establecido.

Podemos definir muy bien qué queremos que haga un agente y, al mismo tiempo, definir mal hasta dónde puede llegar para conseguirlo.

Cuando alguien convierte al agente en arma

El segundo escenario es distinto: la IA no se equivoca. Puede estar funcionando exactamente como fue diseñada.

El problema es quién la está utilizando y para qué.

En su último informe de amenazas, Anthropic describe operaciones en las que Claude fue utilizado para reconocimiento, creación de infraestructura de phishing, ejecución de comandos, robo de credenciales, movimiento lateral y exfiltración de datos. En algunos casos, agentes llegaron a ejecutar gran parte de esas tareas de forma autónoma y sobre varios objetivos en paralelo.

La diferencia respecto a herramientas anteriores no está solo en lo que pueden hacer, sino en la velocidad, la escala y el grado de autonomía con el que pueden hacerlo.

La IA no necesita tener una intención maliciosa para multiplicar una intención maliciosa.

El agente también puede ser la víctima

También hay un tercer escenario: que el problema no esté en el agente, sino en quién ha conseguido acceso a él.

API keys, tokens de sesión, credenciales cloud, cuentas de desarrollador o servidores pueden convertirse en la puerta de entrada para utilizar herramientas de IA dentro de una infraestructura comprometida.

Eso obliga a ser especialmente cuidadosos con la atribución. Que en una máquina aparezca Claude, OpenAI o cualquier otra herramienta de IA no significa que esa IA haya iniciado el ataque.

Podemos encontrar recursos o herramientas que nadie del equipo recuerda haber desplegado, procesos inesperados o servicios asociados a agentes dentro de una cuenta comprometida. Todo ello puede ser una pista, pero no explica por sí solo quién accedió, cómo lo hizo ni con qué objetivo.

El agente, en ese caso, puede formar parte de la propia superficie comprometida.

La IA no siempre es el atacante. A veces es una herramienta que alguien ha conseguido utilizar dentro del ataque.

El prompt injection introduce un problema distinto: el agente puede recibir instrucciones desde el propio contenido que está procesando.

Una web, un correo, un documento, un issue de GitHub o un archivo pueden contener texto pensado no para una persona, sino para influir en el comportamiento del agente que lo está leyendo.

Es el equivalente, para una máquina, de buena parte de la ingeniería social que conocemos en ciberseguridad. Antes intentábamos enseñar a una persona a desconfiar de un “haz clic aquí”. Ahora también necesitamos diseñar agentes capaces de desconfiar de un “ignora las instrucciones anteriores”.

OpenAI describe precisamente este riesgo en sistemas capaces de navegar, leer contenido externo y utilizar herramientas.

La consecuencia es importante: el contenido deja de ser únicamente información y puede convertirse también en una instrucción.

Y cuanto más acceso tenga el agente, mayor puede ser el impacto de obedecerla.

El problema de la atribución

Cuando ocurre un incidente con un agente, reconstruir lo sucedido puede ser más difícil de lo que parece.

¿La acción partió del propio agente? ¿La provocó una instrucción externa? ¿La pidió un usuario? ¿Se utilizaron credenciales robadas? ¿Fue una automatización legítima que tomó una ruta inesperada? ¿Había otro agente detrás?

En seguridad tradicional intentamos responder a una pregunta relativamente directa: quién hizo qué.

Con sistemas agentic aparece otra capa: quién pidió qué a quién, con qué permisos y a través de qué herramienta.

Esa cadena puede incluir personas, modelos, APIs, herramientas externas y automatizaciones. Y cuanto más larga sea, más difícil resulta reconstruir responsabilidades, intenciones y puntos de fallo.

Por eso, en este contexto, los logs ya no deberían limitarse a registrar acciones. También deberían ayudarnos a entender cómo se llegó hasta ellas.

La nueva superficie de ataque no es la IA. Es todo lo que puede tocar

Un chatbot sin acceso externo y un agente conectado a diez herramientas no tienen la misma superficie de riesgo.

Cuantas más capacidades añadimos, más importante es diseñar qué puede alcanzar realmente el sistema: qué credenciales utiliza, a qué entornos accede, qué acciones puede ejecutar, qué límites económicos tiene y cómo podemos revocar ese acceso si algo sale mal.

Aquí entran principios conocidos como el mínimo privilegio, el aislamiento de entornos, los permisos limitados, las credenciales temporales, la trazabilidad o la supervisión de acciones críticas.

No se trata de hacer al agente menos capaz. Se trata de evitar que una capacidad útil se convierta en acceso innecesario.

No tenemos que limitar lo que la IA sabe. Tenemos que limitar lo que puede alcanzar.

Conclusión

Quizá el miedo estaba mal formulado.

El problema no es que una IA tenga una idea que nosotros no habíamos tenido. De hecho, precisamente para eso la utilizamos: para encontrar patrones, alternativas y caminos que no siempre vemos.

El riesgo aparece cuando esa capacidad se combina con acceso, herramientas, credenciales y límites mal definidos. Entonces una idea deja de ser solo una posibilidad y puede convertirse en una acción real.

Por eso, diseñar sistemas agentic no consiste únicamente en decidir qué pueden hacer, sino también en establecer con claridad hasta dónde pueden llegar, qué accesos necesitan, qué deben registrar y cómo podemos intervenir si algo se desvía.

Volvemos así al título: no se trata de no darle ideas a la IA. Se trata de diseñar bien qué puede hacer con ellas.

Si un agente encuentra una forma de hacer algo que nosotros nunca imaginamos, ¿hemos diseñado también una forma de impedirle hacer aquello que nunca habríamos autorizado?