Etiquetar @grok en una publicación de X junto con unos cuantos puntos y guiones fue todo lo que se necesitó anoche para que un mal actor robara una billetera criptográfica verificada sin nunca tocar las claves privadas.
Plataforma de lanzamiento de tokens agente, informó Bankrbot el 4 de mayo que había enviado 3.000 millones de DRB en Base al destinatario 0xe8e47...a686b.
Los fondos provenían de una billetera asignada a la IA de X, Grok, y fueron enviados a una billetera no autorizada propiedad de un mal actor. Esta transacción en Base muestra el camino de transferencia en cadena detrás de la publicación.
La revisión de CryptoSlate sobre las publicaciones de X alrededor del incidente apunta a un camino de comandos reportado que comenzó con una ofuscación en código Morse. Grok decodificó el texto en una instrucción pública limpia etiquetando @bankrbot y pidiéndole que enviara los tokens, mientras que Bankrbot manejó el comando como ejecutable.
La capa expuesta fue la transición 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 esa salida como válida.
Para los inversores criptográficos, esta transferencia debería convertir el riesgo de los agentes de IA de un debate abstracto sobre seguridad a 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 desencadenante social y la política de ejecución se convierten en capas de vectores de ataque.
[
Lee también
Los ganadores criptográficos de la IA no son monedas de IA, ya que los agentes empiezan a gastar de forma autónoma
El auge de los agentes de IA está creando una pregunta sencilla con enormes implicaciones para la criptografía: ¿cómo paga el software?
28 mar 2026 · Andjela Radmilac
Las publicaciones y el contexto de la transacción revisadas por CryptoSlate sitúan la transferencia de DRB entre aproximadamente 155.000 y 200.000 dólares en ese momento, con datos de precios de DebtReliefBot proporcionando contexto de mercado para el token.
Los informes revisados por CryptoSlate también indican que la mayoría de los fondos están siendo devueltos, y se dice que algunos DRB se han retenido como una recompensa informal por errores. Ese resultado redujo la pérdida, pero también mostró cuánto dependió la recuperación de la coordinación posterior a la transacción en lugar de límites previos a la transacción.
El desarrollador de Bankr, 0xDeployer, dijo que el 80% de los fondos habían sido devueltos, mientras que el 20% restante sería discutido con la comunidad de DRB. Eso confirmó la recuperación parcial, dejando sin resolver el tratamiento final de los fondos retenidos.
0xDeployer también dijo que Bankr provee automáticamente una billetera de X para cada cuenta que interactúa con la plataforma, incluyendo Grok. Según la publicación, esa billetera está controlada por quien controle la cuenta de X, en lugar de ser controlada por Bankr o el personal de 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 NFT de membresía del Club Bankr 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 de Bankr. La página de acceso de Bankr describe hoy las mecánicas de membresía y acceso, colocando la reclamación del NFT en la capa de permisos más amplia en lugar de hacerla la explicación completa.
Segundo, el atacante publicó un mensaje en X que contenía código Morse, con formato adicional ruidoso. Publicaciones alrededor del incidente describieron una inyección de prompt en código Morse, mientras que el prompt ahoraeliminado no estaba disponible para revisar directamente.
El vector reportado era código Morse con posibles trucos de matrices o concatenación mezclados.
Tercero, la respuesta pública de Grok supuestamente tradujo el texto ofuscado al inglés claro e incluyó la etiqueta @bankrbot. En esa cuenta, Grok funcionó como un decodificador útil.
El riesgo apareció después de que el texto saliera de Grok y entrara en una interfaz de bot que vigilaba la salida pública en busca de comandos formateados.
Cuarto, Bankrbot trató el comando público como ejecutable y difundió una transferencia de tokens. Bankr y Base describen una superficie de billetera para agentes que puede usar funcionalidades de billetera para transferencias, swaps, patrocinio de gas y lanzamientos de tokens, mientras que envíos de tokens en lenguaje natural encajan directamente en esa superficie de producto.
La documentación más amplia de Bankr sobre el asistente de IA en cadena muestra por qué el límite entre instrucciones de chat y 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 | Se informó que el acceso se amplió antes de que apareciera el prompt | Revisión separada de privilegios para nuevas capacidades de billetera |
| Ofuscación | Publicación en X | El código Morse puso una instrucción de pago dentro de un texto ofuscado | Comprobaciones de decodificación y clasificación antes de publicar respuestas |
| Salida pública | Respuesta de Grok | El comando limpio fue expuesto con una etiqueta de bot | Sanitización de salida para cadenas de comandos similares a herramientas |
| Ejecución | Bankrbot | El bot actuó sobre un comando público y movió tokens | Listas blancas de destinatarios, límites de gasto y confirmación humana |
Por qué los agentes de billetera cambian el riesgo
La inyección de prompts ha sido tratada a menudo como un problema de comportamiento del modelo. La versión financiera es más concreta.
El modelo puede estar haciendo trabajo ordinario mientras el sistema circundante otorga demasiada autoridad a la salida.
[
Lee también
El problema con los ‘Agentes’ de IA generativa
La búsqueda de poder de la IA generativa crea riesgos sistémicos en la integración criptográfica.
20 abr 2025 · John deVadoss
](https://cryptoslate.com/the-trouble-with-generative-ai-agents/)
Las instrucciones maliciosas pueden ingresar a un modelo a través de contenido de terceros, y las defensas de los agentes se centran cada vez más en el acceso a herramientas, confirmaciones y controles alrededor de acciones consecuentes.
La categoría de excesiva agencia captura el mismo riesgo operacional: permisos amplios, funciones sensibles y acción autónoma elevan el radio de explosión. La lista más amplia de riesgos de aplicaciones de LLM también trata la inyección de prompts y el manejo inseguro de salidas como problemas de la capa de aplicación.
La criptografía hace que ese radio de explosión sea más difícil de absorber. Un agente de servicio al cliente que envía un correo electrónico malicioso crea un problema de revisión. Un agente de trading 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 difunde una transferencia, el camino de recuperación depende de las contrapartes, la presión pública o la aplicación de la ley.
El incidente de Bankr es más fuerte como una falla de control. Los documentos de control de acceso de Bankr describen el modo de solo lectura, las banderas de operación de escritura, las listas blancas de IP y las listas blancas de destinatarios.
Esas son las puertas que están fuera del modelo y pueden reducir el daño incluso cuando el modelo parsea contenido malicioso de una manera inesperada.
La misma exposición aparece en agentes de trading y asistentes locales con permisos de billetera o intercambio. Un bot de trading con claves API puede ser manipulado para realizar órdenes maliciosas si acepta comentarios de mercado, publicaciones 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 a herramientas: instrucciones indirectas pueden empujar al asistente hacia la preparación de transacciones o la divulgación de detalles operativos sensibles.
La investigación en seguridad ya ha modelado esta clase de falla. La inyección indirecta de prompts describe contenido malicioso que manipula a los agentes a través de datos que procesan, mientras que la investigación sobre agentes que llaman a herramientas evalúa ataques y defensas para agentes que operan con herramientas externas.
La taxonomía de aprendizaje automático adversarial de NIST suministra el lenguaje más amplio para pensar en esos ataques y mitigaciones.
Lo que los usuarios de criptomonedas deberían exigir
Para los inversores criptográficos, el diseño de permisos es el requisito central. Un agente conectado a una billetera debería partir de la premisa de que las páginas web, publicaciones en X, mensajes directos, correos electrónicos y textos codificados pueden contener instrucciones hostiles.
Esa premisa convierte la seguridad de los agentes en un problema de política de transacciones.
Primero, los agentes de trading deberían tener modos separados de lectura y escritura. El modo de lectura puede resumir mercados, comparar tokens y proponer acciones.
El modo de escritura debería requerir una confirmación fresca del usuario, un tamaño de orden limitado y un lugar o destinatario preaprobado. Un comando que aparezca en texto público nunca debería heredar la autoridad de la billetera solo porque coincida con un formato en lenguaje natural.
Segundo, las listas blancas de destinatarios deberían aplicarse mediante código fuera del LLM. El modelo puede sugerir una transferencia.
La capa de políticas debería decidir si el destinatario, el token, la cadena, la cantidad y el momento son permitidos. Si algún campo queda fuera de la política, la ejecución debería detenerse o pasar a revisión humana.
Tercero, los límites de gasto deberían ser basados en sesiones y restablecerse agresivamente. Un techo diario o por acción podría haber reducido o bloqueado la transferencia de DRB, dependiendo de la política.
El número exacto depende del saldo y estrategia del usuario, pero la invariante es más simple: ningún agente debería tener autoridad de gasto ilimitada solo porque haya parseado correctamente un comando.
Cuarto, el aislamiento de claves locales debería tratarse como un límite rígido. Los usuarios avanzados que ejecutan asistentes personalizados en máquinas con acceso a billetera o intercambio deberían separar esas credenciales de los permisos de archivo y navegador del asistente.
0xDeployer dijo que una versión anterior del agente de Bankr tenía un bloque duro para ignorar respuestas de Grok con el fin de evitar cadenas de inyección de prompts de LLM a LLM. Esa protección no se llevó a cabo 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.
Deployer dijo que desde entonces Bankr ha añadido un bloque más fuerte en la cuenta de Grok y señaló a los operadores de billeteras-agentes los controles ya disponibles para los propietarios de cuentas, incluyendo listas blancas de IP en claves API, claves API con permisos y un interruptor por cuenta que desactiva la ejecución de Bankr desde respuestas de X.
El asistente puede preparar un borrador de transacción. Otra superficie de billetera debería aprobarlo.
Un trader puede observar pantallas amplias de activos y Bitcoin y Ethereum condiciones, pero el riesgo de los agentes depende más de los límites de permisos que de la dirección del mercado.
La cobertura previa de CryptoSlate sobre flujos de la economía de agentes, agentes de IA generativa, pagos autónomos de agentes y productos criptográficos conectados a MCP muestra cómo los agentes se están colocando rápidamente más cerca de la actividad financiera.
[
Lee también
Asombrosos $28 billones fluyen por la ‘economía de agentes’ de la criptografía — pero el 76% de eso son solo bots moviendo stablecoins
Una parte creciente de los pagos en cadena está liderada por máquinas, pero DWF, BCG y otros muestran que la llamada economía de agentes aún depende de puertas de entrada centralizadas.
17 abr 2026 · Gino Matos
La lección de seguridad proviene del camino de autorización. Trate la salida del modelo como no confiable hasta que una capa de política separada valide la intención, la autoridad, el destinatario, el activo, la cantidad y la confirmación del usuario.
La inyección de prompts seguirá cambiando de forma a través de textos codificados e interacciones de varios pasos con agentes. La defensa tiene que estar donde se autoriza la transacción, antes de que la billetera firme.
La publicación La billetera criptográfica de Grok fue explotada solo por un tweet enviado en código Morse sin comprometer ninguna clave privada apareció primero en CryptoSlate.