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 on-chain en nombre de 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 Agentes de IA podría alcanzar los 3–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 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 función importa.

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

Qué tan Peligrosos Son los Agentes Actuales: El Incidente 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 de 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 salieron a la luz.

Las claves privadas estaban en texto plano en archivos locales que el Agente podía leer. Bastó un solo correo electrónico con inyección de prompt 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 el 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 directamente diseñados para vaciar billeteras cripto.

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 críticas de seguridad. Los investigadores demostraron que dos valores de token consecutivos eran suficientes para reconstruir el estado interno y predecir todos los tokens y valores 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 una capa de políticas. No existía nada 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 Defecto 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 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 prompts del sistema, los mensajes del usuario, el contenido de páginas web e incluso el nombre de un token llegan todos como el mismo flujo de tokens. El modelo no tiene un mecanismo confiable para separar "ejecuta esto" de "solo lee esto". De aquí se derivan tres consecuencias.

Primero, la inyección de prompt es irresoluble a nivel del modelo. Los atacantes pueden ocultar instrucciones en cualquier cosa que el Agente consuma: 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 travesura en un robo.

Segundo, la propia revisión de seguridad basada en Skills del Agente puede ser subvertida. Un LLM que evalúa la seguridad de una transacción depende completamente del contexto. Envenena el contexto y el veredicto cambia. Las firmas maliciosas pasan sin problemas.

Tercero, 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 significar la pérdida inmediata de fondos.

La comunidad de seguridad coincide ampliamente: darle 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 podría ser comprometido en cualquier momento. Como 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 dependemos de hacer al Agente lo suficientemente robusto como para detectar cada ataque. La defensa a nivel del 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 inocente. En cambio, dimos la vuelta a la suposición. El Agente está dentro del modelo de amenazas, y el resto del sistema está diseñado para contenerlo. Incluso si un atacante controla completamente el Agente, los activos del usuario permanecen seguros. Posicionamiento en una línea: La Billetera Agéntica Segura, una billetera que trata a su propio Agente como no confiable por defecto y permanece segura independientemente.

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 on-chain. Si el Agente puede leerlas, un compromiso significa claves perdidas. Las claves deben vivir donde el Agente arquitectónicamente no pueda alcanzarlas.

Principio 2: La preparación no es autorización. Construir una transacción y aprobarla son dos actos separados. El Agente 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 de backend independiente al que el Agente no puede acceder.

Principio 3: La revisión es detección, no ejecució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 entender el riesgo, pero no son el veredicto final. Las simulaciones pueden fallar, las etiquetas pueden estar ausentes, y el propio análisis del LLM es vulnerable a la inyección de prompt.

Principio 4: Las políticas rígidas son el último recurso. Supongamos que un Agente es engañado para iniciar una transferencia de $100,000 y la revisión de seguridad es manipulada para aprobarla. Un límite diario de $1,000 aplicado por código la bloquea de todas formas. El Agente no tiene permiso para cambiar estos límites.

Principio 5: Sin evidencia, sin ejecución. Un escaneo fallido no es un pase libre. Los datos faltantes no son sinónimo de "seguro". Cuando la evidencia de seguridad está ausente, es contradictoria, está desactualizada o es insuficiente, el sistema se detiene y espera 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 on-chain, 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 manera de extraerlas.

Así que reformulamos la pregunta: ¿qué pasa si el Agente literalmente no puede firmar? No "se le dice 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, por sus siglas en inglés), 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. Todo lo 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 del disco expone la clave de inmediato. Descartado. Cifrado derivado de contraseña: requiere reingreso en cada reinicio, lo cual es poco práctico para un servicio Docker de larga duración. Descartado. Elegimos 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, sin vías rápidas. 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 Agente, evaluación de políticas, aprobación con Passkey y finalmente firma por 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. math/rand está prohibido en todo el código crítico de seguridad, aplicado 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 lograr 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 aguanta por sí sola. ¿Solo simulación? Las simulaciones fallan, los RPC se caen, 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 corren sobre LLMs. ¿Solo un límite rígido fijo? Los usuarios legítimos chocan con una pared; un tope de $100 en cada swap es imposible de usar.

Combinamos las cuatro capas juntas. 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 reversiones, verificaciones de formato de campos. La simulación detecta problemas obvios pero tiene puntos ciegos. Las nuevas técnicas de ataque y las interrupciones de RPC pueden derrotarla.

Capa 2: Evaluación de 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 quemadas, llamadas de delegación inesperadas. La puntuación de riesgo de direcciones se realiza 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 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 acotada a la detección y la explicación, no a las decisiones finales.

Capa 3: Aplicación de Políticas Rígidas. Ejecución en código Go puro. 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 contra un límite de $100 por transacción es rechazada en el acto. Cambiar la propia política requiere Passkey. ¿Por qué? Si el Agente pudiera editar las políticas, una sola 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 Agente completamente comprometido firma una transacción maliciosa, la pérdida real está acotada por la política. Si el usuario establece el umbral diario de firma automática en $500, la pérdida máxima es $500, 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 de 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 el 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 conocida en DeFi 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 únicamente a la intención exacta que revisó. Si el Agente reconstruye una transacción, incluso cambiando solo el monto o el destinatario, el sistema la trata como una intención completamente nueva y vuelve a ejecutar todas las verificaciones.

Las cuatro capas de defensa se mapean en tres fronteras de confianza independientes: Clave Privada, Política y Passkey. Cualquier brecha en una sola frontera deja las otras dos intactas:

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 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 on-chain. El espacio avanza rápido, pero los estándares de seguridad apenas existen. La mayoría de los equipos se enfocan en lo que su Agente puede hacer. Pocos se han preguntado seriamente: si este Agente es comprometido, ¿puede la arquitectura limitar el radio de la explosión?

Web3 Companion es el esfuerzo de BlockSec para canalizar años de trabajo en seguridad on-chain 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). La industria 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. Estamos publicando el diseño completo para que la comunidad pueda construir sobre él.