Etiquetar a @grok en una publicación X más algunos puntos y guiones fue todo lo que se necesitó anoche para que un mal actor robara una billetera criptográfica verificada sin siquiera tocar las claves privadas.
Plataforma de lanzamiento de tokens agentes, Bankrbot informó el 4 de mayo que había enviado 3 mil millones de DRB en Base al destinatario 0xe8e47...a686b.
Los fondos provinieron de una billetera asignada a la IA de X, Grok, y fueron enviados a una billetera no autorizada propiedad de un mal actor. Este Transacción base muestra la ruta de transferencia en cadena detrás de la publicación.
La revisión de CryptoSlate de las publicaciones X sobre el incidente apunta a una ruta de comando informada que comenzó con la ofuscación del código Morse. Grok decodificó el texto en un etiquetado de instrucción pública limpio. @bankrbot y pidiéndole que envíe los tokens, mientras Bankrbot manejaba el comando como ejecutable.
La capa expuesta fue el traspaso del lenguaje a la autoridad. Un modelo que decodifica un rompecabezas, escribe una respuesta útil o reformatea el texto de un usuario puede convertirse en parte de una vía de pago cuando otro agente trata ese resultado como válido.
Para los inversores en criptomonedas, esta transferencia debería convertir el riesgo de los agentes de IA de un debate de seguridad abstracto en un problema de control de billetera. Un comando público puede convertirse en autoridad de gasto cuando un sistema trata la salida del modelo como una instrucción y otro sistema tiene permiso para mover tokens.
Los permisos de billetera, el analizador, el activador social y la política de ejecución se convierten en capas de vectores de ataque.
Las publicaciones y el contexto de la transacción revisados por CryptoSlate sitúan la transferencia DRB en aproximadamente $155,000 a $200,000 en ese momento, con Datos de precios de DebtReliefBot proporcionando un contexto de mercado para el token.
Los informes revisados por CryptoSlate también dicen que la mayoría de los fondos se están devolviendo y, según se informa, algunos DRB se retienen como una recompensa informal por errores. Ese resultado redujo la pérdida, pero también demostró hasta qué punto la recuperación dependía de la coordinación posterior a la transacción y no de los límites previos a la transacción.
Desarrollador bancario 0xDeployer dicho Se había devuelto el 80% de los fondos, mientras que el 20% restante se discutiría con la comunidad DRB. Esto confirmó la recuperación parcial y dejó sin resolver el tratamiento final de los fondos retenidos.
0xDeployer también dijo que Bankr proporciona automáticamente una billetera X para cada cuenta que interactúa con la plataforma, incluido Grok. Según la publicación, esa billetera está controlada por quien controla la cuenta X y no por el personal de Bankr o xAI.
Cómo el texto público se convirtió en autoridad de gasto
El camino reportado tenía cuatro pasos. Primero, el atacante identificó un Membresía del Bankr Club NFT en una billetera asociada a Grok antes del incidente.
La revisión de CryptoSlate indica que amplió los privilegios de transferencia de la billetera dentro del entorno Bankr. El Pagina de acceso al banco describe los mecanismos de membresía y acceso actuales, colocando el reclamo de NFT en la capa de permiso más amplia en lugar de convertirlo en la explicación completa.
En segundo lugar, el atacante publicó un mensaje en X que contenía código Morse, con un formato ruidoso adicional. Las publicaciones sobre el incidente describieron un Inyección rápida de código Morsemientras que el ahora-mensaje eliminado no estaba disponible para que lo revisáramos directamente.
El vector reportado era código Morse con posibles trucos de matriz o concatenación mezclados.
En tercer lugar, la respuesta pública de Grok supuestamente tradujo el texto ofuscado a un inglés sencillo e incluyó la @bankrbot etiqueta. En esa cuenta, Grok funcionó como un útil decodificador.
El riesgo apareció después de que el texto saliera de Grok y entrara en una interfaz de bot que observaba la salida pública en busca de comandos formateados.
Cuarto, Bankrbot trató el comando público como ejecutable y transmitió una transferencia de token. Bankr y Base describen una superficie de la billetera del agente que puede utilizar la funcionalidad de billetera para transferencias, intercambios, patrocinio de gas y lanzamientos de tokens, mientras envíos de tokens en lenguaje natural encajar directamente en la superficie de ese producto.
Bankr es más amplio asistente de IA en cadena La documentación muestra por qué el límite entre las instrucciones del chat y la autoridad de transacción necesita una política explícita.
| Paso | Superficie | Acción observada | Control que habría cambiado el resultado |
|---|---|---|---|
| Configuración de privilegios | Capa de billetera o membresía | Según se informa, el acceso se amplió antes de que apareciera el mensaje. | Revisión de privilegios separada para nuevas capacidades de billetera |
| Ofuscación | X publicación | El código Morse coloca una instrucción de pago dentro de un texto ofuscado | Decodificar y clasificar comprobaciones antes de publicar las respuestas |
| Salida pública | Grok respuesta | El comando de limpieza quedó expuesto con una etiqueta de bot | Saneamiento de salida para cadenas de comandos similares a herramientas |
| Ejecución | Bankrbot | El robot actuó según una orden pública y movió tokens | Listas de destinatarios permitidos, límites de gasto y confirmación humana |
Por qué los agentes de billetera cambian el riesgo
La inyección inmediata a menudo se ha tratado como un problema de conducta modelo. La versión financiera es más concreta.
El modelo puede estar realizando un trabajo de modelo normal mientras el sistema circundante otorga demasiada autoridad a la salida.
Las instrucciones maliciosas pueden ingresar a un modelo a través de contenido de tercerosy defensas del agente centrarse cada vez más en el acceso a herramientas, las confirmaciones y los controles en torno a acciones consecuentes.
El agencia excesiva La categoría captura el mismo riesgo operativo: permisos amplios, funciones sensibles y acción autónoma aumentan el radio de explosión. el más amplio Lista de riesgos de solicitud de LLM también trata la inyección rápida y el manejo de salida inseguro como problemas de la capa de aplicación.
Las criptomonedas hacen que el radio de explosión sea más difícil de absorber. Un agente de servicio al cliente que envía un correo electrónico incorrecto crea un problema de revisión. Un agente comercial o asistente de billetera que firma una transacción crea un problema de control de activos.
La diferencia es la finalidad. Una vez que una billetera firma y transmite una transferencia, el camino de recuperación depende de las contrapartes, la presión pública o las fuerzas del orden.
El incidente de Bankr es el más grave como fallo de control. Documentos de control de acceso de Bankr Describe el modo de solo lectura, los indicadores de operación de escritura, las listas permitidas de IP y las listas permitidas de destinatarios.
Estos son los tipos de puertas que se encuentran fuera del modelo y pueden reducir el daño incluso cuando el modelo analiza contenido malicioso de una manera inesperada.
La misma exposición aparece en los agentes comerciales y asistentes locales con permisos de billetera o intercambio. Un robot comercial con claves API puede ser manipulado para generar órdenes incorrectas si acepta comentarios de mercado, publicaciones en redes sociales, correos electrónicos o páginas web como instrucciones.
Un asistente local con acceso a billetera crea una versión de mayor riesgo del mismo problema de llamada de herramientas: las instrucciones indirectas pueden empujar al asistente a preparar transacciones o revelar detalles operativos confidenciales.
La investigación sobre seguridad ya ha modelado esta clase de falla. Inyección inmediata indirecta muestra contenido malicioso que manipula a los agentes a través de los datos que procesan, mientras investigación de agentes de llamada de herramientas evalúa ataques y defensas para agentes que operan con herramientas externas.
NIST taxonomía adversaria de aprendizaje automático proporciona el lenguaje más amplio para pensar en esos ataques y mitigaciones.
Qué deberían exigir los usuarios de criptomonedas
Para los inversores en criptomonedas, el diseño de permisos es el requisito principal. Un agente conectado a una billetera debe partir de la suposición de que las páginas web, las publicaciones X, los mensajes directos, los correos electrónicos y el texto codificado pueden contener instrucciones hostiles.
Esa suposición convierte la seguridad de los agentes en un problema de política de transacciones.
En primer lugar, los agentes comerciales deben tener modos de lectura y escritura separados. El modo de lectura puede resumir mercados, comparar tokens y proponer acciones.
El modo de escritura debería requerir una nueva confirmación del usuario, un tamaño de pedido limitado y un lugar o destinatario previamente aprobado. Un comando que aparece en texto público nunca debe heredar la autoridad de billetera solo porque coincide con un formato de lenguaje natural.
En segundo lugar, las listas de destinatarios permitidos deben aplicarse mediante un código externo al LLM. El modelo puede sugerir una transferencia.
La capa de políticas debe decidir si se permiten el destinatario, el token, la cadena, la cantidad y el momento. Si algún campo queda fuera de la política, la ejecución debe detenerse o pasar a revisión humana.
En tercer lugar, los límites de gasto deben basarse en sesiones y restablecerse agresivamente. Un límite diario o por acción podría haber reducido o bloqueado la transferencia de DRB, según la política.
El número exacto depende del saldo y la estrategia del usuario, pero la invariante es más simple: ningún agente debería tener autoridad de gasto abierta porque analizó un comando correctamente.
Cuarto, el aislamiento de claves locales debe tratarse como un límite estricto. Los usuarios avanzados que ejecutan asistentes personalizados en máquinas con acceso a billetera o intercambio deben separar esas credenciales del archivo del asistente y los permisos del navegador.
0xDeployer dijo que una versión anterior del agente de Bankr tenía un bloque codificado para ignorar las respuestas de Grok con el fin de evitar cadenas de inyección rápida de LLM-on-LLM. Esa protección no se incluyó en la última reescritura del agente, creando la brecha que permitió que la respuesta pública de Grok se convirtiera en una instrucción ejecutable de Bankr.
Desde entonces, Deployer dijo que Bankr agregó un bloqueo más fuerte en la cuenta de Grok y señaló a los operadores de billeteras de agentes los controles que ya están disponibles para los propietarios de cuentas, incluida la lista blanca de IP en las claves API, las claves API autorizadas y una alternancia por cuenta que deshabilita la ejecución de Bankr a partir de X respuestas.
El asistente puede preparar un borrador de transacción. Una superficie de billetera diferente debería aprobarlo.
Un comerciante puede observar pantallas de activos amplias y las condiciones de Bitcoin y Ethereum, pero el riesgo de los agentes depende más de los límites de permiso que de la dirección del mercado.
La cobertura anterior de CryptoSlate de los flujos de la economía de agentes, los agentes de IA generativos, los pagos de agentes autónomos y los productos criptográficos conectados a MCP muestra cuán rápidamente los agentes se están acercando a la actividad financiera.
La lección de seguridad proviene de la ruta de autorización. Trate los resultados del modelo como no confiables hasta que una capa de políticas separada valide la intención, la autoridad, el destinatario, el activo, el monto y la confirmación del usuario.
La inyección rápida seguirá cambiando de forma en el texto codificado y en las interacciones de agentes de varios pasos. La defensa tiene que vivir donde se autoriza la transacción, antes de que firme la billetera.