GitHub: blocksecteam/web3-companion
Docker: blocksecteam/web3-companion
Dejar que la IA ejecute transacciones on-chain para los usuarios es la tendencia más candente en el mundo cripto en este momento. Coinbase lanzó Agentic Wallets en febrero de 2026, y McKinsey estima que el comercio mediado por AI Agent podría alcanzar entre 3 y 5 billones de dólares a nivel mundial para 2030. Como lo expresó el CEO de Coinbase, Brian Armstrong: los AI Agent no pueden abrir cuentas bancarias, pero sí pueden poseer una billetera cripto.
El problema es que permitir que la IA opere activos on-chain no se parece en nada a dejarla gestionar calendarios o correos electrónicos. Las transacciones on-chain son irreversibles. Sin reembolsos, sin contracargos. Una sola firma maliciosa puede vaciar una billetera entera en un solo bloque. Sin seguridad, ninguna funcionalidad importa.
BlockSec ha publicado como código abierto Web3 Companion, una Agentic Wallet con seguridad como prioridad. Este artículo recorre el diseño de seguridad que lo sustenta: por qué las arquitecturas actuales de Agentic Wallet están fundamentalmente rotas y cómo construimos la seguridad desde los cimientos de la arquitectura.
Qué tan peligrosos son los Agent actuales: El incidente OpenClaw
¿Qué sucede cuando un AI Agent no tiene límites de seguridad? OpenClaw a principios de 2026 responde esa pregunta.
OpenClaw es un AI Agent de propósito general de código abierto que acumuló 100.000 estrellas en GitHub en cinco días. Funcionaba bien como Agent de propósito general, pero en cuanto tocó transacciones Web3, todas las brechas de seguridad quedaron expuestas.
Las claves privadas estaban en texto plano en archivos locales que el Agent podía leer. Un solo correo con prompt injection bastaba para robarlas.
La firma no tenía aislamiento. El mismo proceso que consultaba páginas web no confiables también podía firmar transacciones, de modo que una sola vulnerabilidad RCE permitía a un atacante tomar el control total tanto del Agent como de sus claves a través de una página web maliciosa.
El marketplace de Skills era otro punto débil. Los investigadores descubrieron que el 7,1% de los ClawHub Skills filtraban credenciales, y algunos estaban diseñados directamente para vaciar billeteras cripto.
La generación de números aleatorios también estaba rota. OpenClaw usaba math/rand, un PRNG con semilla basada en el reloj del sistema, en rutas críticas de seguridad. Los investigadores demostraron que dos valores de token consecutivos bastaban para reconstruir el estado interno y predecir todos los tokens y valores de desafío futuros. En algunas rutas del código, esto se extendía hasta la recuperación de claves de la billetera.
Lo peor de todo: no existía una capa de políticas. No había nada entre un prompt injection y una transferencia de fondos. Cero intercepción.
La conclusión: las arquitecturas de AI Agent de propósito general no son seguras para transacciones Web3.
El defecto fundamental de las arquitecturas actuales de AI Agent
Esto va más allá de OpenClaw. Cambiar de modelo o escribir prompts más estrictos no soluciona el problema. Las arquitecturas actuales de AI Agent cargan con un defecto de seguridad inherente: el propio LLM es una superficie de ataque permanentemente expuesta.
La causa raíz: los LLM no pueden distinguir instrucciones de datos. Los system prompts, los mensajes de usuario, el contenido de páginas web, 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”. Se derivan tres consecuencias.
Primero, el prompt injection es irresoluble en la capa del modelo. Los atacantes pueden ocultar instrucciones en cualquier cosa que el Agent consuma: correos electrónicos, comentarios en contratos, páginas web, nombres de tokens. Si el Agent puede firmar transacciones, una inyección exitosa convierte una broma en un robo.
Segundo, la propia revisión de seguridad basada en Skills del Agent puede ser subvertida. Un LLM que juzga la seguridad de una transacción depende completamente del contexto. Envenena el contexto y el veredicto se invierte. Las firmas maliciosas pasan la revisión sin problema.
Tercero, los Agent 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 significar la pérdida inmediata de fondos.
La comunidad de seguridad coincide ampliamente: dar a un LLM acceso directo a claves privadas, en un mundo donde el prompt injection no tiene cura, equivale a dejar los activos de los usuarios dentro de un componente que podría ser comprometido en cualquier momento. Dado que la capa del modelo no se puede endurecer, el riesgo debe contenerse en la capa de arquitectura. Incluso un modelo completamente comprometido no debería poder mover los fondos de los usuarios.
La arquitectura de seguridad de Web3 Companion está construida exactamente sobre esta idea.
Modelo de amenazas: El Agent no es de confianza
El modelo de amenazas de Web3 Companion se resume en una frase: el propio Agent no es de confianza. Toda la arquitectura asume que el Agent puede ser comprometido en cualquier momento.
No confiamos en hacer al Agent lo suficientemente resistente como para detectar cada ataque. La defensa a nivel de modelo no funciona, como se demostró anteriormente. Entrénalo hoy para detectar inyecciones en código Morse; mañana los atacantes cambiarán a Base64, texto esteganográfico en imágenes o un PDF de apariencia inocua. En su lugar, invertimos la suposición. El Agent se encuentra dentro del modelo de amenazas, y el resto del sistema está diseñado para contenerlo. Incluso si un atacante controla completamente al Agent, los activos de los usuarios permanecen seguros. Posicionamiento en una línea: The Secure Agentic Wallet — una billetera que trata a su propio Agent como no confiable por defecto y permanece segura sin importar las circunstancias.
A partir de este modelo de amenazas, derivamos cinco principios de diseño.
Principio 1: El Agent nunca debe tocar las claves privadas. Las claves privadas son la única credencial que controla los activos on-chain. Si el Agent puede leerlas, un compromiso significa claves perdidas. Las claves deben residir donde el Agent arquitectónicamente no pueda alcanzarlas.
Principio 2: Preparación no es autorización. Construir una transacción y aprobarla son dos actos separados. El Agent puede ayudar a los usuarios a entender el estado on-chain y ensamblar intenciones, pero la decisión de firma pertenece a un módulo backend independiente al que el Agent no tiene acceso.
Principio 3: La revisión es detección, no ejecución forzada. 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 entender 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 al prompt injection.
Principio 4: Las políticas rígidas son la última línea de defensa. Supongamos que el Agent es engañado para iniciar 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 la bloquea igualmente. El Agent no tiene permiso para cambiar estos límites.
Principio 5: Sin evidencia, no hay ejecución. Un escaneo fallido no es una aprobación. La ausencia de datos no es “seguro”. Cuando la evidencia de seguridad es inexistente, contradictoria, obsoleta o 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 Agent
El primer problema es simple. Queremos un asistente que prepare transacciones on-chain, pero darle capacidad de firma le otorga el poder de mover dinero real. Prácticamente todas las brechas de seguridad de Web3 Agent en 2025 y 2026 siguieron el mismo patrón: las claves privadas vivían dentro del proceso del Agent, y los atacantes encontraban la forma de extraerlas.
Así que reformulamos la pregunta: ¿y si el Agent literalmente no puede firmar? No que “se le dice que no lo haga”, sino que arquitectónicamente no puede. Los controles de acceso a nivel de software siempre se pueden eludir. Necesitábamos algo más fuerte.
Web3 Companion implementa aislamiento a nivel de proceso. Solo un componente toca las claves privadas: el Secure Signature Module (SSM), un proceso Go independiente. La memoria del proceso del Agent, las variables de entorno y el sistema de archivos no contienen ningún material de claves. Todo lo que el Agent 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 de inmediato. Descartado. Cifrado derivado de contraseña: requiere reintroducción en cada reinicio, poco práctico para un servicio Docker de larga ejecución. Descartado. Elegimos cifrado de sobre: cada clave de billetera se cifra con su propia clave de datos, y esa clave de datos se envuelve con una clave maestra (AWS KMS o AES-256 local). Incluso si los archivos cifrados se exfiltran en su totalidad, son inútiles sin la clave maestra. Las claves solo existen en texto plano momentáneamente dentro de la memoria del SSM y se borran inmediatamente después de firmar.
Cada solicitud de firma recorre el mismo camino. Sin atajos, sin vía rápida. Una transacción pasa por siete pasos en orden: verificación de delegación, simulación, verificación de seguridad, revisión de seguridad del Agent, evaluación de políticas, aprobación por Passkey y, finalmente, firma del SSM. Completar un paso nunca permite saltar 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. math/rand está prohibido en todo el código crítico de seguridad, con cumplimiento forzado 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 Agent comprometido puede ensamblar una intención de transacción de apariencia completamente legítima para engañar a los usuarios o explotar las políticas de firma automática. El prompt injection no necesita la clave privada; solo necesita que el sistema firme una transacción maliciosa a través del flujo normal.
La pregunta central: cuando el Agent que prepara las transacciones podría 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 RPC se caen, los ataques novedosos quedan fuera de los patrones conocidos. ¿Solo revisión basada en LLM? La misma inyección que comprometió al Agent compromete al revisor, ya que ambos corren sobre LLM. ¿Solo un límite rígido? Los usuarios legítimos chocan contra un muro; un tope de 100 dólares en cada swap es inutilizable.
Combinamos las cuatro capas. Cada capa asume que todas las capas 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 revert, verificaciones de formato de campos. La simulación detecta problemas obvios pero tiene puntos ciegos. Las nuevas técnicas de ataque y las caídas de RPC pueden derrotarla.
Capa 2: Evaluación de la contraparte. Una batería de verificaciones estáticas apunta a la contraparte: coincidencia de destinatario/monto, detección de aprobaciones ilimitadas, detección de direcciones de quema, llamadas delegadas inesperadas. La puntuación de riesgo de direcciones se ejecuta a través del servicio de cumplimiento x402 de BlockSec, donde el Agent consulta etiquetas y puntuaciones de riesgo mediante micropagos x402 sin necesidad de clave API ni suscripción. Las capas 1 y 2 juntas detectan la mayoría de los problemas comunes, pero ambas pueden eludirse. Su rol está deliberadamente limitado a la detección y explicación, no a las decisiones finales.
Capa 3: Aplicación rígida de políticas. Aplicación pura por código en Go. El LLM no participa y el Agent 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 Agent pudiera editar las políticas, una inyección elevaría primero 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 Agent 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 en el peor caso es de 500 dólares, no la billetera entera. 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 rostro). Ningún exploit puramente de software puede falsificar esto.
Las cuatro capas operan sobre 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 el Passkey. Cada capa se sostiene por sí misma.
Un detalle fácil de pasar por alto: la reutilización de veredictos. Una técnica de ataque DeFi conocida reutiliza 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 solo se aplica a la intención exacta que revisó. Si el Agent reconstruye una transacción — incluso cambiando solo el monto o el destinatario — el sistema la trata como una intención completamente nueva y ejecuta todas las verificaciones de nuevo.
Las cuatro capas de defensa se corresponden con tres límites de confianza independientes: Private Key, Policy y Passkey. La brecha de cualquier límite individual deja los otros dos en pie:
| Límite comprometido | Protección restante |
|---|---|
| Agent (prompt injection, RCE) | Sin claves = sin firma; la política bloquea lo que exceda el límite; Passkey bloquea operaciones no aprobadas |
| Revisión de seguridad (veredicto envenenado) | La política sigue aplicando los límites; las operaciones de aprobación manual aún requieren Passkey |
| Política (mala configuración del usuario) | Las operaciones de aprobación manual aún requieren verificación biométrica |
| Todo excepto Passkey | Las credenciales están vinculadas al hardware; el atacante necesita al usuario físicamente presente |
Seguridad por diseño: La filosofía detrás del código abierto
BlockSec ha trabajado en seguridad on-chain desde el primer día. Hemos protegido miles de millones de dólares en activos on-chain y hemos visto la misma lección repetirse: la seguridad que no se incorpora en la arquitectura desde el inicio siempre llega demasiado tarde.
Los AI Agent se están convirtiendo en una nueva puerta de entrada a las transacciones on-chain. El espacio se mueve rápido, pero los estándares de seguridad apenas existen. La mayoría de los equipos se centran en lo que su Agent puede hacer. Pocos se han preguntado seriamente: si este Agent es comprometido, ¿puede la arquitectura limitar el radio de la explosión?
Web3 Companion es el esfuerzo de BlockSec por canalizar años de trabajo en seguridad on-chain hacia una arquitectura de Agentic Wallet. El código es completamente abierto bajo la licencia MIT (actualmente etiquetado como vista previa de investigación). La industria necesita un punto de referencia concreto de diseño de seguridad ahora. 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.