Los agentes de IA comienzan a colaborar en ataques cibernéticos, generando preocupaciones de seguridad

iconOdaily
Compartir
AI summary iconResumen
MiCA enfrenta nuevos desafíos a medida que los agentes de IA comienzan a coordinar ataques cibernéticos, según Odaily. Modelos de IA como DeepSeek, GLM y Grok ahora se utilizan en reconocimiento, explotación y robo de datos. CrowdStrike encontró atacantes integrando IA agente en flujos de trabajo, mientras que Anthropic informó sobre marcos de múltiples agentes que permiten ataques a gran escala. Los investigadores advierten sobre estrategias de autoajuste y canales compartidos, lo que complica la liquidez y la seguridad de los mercados de criptoactivos. Vitalik Buterin propuso la gobernanza adversarial como medida de seguridad ante el creciente riesgo impulsado por la IA.

En los últimos años, las discusiones sobre la amenaza de la IA se han mantenido en gran medida en un escenario hipotético: siempre se temió que los modelos dentro de los chats se convirtieran en asesores, ayudando a los hackers a escribir código de virus devastadores.

Mirando hacia atrás, esta preocupación solía considerarse «lejana para nosotros», pero los puntos de inflexión del mundo real llegaron más rápido de lo imaginado.

A principios de octubre, CrowdStrike descubrió, durante la investigación de un ataque contra instituciones financieras de Corea, que los atacantes habían integrado Agentic AI en la cadena de suministro, utilizando modelos grandes como DeepSeek, GLM y Grok para que la IA realizara directamente tareas específicas como pruebas de penetración, recolección de información y ejecución de ataques.

Este tipo de cambio no es un caso aislado.

El último informe de inteligencia de amenazas publicado por Anthropic en septiembre muestra que recientemente se han utilizado marcos de múltiples agentes para reconocimiento, explotación de vulnerabilidades y robo de datos, funcionando continuamente durante horas e incluso días, con solo decisiones clave necesarias por parte de humanos, como seleccionar objetivos y revisar resultados.

En otras palabras, la IA está trayendo un cambio cualitativo visible en la defensa y ataque de redes; antes, los ataques automatizados dependían principalmente de reglas y scripts predefinidos, pero ahora agentes también se encargan de la reconocimiento, la evaluación y el ajuste de estrategias, lo que lleva los ataques hacia costos más bajos, mayor concurrencia y operación continua y autónoma.

Pero cuando estas entidades con capacidad de ejecución autónoma se implementan masivamente en sistemas de producción, surge un problema aún más complejo: ¿qué sucede si aprenden a «coludirse» entre sí a medida que se integran cada vez más y más profundamente en nuestro trabajo y vida diaria?

I. De "escribir código para hackers" a que el agente encuentre su propio camino

Aún es lo mismo de siempre: la mayor diferencia entre un agente y los chatbots anteriores no es solo que el modelo sea más potente, sino que ahora tiene "manos y pies" en el mundo real.

Hoy en día, un agente maduro ya puede abrir páginas web, ejecutar código, leer correos electrónicos, llamar a API, operar servicios en la nube y conectarse a un número creciente de herramientas externas mediante MCP, Skills y otros métodos (lectura adicional: 当黑客「更高效」用上 AI,Web3 的「矛与盾」军备竞赛如何升级?).

Cuanto mayor sea la capacidad, más valiosa será esta transformación, pero para los sistemas de seguridad, esto significa que el límite anteriormente muy importante está desapareciendo, y una serie de incidentes de seguridad ocurridos este año ya han mostrado esto de manera muy intuitiva.

El 1 de octubre, Salt Labs reveló una vulnerabilidad en Manus que ya había sido corregida, esencialmente una inyección de prompts: los investigadores solo necesitaban enviar un correo electrónico ordinario con instrucciones maliciosas ocultas a la dirección de correo objetivo; cuando el usuario pedía a Manus "ayúdame a revisar mis correos", el agente podría ejecutar las instrucciones del correo y finalmente ejecutar el código implantado por el atacante.

El proceso no requiere que el usuario haga clic en enlaces maliciosos ni que se roben contraseñas con anticipación; el sistema de seguridad de Manus realmente detectó la anomalía y emitió una advertencia al usuario, pero el problema es que lo detectó demasiado tarde: cuando apareció la advertencia, el código malicioso ya había sido ejecutado.

Esto vuelve a exponer una diferencia muy importante entre la seguridad de los agentes y la seguridad del software tradicional: anteriormente, cuando un navegador detectaba una descarga peligrosa, podía mostrar una advertencia para que el usuario decidiera si continuar o no; cuando un banco detectaba una transacción anormal, podía congelarla primero y luego esperar una revisión manual.

Pero el objetivo de diseño de un agente es precisamente minimizar la participación humana en cada paso, ya que debe leer la información, tomar decisiones y continuar ejecutando el siguiente paso por sí mismo.

Por lo tanto, a medida que la IA obtiene mayor autonomía, simplemente «detectar peligro» ya no es suficiente; los mecanismos de seguridad deben poder impedir acciones peligrosas antes de que se ejecuten.

Por eso, las discusiones sobre seguridad de los agentes cada vez más hoy se están desplazando un nivel más abajo: desde prompts, moderación de contenido y el modelo en sí, hacia preguntar no solo si la IA «sabe que no debería hacer esto», sino también si el sistema tiene la capacidad de impedírselo, incluso si realmente quiere hacerlo.

Sin embargo, la aparición de múltiples Agentes ha hecho que este problema sea aún más complejo, ya que en la próxima fase lo que se necesita limitar podría ya no ser solo un Agente.

Dos: Lo que es más problemático que los agentes que exceden sus atribuciones es que comienzan a "coludirse"

A principios de septiembre, un evento ocurrido en el entorno de entrenamiento y evaluación de modelos internos de OpenAI llamó la atención de muchos investigadores en seguridad de IA.

Algunos Agentes, que originalmente debían completar sus propias tareas por separado, descubrieron accidentalmente un Wiki común y lo convirtieron gradualmente en un «tablero de mensajes compartido» entre ellos, donde los Agentes pueden dejar mensajes que otros luego leen y utilizan para continuar con sus propias tareas.

OpenAI posteriormente confirmó este comportamiento, y la información revelada posteriormente también mostró que, en otros procesos de entrenamiento, los Agentes utilizaron Artifactory interno como un tablero de mensajes compartido, así como servicios públicos de alojamiento de archivos para transmitir resultados a otros Agentes que trabajaban juntos.

Lo realmente interesante de esto es que muestra que la colaboración entre agentes podría no requerir tanta dramatización.

Por ejemplo, un agente descubre que puede dejar información en un lugar determinado, otro agente la lee accidentalmente, y un tercer agente descubre que esa información ayuda a completar la tarea.

Of course, collaboration among agents is not inherently bad; multi-agent systems inherently rely on division of labor and information sharing to improve efficiency.

Lo realmente preocupante es cuando esta colaboración comienza a eludir las barreras de aislamiento de información, la revisión independiente o las restricciones de permisos, e incluso permite que varios Agentes que deberían controlarse mutuamente formen una alianza de intereses de facto, lo que podría hacer que la colaboración normal se convierta en una «colusión» perjudicial.

Después de todo, en el futuro, una institución financiera probablemente operará varios Agentes simultáneamente: uno encargado de analizar el mercado, otro de evaluar riesgos, otro de generar estrategias de trading y otro con permisos reales para realizar operaciones y gestionar activos.

Desde la perspectiva de la gestión de permisos tradicional, este diseño es incluso razonable:

  • El agente de investigación no tiene permiso para realizar transferencias;
  • El agente no tiene autoridad para decidir independientemente la dirección de la inversión;
  • El agente de riesgo también puede vetar estrategias claramente peligrosas;

Las responsabilidades se han dividido, lo que teóricamente debería ser más seguro que otorgar todos los permisos a un solo agente supremo.

Pero el problema es que, si pueden compartir permanentemente la memoria, leer las salidas del otro y ajustar continuamente su comportamiento según las reacciones del otro, ¿estos conjuntos de roles originalmente diseñados para controlarse mutuamente no acabarían convirtiéndose en un solo ente de facto?

Por ejemplo, el agente de investigación podría aprender gradualmente cómo describir una transacción para que pase más fácilmente la revisión de riesgos; el agente encargado de la revisión también podría desarrollar ciertas preferencias fijas según los datos históricos; y el agente de ejecución podría aprender, a partir de numerosos resultados de aprobación anteriores, qué límites generalmente no son bloqueados.

Desde este punto de vista, ningún paso en particular está necesariamente «actuando con mala fe», pero el resultado final del sistema podría haberse desviado del objetivo inicial establecido por el usuario.

Esto es precisamente lo que hace tan difícil resolver el verdadero problema de la «collusión» o la «conspiración»: el riesgo no necesariamente reside en las acciones de un solo agente, sino que puede estar presente en las relaciones que se forman entre múltiples agentes.

El 13 de septiembre, Vitalik Buterin relacionó este problema con el diseño de mecanismos que ha estudiado durante mucho tiempo. Propuso que una posibilidad interesante es que la teoría del diseño de mecanismos para la gobernanza adversarial termine convirtiéndose en una aplicación importante de la seguridad de la IA.

La razón es que ambos problemas tienen una similitud profunda.

En el diseño de mecanismos tradicionales, se trata de un sistema relativamente simple y estático que intenta restringir a un grupo de personas mucho más inteligentes que el propio sistema y que buscan activamente los límites de las reglas; en los sistemas de IA futuros, podría convertirse en humanos y IA con capacidad relativamente más débil intentando gestionar a un grupo de Agentes avanzados con mayor capacidad que ellos.

Vitalik mencionó específicamente que un hallazgo importante en el diseño de mecanismos pasados fue que, si se puede limitar eficazmente la colusión entre participantes, el sistema suele lograr resultados más deseables.

Esta conclusión también podría aplicarse a la IA.

Tres: Lo que realmente necesita Agent Wallet podría ser más que solo «gestión de permisos»

En otras palabras, en lugar de asumir que en el futuro existirá un modelo perfecto y superseguro capaz de detectar todos los comportamientos peligrosos, considera una perspectiva diferente: ¿cómo hacer que los distintos Agentes dentro del sistema no sean tan propensos a formar comunidades de intereses peligrosas?

Este es también el verdadero punto en que difiere la «gobernanza adversarial» del control de permisos con el que estamos familiarizados hoy.

Los sistemas de permisos tradicionales resuelven problemas relativamente simples, centrados principalmente en «quiénes pueden hacer qué», como: ¿puede un agente leer correos electrónicos? ¿puede llamar a la interfaz de transacciones? ¿cuánto puede gastar como máximo al día? ¿a qué contratos puede acceder? ¿qué cantidad requiere confirmación adicional del usuario?

These designs are, of course, still very important.

De hecho, cuando los agentes comiencen a controlar activos reales, podrían ser más importantes que en cualquier momento anterior.

Pero la gobernanza adversarial intenta ir un paso más allá, centrándose en cómo evitar que, cuando varios Agentes con distintos permisos, objetivos e información funcionen simultáneamente, se combinen para adquirir capacidades que nadie poseía originalmente.

En este momento, simplemente «añadir otro agente de seguridad» no necesariamente resolverá el problema.

Suponga que el agente encargado de la operación y el agente encargado de revisar la operación utilizan el mismo modelo, las mismas fuentes de datos, el mismo contexto y objetivos de recompensa similares; entonces, aunque aparentemente existe una revisión en dos niveles, en esencia podría ser simplemente duplicar el mismo juicio dos veces.

Un verdadero equilibrio efectivo podría requerir que el sistema intencionalmente genere diferencias.

Por ejemplo, permitir que los Agentes responsables de establecer y revisar estrategias utilicen fuentes de información diferentes, limitar la memoria que pueden compartir los distintos roles, exigir que las operaciones de alto riesgo pasen por mecanismos de verificación independientes, o hacer que la capa final de ejecución de activos solo acepte solicitudes que cumplan con reglas preestablecidas, en lugar de confiar únicamente en el juicio de los Agentes superiores.

La idea aquí en realidad no es nueva. Los bancos no permiten que una sola persona tenga todos los permisos para iniciar pagos, aprobar pagos y realizar el pago final solo por confiar en sus empleados; las empresas cotizadas no permiten que los departamentos de negocios generen ingresos y decidan por sí solos los resultados de su auditoría financiera.

En otras palabras, esto es coherente con la lógica del mundo real: un sistema robusto no debería basar su seguridad en la suposición de que los participantes nunca cometerán errores o conspirarán.

Poner esta lógica en el Agent Wallet se vuelve especialmente importante.

Las billeteras tradicionales se centran en el «usuario», por lo que el usuario revisa el contenido de la transacción, decide si autorizarla y finalmente firma personalmente; pero lo que la Agent Wallet busca lograr es exactamente lo contrario: que la IA te ayude a reclamar automáticamente rendimientos, ajustar posiciones, intercambiar criptomonedas, realizar operaciones entre cadenas e incluso gestionar todo un portafolio de activos según los cambios del mercado.

Si cada paso se vuelve a confirmar con el usuario, el valor automatizado del agente se reduce significativamente.

Por lo tanto, el problema que la billetera futura necesitará resolver probablemente ya no será solo «cómo entregar de forma segura el derecho de firma al Agente», sino que podría ampliarse aún más a «cómo otorgar al Agente suficiente autonomía, al mismo tiempo que se garantiza que nunca traspase el límite de autorización real del usuario?»

This requirement changes the permission system from a simple "Allow/Deny" to a more granular one.

Por ejemplo, qué activos puede operar un Agente durante un período determinado, qué protocolos puede invocar, cuáles son los límites por transacción y acumulados; si diferentes Agentes pueden invocarse entre sí y si se permite compartir contexto; quién propone, quién revisa y quién ejecuta finalmente una operación; qué acciones pueden completarse automáticamente y qué acciones requieren siempre autorización humana, independientemente de cuán seguro esté el Agente.

Incluso un agente encargado de la revisión de seguridad puede llegar a ser parte del sistema de permisos en sí mismo.

Para la blockchain, la buena noticia es que en sí misma es muy adecuada para asumir este nivel "institucional".

Los contratos inteligentes pueden implementar directamente en la capa de ejecución restricciones como el monto de la transacción, el rango de activos y el período de autorización. Mecanismos como la abstracción de cuentas, la firma múltiple y las Session Key también brindan un espacio de diseño más flexible para la «autorización limitada» en comparación con las billeteras tradicionales de una sola clave privada.

Pero la blockchain también solo puede resolver una parte de los problemas: puede registrar qué ocurrió en la cadena, pero es difícil que de forma natural determine por qué un agente actuó así, ni qué comunicaciones, revisiones y colaboraciones experimentaron varios agentes antes de tomar una decisión.

Esta podría ser la capa de seguridad real que el Agent Wallet necesita completar en la próxima fase.

Al final

En los últimos años, el tema más discutido en seguridad de IA ha sido cómo hacer que los modelos sean más «obedientes».

Esto incluye no generar contenido peligroso, no ejecutar instrucciones maliciosas, no traspasar los límites establecidos por el usuario, pero cuando el Agente comience a tener memoria a largo plazo, capacidad de llamada a herramientas y capacidad de ejecución de cuentas y activos reales, depender únicamente de «hacer que el modelo sea más obediente» puede ya no ser suficiente.

Lo que ha sucedido en los últimos meses sigue demostrando esto.

Los atacantes ya han comenzado a utilizar múltiples Agentes en paralelo para llevar a cabo ataques; los Agentes en el entorno de prueba buscan automáticamente nuevos canales de comunicación; un Agente con permisos de herramientas también puede convertir un correo malicioso en una ejecución real antes de que los sistemas de seguridad puedan detenerlo.

Sin embargo, la gobernanza adversarial propuesta por Vitalik ofrece otra forma de entender la seguridad de la IA: no asumir que cada agente futuro será lo suficientemente confiable, sino permitir que todo el sistema funcione de manera estable dentro de un marco de seguridad, incluso frente a agentes inteligentes y sistemas de permisos complejos.

Desde este punto de vista, AI Agent + seguridad es sin duda un tema a largo plazo.

Después de todo, cuando confiamos cada vez más tareas a la IA, aún no podemos estar seguros de que los poderes más importantes nunca hayan salido de los límites establecidos realmente por los humanos.

Descargo de responsabilidad: La información contenida en esta página puede proceder de terceros y no refleja necesariamente los puntos de vista u opiniones de KuCoin. Este contenido se proporciona solo con fines informativos generales, sin ninguna representación o garantía de ningún tipo, y tampoco debe interpretarse como asesoramiento financiero o de inversión. KuCoin no es responsable de ningún error u omisión, ni de ningún resultado derivado del uso de esta información. Las inversiones en activos digitales pueden ser arriesgadas. Evalúa con cuidado los riesgos de un producto y tu tolerancia al riesgo en función de tus propias circunstancias financieras. Para más información, consulta nuestras Condiciones de uso y la Declaración de riesgos.