Compañero Web3: La Billetera Agéntica de Código Abierto y Segura

GitHub: blocksecteam/web3-companion

Docker: blocksecteam/web3-companion

Permitir que la IA ejecute transacciones en cadena para los usuarios es la tendencia más candente en el mundo de las criptomonedas ahora mismo. Coinbase lanzó Agentic Wallets en febrero de 2026, y McKinsey estima que el comercio mediado por Agentes de IA podría alcanzar entre 3 y 5 billones de dólares a nivel global para 2030. Como señaló el CEO de Coinbase, Brian Armstrong, al respecto: los Agentes de IA no pueden abrir cuentas bancarias, pero sí pueden tener una billetera de criptomonedas.

El problema es que permitir que la IA opere activos en cadena no se parece en nada a dejarla gestionar calendarios o correos electrónicos. Las transacciones en cadena son irreversibles. Sin reembolsos, sin contracargos. Una sola firma maliciosa puede vaciar una billetera completa en un solo bloque. Sin seguridad, ninguna función importa.

BlockSec ha publicado como código abierto Web3 Companion, una Billetera Agéntica con enfoque prioritario en la seguridad. Este artículo recorre el diseño de seguridad detrás de él: por qué las arquitecturas actuales de Billeteras Agénticas están fundamentalmente rotas y cómo integramos la seguridad en la arquitectura de la billetera desde cero.

Qué tan peligrosos son los Agentes actuales: el incidente de OpenClaw

¿Qué ocurre cuando un Agente de IA no tiene límites de seguridad? OpenClaw a principios de 2026 responde esa pregunta.

OpenClaw es un Agente de IA de propósito general y código abierto que acumuló 100.000 estrellas en GitHub en cinco días. Funcionaba bien como Agente de propósito general, pero en el momento en que tocó transacciones Web3, todas las brechas de seguridad quedaron al descubierto.

Las claves privadas estaban en texto plano en archivos locales que el Agente podía leer. Un solo correo electrónico con inyección de prompt fue suficiente para obtenerlas.

La firma no tenía aislamiento. El mismo proceso que obtenía páginas web no confiables también podía firmar transacciones, por lo que una sola vulnerabilidad RCE permitió a un atacante tomar control total tanto del Agente como de sus claves a través de una página web maliciosa.

El mercado de Skills era otro punto débil. Los investigadores encontraron que el 7,1 % de los Skills de ClawHub filtraban credenciales, y algunos estaban diseñados directamente para vaciar billeteras de criptomonedas.

La generación de números aleatorios también estaba rota. OpenClaw usaba math/rand, un PRNG inicializado por el reloj del sistema, en rutas de código críticas para la seguridad. Los investigadores demostraron que dos valores de token consecutivos eran suficientes para reconstruir el estado interno y predecir cada token y valor de desafío futuros. En algunas rutas de código, esto se extendía hasta la recuperación de claves de billetera.

Lo peor de todo era que no había capa de políticas. Nada se interponía entre una inyección de prompt y una transferencia de fondos. Cero interceptación.

La conclusión: las arquitecturas de Agentes de IA de propósito general no son seguras para transacciones Web3.

El fallo fundamental en las arquitecturas actuales de Agentes de IA

Esto va más allá de OpenClaw. Cambiar de modelo o escribir prompts más estrictos no soluciona el problema. Las arquitecturas actuales de Agentes de IA tienen un fallo de seguridad inherente: el propio LLM es una superficie de ataque permanentemente expuesta.

La causa raíz: los LLMs no pueden distinguir instrucciones de datos. Los prompts del sistema, los mensajes del usuario, el contenido de páginas web e incluso el nombre de un token llegan como el mismo flujo de tokens. El modelo no tiene un mecanismo fiable para separar "ejecuta esto" de "solo lee esto". De aquí se derivan tres consecuencias.

En primer lugar, la inyección de prompt es irresoluble a nivel del modelo. Los atacantes pueden ocultar instrucciones en cualquier cosa que el Agente ingiera: correos electrónicos, comentarios de contratos, páginas web, nombres de tokens. Si el Agente puede firmar transacciones, una sola inyección exitosa convierte una broma en un robo.

En segundo lugar, la revisión de seguridad basada en Skills del propio Agente puede ser subvertida. Un LLM que juzga la seguridad de una transacción depende enteramente del contexto. Envenena el contexto y el veredicto cambia. Las firmas maliciosas pasan sin problemas.

En tercer lugar, los Agentes funcionan las 24 horas del día, consumiendo continuamente entradas no confiables y siendo capaces de ejecutar transacciones de forma autónoma. La ventana de ataque nunca se cierra, y una sola brecha puede suponer una pérdida inmediata de fondos.

La comunidad de seguridad está ampliamente de acuerdo: dar a un LLM acceso directo a claves privadas, en un mundo donde la inyección de prompt no tiene cura, equivale a dejar los activos del usuario dentro de un componente que puede ser comprometido en cualquier momento. Dado que la capa del modelo no puede ser reforzada, el riesgo debe contenerse a nivel de arquitectura. Incluso un modelo completamente comprometido no debería poder mover los fondos del usuario.

La arquitectura de seguridad de Web3 Companion está construida exactamente sobre esta idea.

Modelo de amenazas: el Agente no es de confianza

El modelo de amenazas de Web3 Companion cabe en una sola frase: el propio Agente no es de confianza. Toda la arquitectura asume que el Agente puede ser comprometido en cualquier momento.

No confiamos en hacer al Agente lo suficientemente robusto como para detectar cada ataque. La defensa a nivel de modelo no funciona, como se mostró anteriormente. Entrénalo hoy para detectar inyecciones en código Morse; mañana los atacantes cambian a Base64, texto esteganográfico en imágenes o un PDF de apariencia inocente. En cambio, invertimos el supuesto. El Agente se encuentra dentro del modelo de amenazas, y el resto del sistema está diseñado para contenerlo. Aunque un atacante controle completamente el Agente, los activos del usuario permanecen seguros. Posicionamiento en una línea: The Secure Agentic Wallet, una billetera que trata a su propio Agente como no confiable por defecto y permanece segura independientemente de todo.

A partir de este modelo de amenazas derivamos cinco principios de diseño.

Principio 1: el Agente nunca debe tocar las claves privadas. Las claves privadas son la única credencial que controla los activos en cadena. Si el Agente puede leerlas, un compromiso significa claves perdidas. Las claves deben residir donde el Agente arquitectónicamente no pueda alcanzarlas.

Principio 2: preparar no es autorizar. Construir una transacción y aprobarla son dos actos separados. El Agente puede ayudar a los usuarios a comprender el estado en cadena y ensamblar intenciones, pero la decisión de firmar pertenece a un módulo de backend independiente al que el Agente no puede acceder.

Principio 3: la revisión es detección, no aplicación. La simulación de transacciones, el análisis de calldata y el etiquetado de direcciones detectan patrones de ataque comunes y ayudan a los usuarios a comprender el riesgo, pero no son el veredicto final. Las simulaciones pueden fallar, las etiquetas pueden faltar, y el propio análisis del LLM es en sí mismo vulnerable a la inyección de prompt.

Principio 4: las políticas duras son el último recurso. Supongamos que se engaña a un Agente para que inicie una transferencia de 100.000 dólares y la revisión de seguridad es manipulada para aprobarla. Un límite diario de 1.000 dólares impuesto por código aún la bloquea. El Agente no tiene permiso para cambiar estos límites.

Principio 5: sin evidencia, no hay ejecución. Un escaneo fallido no equivale a un pase. La falta de datos no es "seguro". Cuando la evidencia de seguridad está ausente, es contradictoria, está desactualizada o es insuficiente, el sistema se detiene y espera la confirmación explícita del usuario.

Estos cinco principios se implementan a través de dos módulos de seguridad: seguridad de claves privadas y seguridad de transacciones.

Aislamiento de claves privadas: arquitectónicamente inalcanzable por el Agente

El primer problema es simple. Queremos un asistente que prepare transacciones en cadena, pero darle capacidad de firma le entrega el poder de mover dinero real. Casi todas las brechas de Agentes Web3 en 2025 y 2026 siguieron el mismo patrón: las claves privadas vivían dentro del proceso del Agente y los atacantes encontraron la forma de extraerlas.

Así que reformulamos la pregunta: ¿y si el Agente literalmente no puede firmar? No "se le indica que no lo haga", sino que arquitectónicamente no puede. Los controles de acceso a nivel de software siempre pueden ser eludidos. Necesitábamos algo más robusto.

Web3 Companion aplica aislamiento a nivel de proceso. Solo un componente toca las claves privadas: el Módulo de Firma Segura (SSM), un proceso Go independiente. La memoria del proceso del Agente, las variables de entorno y el sistema de archivos no contienen ningún material de claves. Lo único que el Agente ve es un ID de intención de transacción. Puede pedirle al SSM que firme esa intención, pero nunca puede ver la clave detrás de ella.

Para el almacenamiento de claves, evaluamos tres opciones. Texto plano en disco: una lectura de disco expone la clave inmediatamente. Rechazado. Cifrado derivado de contraseña: requiere nueva introducción en cada reinicio, poco práctico para un servicio Docker de larga duración. Rechazado. Optamos por el cifrado en sobre: cada clave de billetera se cifra con su propia clave de datos, y esa clave de datos está envuelta por una clave maestra (AWS KMS o AES-256 local). Incluso si los archivos cifrados son exfiltrados en su totalidad, son inútiles sin la clave maestra. Las claves solo existen en texto plano momentáneamente en la memoria del SSM y se ponen a cero justo después de la firma.

Cada solicitud de firma recorre el mismo camino. Sin atajos ni vías rápidas. Una transacción pasa por siete pasos en orden: verificación de delegación, simulación, revisión de seguridad, revisión de seguridad del Agente, evaluación de políticas, aprobación con Passkey y, finalmente, firma por el SSM. Completar un paso nunca omite el siguiente.

Un detalle de bajo nivel que vale la pena mencionar: cada byte aleatorio en el sistema (generación de claves privadas, nonces AES-GCM, tokens de autenticación, desafíos WebAuthn) proviene de crypto/rand, la fuente de aleatoriedad criptográfica del sistema operativo. El uso de math/rand está prohibido en todo código crítico para la seguridad, lo cual se hace cumplir mediante pruebas y CI.

Seguridad de transacciones: cuatro capas de defensa en profundidad

El aislamiento de claves privadas cubre la seguridad de las claves, pero los riesgos a nivel de transacción persisten. Un Agente comprometido puede ensamblar una intención de transacción de apariencia perfectamente legítima para engañar a los usuarios o manipular las políticas de firma automática. La inyección de prompt no necesita la clave privada; solo necesita conseguir que el sistema firme una transacción maliciosa a través del flujo normal.

La pregunta central: cuando el Agente que prepara las transacciones puede estar comprometido, ¿cómo se detecta una transacción maliciosa?

Ninguna capa de defensa individual se sostiene por sí sola. ¿Solo simulación? Las simulaciones fallan, los RPCs se caen y los nuevos ataques quedan fuera de los patrones conocidos. ¿Solo revisión basada en LLM? La misma inyección que comprometió al Agente compromete al revisor, ya que ambos ejecutan LLMs. ¿Solo un límite duro fijo? Los usuarios legítimos se topan con una pared; un tope de 100 dólares en cada swap es inutilizable.

Combinamos las cuatro capas. Cada capa asume que todas las anteriores ya han caído.

Capa 1: Simulación de transacciones. Antes de firmar, el sistema simula la ejecución: decodificación de calldata, predicción de reversiones, verificación del formato de los campos. La simulación detecta problemas evidentes pero tiene puntos ciegos. Las nuevas técnicas de ataque y las interrupciones de RPC pueden eludirla.

Capa 2: Evaluación de la contraparte. Una batería de comprobaciones estáticas apunta a la contraparte: coincidencia de destinatario/monto, detección de aprobaciones ilimitadas, detección de direcciones quemadas, detección de llamadas delegadas inesperadas. La puntuación de riesgo de direcciones se ejecuta a través del servicio de cumplimiento x402 de BlockSec, donde el Agente consulta etiquetas y puntuaciones de riesgo mediante micropagos x402 sin necesidad de clave de API ni suscripción. Las capas 1 y 2 juntas detectan la mayoría de los problemas comunes, pero ambas pueden ser eludidas. Su función está deliberadamente limitada a la detección y explicación, no a las decisiones finales.

Capa 3: Aplicación de políticas duras. Aplicación pura mediante código en Go. El LLM no está involucrado y el Agente no puede modificar las reglas. Límites por transacción, presupuestos diarios, listas blancas de destinatarios, umbrales de firma automática: una transferencia de 5.000 dólares contra un límite de 100 dólares por transacción se rechaza en el acto. Cambiar la política en sí requiere Passkey. ¿Por qué? Si el Agente pudiera editar las políticas, una sola inyección primero subiría el límite y luego vaciaría la billetera. La firma automática está desactivada por defecto; cada transacción requiere aprobación manual hasta que el usuario opte explícitamente por activarla.

Esto significa que incluso si todas las capas de detección son eludidas y un Agente completamente comprometido firma una transacción maliciosa, la pérdida real está limitada por la política. Si el usuario establece el umbral diario de firma automática en 500 dólares, la pérdida máxima es de 500 dólares, no toda la billetera. La capa de políticas convierte un compromiso de un evento catastrófico en una pérdida acotada.

Capa 4: Confirmación del usuario (Passkey). Cuando la política exige aprobación manual, el sistema requiere verificación WebAuthn (huella dactilar o reconocimiento facial). Ningún exploit puramente por software puede falsificar esto.

Las cuatro capas operan bajo desconfianza mutua. Cada una asume que todo lo anterior ya ha fallado. Una simulación perfecta no relaja la política. Una política mal configurada no omite la Passkey. Cada capa se sostiene por sí sola.

Un detalle fácil de pasar por alto: la reutilización de veredictos. Una técnica de ataque DeFi conocida reproduce un veredicto de seguridad antiguo contra una transacción modificada. Web3 Companion vincula cada operación de escritura a una intención de transacción única con transiciones de estado auditables. Un veredicto de seguridad se aplica solo a la intención exacta que revisó. Si el Agente reconstruye una transacción, aunque solo cambie el monto o el destinatario, el sistema la trata como una intención completamente nueva y vuelve a ejecutar todas las comprobaciones.

Las cuatro capas de defensa se mapean en tres límites de confianza independientes: Clave Privada, Política y Passkey. Una sola brecha en cualquier límite deja los otros dos en pie:

Seguridad por diseño: la filosofía detrás del código abierto

BlockSec ha trabajado en seguridad en cadena desde el primer día. Hemos protegido miles de millones de dólares en activos en cadena y hemos visto repetirse la misma lección: la seguridad que no está integrada en la arquitectura desde el principio siempre llega demasiado tarde.

Los Agentes de IA se están convirtiendo en una nueva puerta de entrada a las transacciones en cadena. El espacio avanza rápido, pero los estándares de seguridad apenas existen. La mayoría de los equipos se centra en lo que su Agente puede hacer. Pocos se han preguntado seriamente: si este Agente es comprometido, ¿puede la arquitectura limitar el radio de explosión?

Web3 Companion es el esfuerzo de BlockSec por canalizar años de trabajo en seguridad en cadena hacia una arquitectura de Billetera Agéntica. El código es completamente abierto bajo la licencia MIT (actualmente etiquetado como vista previa de investigación). El sector necesita ahora un punto de referencia concreto en diseño de seguridad. Cómo estructurar modelos de amenazas, cómo aislar claves, hasta dónde llevar la defensa de transacciones: ningún equipo debería tener que reinventar todo esto desde cero. Publicamos el diseño completo para que la comunidad pueda construir sobre él.