Researchers urge crypto users to treat wallet AI agents as untrusted systems
AI

Los investigadores instan a los usuarios de criptomonedas a tratar a los agentes de IA de billetera como sistemas no confiables

Un documento enmendado del 20 de mayo describe tres controles a nivel de sistema, ya que Bankr deshabilitó transacciones después de que se accediera a más de 14 billeteras.

Por AI News Crypto Editorial Team5 min de lectura

Un documento de investigación enmendado del 20 de mayo argumenta que los agentes de IA conectados a billeteras deben ser tratados como componentes no confiables y asegurados a nivel del sistema, no solo a través del endurecimiento del modelo. La advertencia llega cuando el asistente de trading de criptomonedas Bankr deshabilitó transacciones el mismo día después de detectar a un atacante con acceso a al menos 14 billeteras.

Puntos Clave

  • Un documento de investigación enmendado publicado el 20 de mayo enmarca la seguridad de los agentes de IA como un problema de seguridad de sistemas y trata al agente mismo como un componente no confiable.
  • Los autores argumentan que muchos ataques pueden ser bloqueados separando instrucciones de datos no confiables, aplicando permisos de menor privilegio y controlando dónde se permite que fluya la información sensible.
  • El asistente de trading Bankr deshabilitó transacciones el 20 de mayo después de identificar a un atacante que había obtenido acceso a al menos 14 billeteras, aunque la ruta de explotación no ha sido confirmada.
  • El CEO de Circle, Jeremy Allaire, dijo en enero que miles de millones de agentes de IA podrían estar operando en nombre de los usuarios en cinco años.

Advertencia de Seguridad de Sistemas para Agentes de IA Conectados a Billeteras

Un documento de investigación enmendado publicado el 20 de mayo por investigadores de Google, Gray Swan, EmbraceTheRed y varias universidades argumenta que la seguridad de los agentes de IA debe ser tratada como la seguridad informática, no como un problema de 'robustez de IA' de nicho.

La afirmación central es contundente: se debe asumir que el agente es manipulable y, por lo tanto, debe ser tratado como un componente no confiable dentro de un sistema más grande.El marco del documento es importante para las criptomonedas porque los agentes conectados a billeteras colapsan la toma de decisiones y la ejecución en un solo flujo de trabajo. Si el agente se trata como confiable, entonces la inyección de comandos, el uso indebido de herramientas y la exfiltración de datos se convierten en eventos de riesgo para la billetera, no solo en 'malos resultados'. Los investigadores lo expresan directamente: 'A través de este lente, los esfuerzos para aumentar la robustez del modelo, el punto de vista dominante en la comunidad, son insuficientes por sí solos. En su lugar, debemos complementar los esfuerzos existentes con técnicas del dominio de la seguridad de sistemas.'Tres Controles que el Documento Dice Pueden Bloquear Muchos Ataques de Agentes

Los investigadores dicen que tres mecanismos a nivel de sistema podrían 'eliminar una gran fracción de ataques.' Para los constructores que envían asistentes de trading o bots de ejecución DeFi, estos se mapean claramente a los modos de falla que realmente drenan billeteras.

El primero es separar instrucciones de datos no confiables. En términos de agentes, este es el problema de la inyección de comandos: instrucciones maliciosas pueden estar ocultas dentro del contenido que el modelo lee, y luego ser tratadas como si fueran un comando legítimo.

El segundo es el menor privilegio. El agente solo debe tener los permisos mínimos necesarios para la tarea, en lugar de un acceso amplio a la billetera. Si un atacante dirige al agente, los permisos limitados reducen el radio de explosión.

El tercero es el flujo de datos sensibles controlado por el sistema. El sistema circundante, no el agente, debe decidir a dónde se permite que vayan los secretos y salidas sensibles, reduciendo la posibilidad de que el agente sea manipulado para enviar datos a destinos inseguros.

La línea a seguir es arquitectónica: 'mejores comandos' y el endurecimiento del modelo por sí solos no definen el límite de seguridad. El sistema lo hace.

El Cierre de Transacciones de Bankr Coloca el Riesgo del Agente en un Contexto Cripto

La advertencia del documento no es teórica en cripto. El 20 de mayo, el asistente de trading de criptomonedas impulsado por IA, Bankr, dijo que deshabilitó transacciones después de identificar a un atacante que había obtenido acceso a al menos 14 billeteras.

Lo que está confirmado es la respuesta y la cifra de alcance: las transacciones fueron deshabilitadas y se identificó el acceso a al menos 14 billeteras. Lo que no está confirmado es la causa raíz. Los expertos en seguridad especularon que el bot podría haber sido explotado por un hacker, pero el método de explotación y la atribución no se establecieron en los detalles disponibles.

Esa incertidumbre es el punto para los traders. Cuando la ejecución es automatizada, la diferencia entre 'mal comportamiento del agente' y 'compromiso de la billetera' puede ser un solo aviso de permiso.

Señales que los Traders Pueden Demandar Antes de Conceder Permisos de Billetera

La señal a corto plazo será si Bankr o investigadores de terceros publican detalles confirmados sobre cómo ocurrió el acceso a las 'al menos 14 billeteras'. Sin un informe de explotación, el mercado aprende la lección equivocada y repite la misma arquitectura.

Del lado del producto, los traders deben esperar que las herramientas de agentes se muevan hacia acciones limitadas en lugar de un acceso amplio a la billetera, especialmente para trading y ejecución DeFi. Sean Ren, cofundador de Sahara AI, describió los protocolos de contexto del modelo como un patrón de guardián: 'Esencialmente actúan como un guardián entre el modelo de IA y tu billetera. El agente solo puede realizar acciones específicas y aprobadas, como verificar saldos o preparar un pago para que lo confirmes, en lugar de mover fondos libremente o cambiar configuraciones de la billetera.'

Aaron Ratcliff, líder de atribuciones en Merkle Science, estableció un estándar más alto para los agentes capaces de ejecución: 'Quisiera pruebas de que la IA puede detectar el front-running, aplicar límites de deslizamiento, identificar tokens fraudulentos y auditar contratos en tiempo real antes de realizar un comercio. También debería poner en un entorno aislado los comandos, prevenir inyecciones y bloquear el acceso de hombre en el medio.'

Un vacío práctico más permanece: el documento enmendado se menciona sin un título completo, lista de autores o enlace canónico en el extracto disponible. Los constructores necesitarán esa pista de citación para implementar los controles de manera consistente.

Trata al Agente Como una Pestaña de Navegador Comprometida, No Como un Co-FirmanteNo veo esto como un titular de 'la IA es insegura'. Es un recordatorio de que la automatización conectada a billeteras es solo software con una nueva interfaz, y las viejas reglas aún ganan: asumir compromiso, minimizar privilegios y hacer cumplir límites fuera del componente que menos controlas.El umbral que importa es si los productos de agentes convergen en permisos limitados y controles de flujo de datos impuestos por el sistema como predeterminados, no como características premium. Si ese cambio ocurre mientras la adopción de agentes se acelera en la línea de tiempo de Allaire, la configuración comienza a parecer estructural en lugar de impulsada por la narrativa, y el impacto práctico es menos fallos de un solo punto donde un agente manipulado puede actuar como un co-firmante completo de la billetera.FuentesCointelegraph

[@portabletext/react] Unknown block type "span", specify a component for it in the `components.types` prop[@portabletext/react] Unknown block type "span", specify a component for it in the `components.types` prop[@portabletext/react] Unknown block type "span", specify a component for it in the `components.types` prop

[@portabletext/react] Unknown block type "span", specify a component for it in the `components.types` prop

[@portabletext/react] Unknown block type "span", specify a component for it in the `components.types` prop

[@portabletext/react] Unknown block type "span", specify a component for it in the `components.types` prop

[@portabletext/react] Unknown block type "span", specify a component for it in the `components.types` prop

  • [@portabletext/react] Unknown block type "span", specify a component for it in the `components.types` prop