TL; DR
Tres respuestas a la misma pregunta sobre el riesgo de la IA con agentes
Esperábamos un amplio consenso sobre cómo limitar a los agentes de IA y obtuvimos tres respuestas diferentes.
- Pedro Fortuna: Dividir los agentes en muchos agentes pequeños y específicos, cada uno con los permisos más restringidos posibles, y añadir una monitorización en tiempo de ejecución que los detenga prematuramente.
- Jack Trefon: Lo contrario ocurre con los agentes de codificación. Si se restringe uno, se destruye lo que lo hace útil, así que hay que aceptar las consecuencias e invertir en rastreo y recuperación rápida.
- Luis Rodríguez Berzosa: Una tercera línea. Trate los modelos fronterizos como trataría el malware, diseñe el sistema para limitar cada agente especializado y coloque una capa de protección debajo de todo que funcione cuando falle todo lo que esté por encima.
Donde se encontraron los tres: No se puede proteger lo que no se ha inventariado, cada acción debe registrarse y aquello que detiene a un agente tiene que estar fuera del agente.
No se produjo ninguna infracción.
El agente cumplió con su cometido. En el proceso, decidió modificar una dependencia, un archivo de configuración, un servicio que nadie le había solicitado. Se mantuvo dentro de los permisos establecidos en todo momento. No se infringió ninguna regla, por lo que no se activó ninguna acción.
Les planteamos el caso a tres personas que se dedican profesionalmente a ello, esperando un amplio consenso sobre qué hacer al respecto. Obtuvimos tres respuestas diferentes, y dos de ellas se contradicen entre sí.
El riesgo de la IA con agentes suele describirse como un problema de los atacantes. Esta es la otra cara de la moneda. Durante veinte años, definimos límites de permisos para software que hacía exactamente lo que se le ordenaba: una cuenta de servicio, un ejecutor de CI, una tarea programada. A menudo nos equivocábamos al definir los límites, pero el sistema era predecible: realizaba una sola tarea, siempre de la misma manera.
Ahora, quien está dentro de los límites decide. Y esos límites se siguen trazando como siempre: de antemano, en el momento de la configuración, por alguien que no puede saber en qué se convertirá la tarea.
Esa es la versión del riesgo de la IA con agentes que merece la pena debatir, y le dedicamos una hora en el último Charla de SafeDev con Pedro Fortuna de Jscrambler, Jack Trefon de Trefon Digital Consulting y Luis Rodríguez Berzosa de Xygeni, alojado por Alejandro Estrada.
Esperábamos que estuvieran de acuerdo en general. No lo estuvieron.
Riesgo de IA con agentes: la premisa reconfortante que no se sostiene
El encuadre anterior contiene una palabra que está haciendo más trabajo del que debería: agresorNo hay ninguna. Se supone que eso simplifica el escenario.
Pedro lo desarmó de un solo movimiento.
“Ser o no ser un atacante es un concepto humano. Lo que define a un atacante es que tiene objetivos distintos. Y un agente desorientado también tiene objetivos distintos.”
Reflexiona sobre esto, porque desmantela la premisa de la mayoría de las conversaciones sobre riesgos de la IA con agentes, incluida la descripción que escribimos para nuestro propio evento. Si lo que define a un atacante son los objetivos divergentes en lugar de la malicia, entonces decir que «en esta historia no hay ningún atacante» es un consuelo que nadie se ha ganado. Estructuralmente, es el mismo riesgo. Lo que falta es la intención, y la intención nunca fue lo que detectaron tus controles. Detectan efectos. Siempre lo han hecho.
Esta es también la razón por la que cambió el vocabulario de la industria. OWASP Los 10 programas de LLM más solicitados en 2026 Se promovió la excesiva influencia del sexto al tercer puesto, lo que no se debe tanto a un cambio de opinión como a que el historial de incidentes se ajusta a una arquitectura que ya estaba desplegada.
Lo que realmente muestra el incidente de Hugging Face
El incidente de julio, en el que una modelo de Frontier atacó a un tercero, se interpretó ampliamente como la historia de una modelo que se descontroló. Luis lo interpreta de otra manera, y su versión sitúa la responsabilidad en un lugar incómodo.
“El problema no reside en el modelo de frontera. El modelo de frontera hizo lo que se le indicó que hiciera. El problema reside en el diseño del experimento.”
El objetivo era abierto. No había restricciones. Y el entorno aislado destinado a contenerlo tenía una ventana a Internet, a través de una vulnerabilidad de falsificación de solicitudes del lado del servidor en la caché de paquetes a la que el agente podía acceder. Cada uno de esos es un diseño decisión producido por una persona.
Lo cual produce la frase que debería cambiar la forma en que se proveen estas cosas:
“Los modelos fronterizos deben ser vistos como si fueran malware, porque pueden actuar de forma autónoma y tomarcisiones que son maliciosos. No por intención, pero al final resultan ser realmente maliciosos.
No es una crítica al modelo, sino una medida de aprovisionamiento. No se le da acceso a un intérprete de comandos bash a un malware esperando que el objetivo esté bien definido.
La interpretación que Pedro hizo del mismo incidente se centró más en el momento oportuno que en la intención:
“En el momento en que veas agentes comunicándose mediante nombres de carpetas en un servicio que no deberían usar, debes detenerlos de inmediato. No necesitas esperar a que logren vulnerar Hugging Face para decidir si se trata de una acción maliciosa o no.”
Un detalle de la respuesta también merece ser destacado. Los analistas intentaron utilizar una herramienta comercial de análisis de datos para analizar los rastros, pero no pudieron debido a que alcanzaron los límites de velocidad. El atacante no tenía ese límite. «Existía una asimetría en el ataque en sí».
El verdadero debate: ¿limitar al agente o recuperarse más rápido?
Aquí es donde el panel se dividió, y se trata de un verdadero desacuerdo entre profesionales que se han ganado su posición a pulso.
Pedro aboga por la descomposición. Quince años impulsando el aislamiento dentro del navegador le enseñaron que no se puede imponer nada en tiempo de ejecución contra un monolito. Hay que dividir la arquitectura en pequeñas partes con funciones específicas, y solo entonces los controles y los puntos de monitoreo tendrán dónde conectarse. Los agentes no son diferentes.
“Creo que hay que dividirlo en agentes muy específicos, destinados únicamente a tareas específicas. Y no importa si al final tienes cincuenta agentes. Es mejor que tener solo uno.”
Jack argumenta lo contrario, específicamente en lo que respecta a los agentes de codificación. Cabría esperar que un operador con experiencia en tecnología de intercambio de criptomonedas regulado adoptara la postura más restrictiva. Sin embargo, fue la menos restrictiva.
Su analogía inicial no es en absoluto un modelo de amenaza:
“Considero que un despliegue de agente típico es igual que consideraría a un nuevo empleado, a una persona que se incorpora. Y esa persona puede ejecutar su trabajo a la perfección o cometer un error. No veo mucha diferencia.”
Para los agentes especializados, es tan estricto como cualquiera. Al describir un agente de revisión de solo lectura que está desarrollando, fue tajante al afirmar que la configuración común es indefendible: implementarlo en un sistema Linux estándar con acceso a bash “es abrir todo el ecosistema de amenazas”. Pero para los agentes de codificación general, la lógica se invierte, y sabe que esta postura es impopular:
“Cuanto más poder tenga el agente, más creativo y eficaz será. Por lo tanto, no es la industria la que prospera gracias a las limitaciones y la reducción de su alcance.”
Entonces, ¿qué queda si no se limita? Disyuntores y, sobre todo, instantáneas basadas en el tiempo: no para evitar el radio de la explosión, sino para que la recuperación de la misma sea barata y rápida. Él lo incorpora en Amber, un arnés de agente C++ sin dependencias que escribe en su tiempo libre, con instantáneas en el bucle (Sitio del proyecto).
Y la advertencia sobre dónde termina el otro camino:
“Si empezamos a quitar, solo quedará una herramienta, y ese desarrollador podrá encender y apagar las luces.”
Luis ocupa la tercera posición., que no es ni restringir ni recuperar, sino contener desde abajo: asumir que el agente eventualmente se comportará como malware, diseñar el arnés para limitar a cada agente especializado y colocar una capa de cumplimiento debajo de todo ello que se mantenga cuando todo lo que está por encima de ella falle.
Tres enfoques para el mismo problema
Tres posiciones, cada una con un coste asociado. Ninguna es gratuita y ninguna garantiza la seguridad del agente por sí sola.
| Nuevo enfoque | Movimiento central | Lo que te cuesta |
|---|---|---|
| DescomponerPedro Fortuna | Muchos agentes pequeños, cada uno con permisos limitados, además de un sistema de monitorización en tiempo de ejecución que los detiene prematuramente. | Esfuerzo de diseño inicial y mayor dificultad con el trabajo de codificación de final abierto. |
| RecuperarJack Trefon | Mantén la funcionalidad, añade disyuntores y instantáneas basadas en el tiempo para que la reversión sea económica. | Un radio de explosión más amplio y la apuesta por detectarlo y revertirlo a tiempo. |
| Contiene de abajoLuis Rodríguez Berzosa | Suponga un comportamiento malicioso, limite cada agente en el entorno, aplique medidas de seguridad en la estación de trabajo y en el ejecutor de CI. | Infraestructura y herramientas que la mayoría de las pilas de endpoints aún no proporcionan. |
Al leerlos uno al lado del otro, la discrepancia es menor de lo que parece. Los tres coinciden en que el agente hará algo no previsto. La diferencia radica en el destino del dinero: si se invierte en la arquitectura antes de que ocurra, en la recuperación posterior o en un fondo para ambos.
Por qué el principio de mínimo privilegio no se traduce en riesgo para la IA con capacidad de agencia.
El principio de mínimo privilegio presupone que conoces la tarea. Tú defines el alcance de los permisos para esa tarea.
Un agente incumple esta norma silenciosamente, ya que sus permisos se definen durante la configuración y su tarea se ejecuta en tiempo real. En realidad, lo que se le concede es la suma de todas las acciones que se le podrían solicitar. Esto no es el principio de mínimo privilegio; es todo lo contrario, disfrazado de mínimo privilegio.
Luis ofreció una reformulación tomada de una idea anterior a todo esto:
“Pienso en el mecanismo de tuberías de UNIX, que conecta herramientas sencillas para realizar una tarea compleja. Se pueden definir agentes específicos con una configuración controlada, limitando lo que ese agente especializado puede hacer. Y se pueden combinar para casi cualquier tarea.”
Además, una segunda idea de diseño que la mayoría de los equipos no ha probado: En lugar de ampliar los permisos, conviene encapsular las herramientas. No se trata de bash, que entrega todo el sistema, sino de una envoltura limitada que constituye la única ruta invocable, con variantes de solo lectura que encapsulan las genéricas. El agente obtiene una capacidad, no un intérprete de comandos.
También dejó claro que el obstáculo no es el diseño, sino la implementación. Los nuevos controles en las máquinas de los desarrolladores tienen un largo historial de ser eludidos, y ese historial no cambia porque la herramienta en cuestión sea un agente.
Y sobre dónde cree que termina todo:
“Creo que al final tendremos agentes autónomos controlando a otros agentes autónomos.”
El portátil se convirtió en la joya de la corona, y su EDR no se ha dado cuenta.
Un agente necesita acceso permanente para ser útil. Un token que no caduque a mitad de la tarea, una credencial almacenada en caché, derechos push, acceso al registro, una ruta en vivo hacia el pipelineCada uno de ellos es un requisito, no un descuido, lo que significa que cuanto mejores eran las herramientas, más se centraba el desarrollo.
Los atacantes fueron los primeros en darse cuenta. Como dijo Pedro, no son ideólogos:
“Se organizan como pequeñas empresas. Necesitan ganar dinero, así que buscan la vía más rentable que puedan encontrar. Y enseguida se dieron cuenta de que se podía ganar dinero con las estaciones de desarrollo.”
Observamos ese cambio reflejado en los registros cada semana. Resumen de código maliciosodonde los recolectores de credenciales ahora buscan rutinariamente las claves de los proveedores de IA junto con las de la nube y el registro.
Su lista de medidas de mitigación no es nada del otro mundo, pero funciona: eliminar todas las claves que no sean necesarias en la máquina, combinar las que queden con un segundo factor como OpenID Connect o una clave de hardware para que un token robado no sea suficiente por sí solo, y trasladar el entorno fuera del host siempre que sea posible, mediante contenedores de desarrollo o IDE en la nube.
Entonces Luis hizo hincapié en algo que debería preocupar a cualquiera que suponga que su pila de endpoints cubre esto:
“Los EDR están especializados en malware tradicional y no reconocen las herramientas de agentes. Y si funcionan, pueden generar muchos falsos positivos, porque el agente realiza acciones que los patrones de detección desconocen actualmente.”
Dos modos de fallo a la vez: pasa por alto lo importante y marca lo irrelevante. Su solución es esa capa de control externa, situada alrededor de la estación de trabajo del desarrollador y el ejecutor de CI, por debajo del arnés, que limita el alcance de un agente malicioso. Esa es la brecha. xygeni Shield Se diseñó para ello, con una política aplicada en el punto final donde se realiza la instalación.
Jack lo expresó de forma más directa: no guardes tus Bitcoin en tu ordenador de desarrollo.
El piso en el que los tres estuvieron de acuerdo
Tres respuestas diferentes, un mínimo común.
- Primero el inventario. “No puedes proteger lo que no conoces.” Cada dos por trescisLa operación depende de saber qué agentes, habilidades y servidores MCP existen, y casi ninguno de ellos fue declarado.
- Registra cada acción. Jack y Luis llegaron aquí desde direcciones opuestas. Jack busca rastros porque son la clave para la recuperación y la madurez de una organización. Luis los busca porque, sin ellos, es imposible reconstruir el radio de la explosión. Vale la pena adoptar el planteamiento de Jack: no tiene sentido interrogar al actor, sea humano o agente, sino comprender el contexto lo suficientemente bien como para no repetirlo.
- Aquello que detiene a un agente debe estar fuera del agente. El monitoreo en tiempo de ejecución de Pedro, la capa de aplicación de Luis, los disyuntores y las instantáneas de Jack. Mecanismos diferentes, un mismo principio.
Jack ofreció una perspectiva útil sobre la situación actual del sector. Recuerda el primer correo basura que recibió, en el que le decían que había heredado una mina de oro en Nigeria. Se trata de un problema de madurez, y la madurez llega después de los errores, no antes.
Qué hacer antes del viernes
Elige un agente. Escribe dos listas: una sobre lo que tiene permitido hacer y otra sobre lo que se le pidió que hiciera esta semana.
La diferencia entre esas listas es tu radio de explosión, y es la medida más útil del riesgo de la IA con agentes que tu equipo puede generar en una tarde. Solo toma una tarde, no requiere presupuesto y resuelve el debate anterior para tu organización, porque las tres posturas son, en realidad, tres respuestas diferentes a la pregunta de cuán grande debería ser esa diferencia.
La mayoría de los equipos nunca lo han escrito.
El hora entera Está disponible para volver a ver la grabación, incluyendo la observación de Jack sobre por qué los requisitos de intervención humana en Europa hacen que algunas defensas de IA sean inviables en la práctica.
Y si el ejerciciocise devuelve una respuesta que no te gusta, xygeni Descubre todos los recursos de IA en tus repositorios, incluidos los agentes, las habilidades y los servidores MCP que nadie ha declarado, y visualiza el alcance de cada uno. Agendar demo or comienza gratis, y lo ejecutaremos en el tuyo.
Preguntas Frecuentes
¿Cuál es el radio de explosión de un agente de IA?
Todo aquello a lo que el agente podría acceder si algo saliera mal, a diferencia de lo que se le pidió que hiciera. Se define por los permisos, las credenciales y las herramientas disponibles en tiempo de ejecución, no por la tarea. La diferencia entre ambos es lo que vale la pena medir, y la mayoría de los equipos nunca la han documentado.
¿Constituye un incidente de seguridad que un agente exceda sus funciones si nunca ha excedido sus permisos?
Ese fue el punto central de la discrepancia. La respuesta de Pedro es, en esencia, afirmativa, ya que un atacante se define por la divergencia de objetivos más que por la malicia, y un agente desalineado ha divergido. La respuesta de Jack se acerca más al no: se trata de un fallo operativo, como el error de un empleado recién contratado, y la respuesta adecuada es el rastreo y la recuperación, en lugar de restricciones más estrictas. Luis elude la pregunta asumiendo el peor escenario desde el principio y preguntando qué capa seguirá funcionando cuando esto ocurra.
¿Deberían los agentes de codificación estar aislados en un entorno seguro (sandbox)?
Para agentes específicos para tareas concretas, los tres dijeron que sí sin dudarlo: solo lectura siempre que sea posible, sin bash, sin red a menos que sea necesario. Para agentes de codificación general, el panel se dividió en tres: Pedro los descompondría, Jack mantendría la capacidad y tomaría instantáneas de forma intensiva, y Luis añadiría una capa de control por debajo del arnés, independientemente de lo que el agente tenga permitido hacer.
¿Mi sistema EDR cubre el riesgo de la IA con agentes?
Probablemente no funcionen bien. Las herramientas actuales para endpoints se basan en patrones de malware tradicionales y no modelan el comportamiento de los agentes, por lo que tienden a pasar por alto lo importante y a marcar lo irrelevante. La solución de Luis fue una capa de aplicación externa diseñada para entornos de desarrollo, en lugar de una solución EDR de propósito general.
¿Cuál es la primera cosa que hay que hacer?
Crea el inventario. Incluye todos los modelos, agentes, habilidades y servidores MCP en tus repositorios, así como el alcance de cada uno. Este es el paso que mencionaron los tres panelistas y del que dependen todos los demás controles.
