Gestión de Claves y Seguridad Operacional para Pagos con Criptomonedas

La mayoría de los incidentes graves de 2025-2026 tienen su origen, en última instancia, en claves o en la firma: una herramienta de firma comprometida, una clave de administrador filtrada o un operador víctima de phishing. (Analizamos esos casos por separado en nuestro análisis de los hackeos recientes a pagos con criptomonedas.) El hilo conductor suele estar en cómo se autorizan, almacenan o utilizan las claves para firmar.

El problema es que multisig, MPC, carteras calientes/frías y HSM se discuten como si fueran opciones al mismo nivel, y confundirlos convierte la selección en un caos. En realidad son tres dimensiones independientes, y una configuración real de gestión de claves es una combinación de las tres. Este artículo analiza cada una de ellas, y luego aborda la arquitectura híbrida, la infraestructura de firma y los estándares operativos que la sostienen, y la superficie operativa más amplia que la rodea: aislamiento de API e infraestructura, personas y proveedores, dominios e identidad, y el riesgo más nuevo y menos comprendido: los Agentes de IA con acceso a sus fondos.

Claves Privadas, Frases Semilla y Por Qué "Está en Mi Dispositivo" No Es Seguridad

En el núcleo de todo esto está la clave privada: una cadena de números aleatorios criptográficos. Quien la posea puede firmar transacciones y mover los fondos en la dirección correspondiente. Es el control definitivo sobre los fondos de una dirección — y el punto de riesgo singular definitivo.

Una frase semilla (generalmente 12 o 24 palabras, el estándar BIP-39) es una codificación legible por humanos de esa clave privada. La regla "Determinista Jerárquica" (HD) deriva miles de claves privadas y direcciones a partir de una sola frase semilla. Esto hace que una frase semilla sea al menos tan sensible como una clave privada individual, y probablemente más: filtre una clave privada y perderá una dirección; filtre la frase semilla y perderá toda la cartera.

Aquí hay un error conceptual común que vale la pena nombrar directamente: algunos asumen que mientras el dispositivo de firma y la cartera estén en sus propias manos, y la clave esté desconectada, nada puede salir mal. El problema es que las claves privadas y las frases semilla en carteras de software y hardware ordinarias pueden exportarse. Cualquier persona con acceso interno al dispositivo o a una copia de seguridad puede exportar y copiar la clave privada, y luego controlar los fondos desde cualquier lugar — sin necesidad de tocar nunca ese dispositivo "propio".

Por lo tanto, "la clave está en mi propio dispositivo" no equivale a "nadie más puede tomarla". Lo que realmente importa es si la clave privada puede exportarse. Como verá a continuación, el HSM es la única opción que bloquea la exportación a nivel de hardware.

Tres Dimensiones Independientes, No Un Espectro

Antes de poder elegir una configuración, es útil separar las tres preguntas que realmente está respondiendo.

Modelo de Autorización: Single-Sig, Multisig o MPC/TSS

Single-sig significa que una sola clave privada controla todo: la configuración más sencilla y el mayor punto único de falla.

Multisig requiere M de N claves privadas independientes para firmar juntas (por ejemplo, 3 de 5), donde cada firmante posee una clave privada completa e independiente. En cadenas que admiten contratos inteligentes, el multisig de contrato (Safe es el estándar de facto) implementa esta lógica en un contrato, con firmas y reglas de umbral verificables públicamente en la cadena — a costa de mayor gas por transacción y una edición de la configuración del contrato cada vez que se cambian los firmantes. Aquí también hay una debilidad fácil de pasar por alto: la infraestructura de firma para el multisig de contrato todavía es inmadura. Una llamada execTransaction de Safe a menudo aparece en una cartera de hardware como una larga cadena de calldata, por lo que los firmantes tienen dificultades para ver qué están aprobando realmente, y el soporte del ecosistema para Clear Signing y el análisis de transacciones sigue siendo limitado. Esta es exactamente la superficie de ataque explotada en el incidente de Bybit, razón por la cual las empresas que adoptan el multisig de contrato a menudo necesitan incorporar análisis de transacciones de terceros y verificación cruzada para llenar el vacío. Cadenas como Bitcoin, por el contrario, admiten multisig de forma nativa en la capa de script, sin dependencia de contratos.

MPC (firmas de umbral, TSS) no es "cortar una clave privada completa en pedazos". El MPC real utiliza generación de claves distribuida (DKG): la clave se distribuye desde el momento en que se crea, cada parte posee una participación de clave independiente, y nunca existe una clave privada completa en ningún momento. Cada parte calcula una firma parcial a partir de su participación, y esas firmas parciales se combinan mediante un protocolo criptográfico en una única firma estándar — un cálculo, no una concatenación de cadenas de bytes — de modo que el resultado es indistinguible en la cadena de una firma ordinaria. El costo de gas es normal, la compatibilidad entre cadenas es buena, y cambiar los firmantes o el umbral no requiere tocar un contrato.

Vale la pena distinguir MPC/TSS de un método más antiguo y fácilmente confundible: Shamir Secret Sharing (SSS). SSS divide una clave privada completa ya existente en n piezas; para firmar, se reúnen suficientes piezas y la clave privada completa se reconstruye en memoria antes de firmar — y ese momento de reconstrucción es el punto único de falla. TSS nunca reconstruye; la clave privada completa nunca aparece. Eso es lo que lo hace más seguro que SSS.

Tanto multisig como MPC eliminan el riesgo de punto único, solo a través de mecanismos diferentes. Multisig es múltiples claves completas más verificación en la cadena: transparente, pero costoso y engorroso para rotar firmantes. MPC es múltiples participaciones de clave más combinación fuera de la cadena de firmas parciales: flexible y económico, pero la coordinación depende de su infraestructura.

Protección de Hardware: Software, Cartera de Hardware, TEE o HSM

El almacenamiento de software mantiene la clave privada en un servidor o software — la opción más conveniente y la más frágil. Una cartera de hardware (Ledger, Trezor y similares) mantiene la clave en un chip seguro, firma dentro del dispositivo y nunca permite que la clave lo abandone.

TEE (Entorno de Ejecución Confiable) — piense en Intel SGX, AWS Nitro o Apple Secure Enclave — delimita una región de memoria aislada y cifrada en una CPU de propósito general, donde las claves y el cálculo de firma permanecen fuera del alcance incluso de un atacante con acceso root al SO. Se sitúa entre el software y el HSM: aislamiento lógico sólido, buen rendimiento y capacidad para ejecutar código arbitrario (incluidos protocolos MPC), aunque su resistencia física a manipulaciones y la certificación de cumplimiento no alcanzan el nivel de un HSM. Esta es también la forma más común de almacenar participaciones de clave MPC — generadas por DKG dentro del enclave y nunca extraídas de él. Fireblocks, por ejemplo, distribuye las participaciones de clave MPC entre enclaves SGX en múltiples nubes.

HSM (Módulo de Seguridad de Hardware) es hardware de grado empresarial resistente a manipulaciones que cumple con certificaciones como FIPS 140-2/3, con resistencia física a manipulaciones y borrado automático en caso de intrusión. Su garantía más sólida: la clave privada se genera dentro del hardware, se marca como no exportable y físicamente no puede salir. Eso es lo que lo separa fundamentalmente del software y las carteras de hardware, y es por eso que el HSM es adecuado para la custodia de claves privadas completas de alto valor.

Esta dimensión es ortogonal al modelo de autorización anterior: cada clave completa en un multisig puede residir en una cartera de hardware o un HSM, mientras que cada participación MPC generalmente reside en un enclave TEE.

Temperatura de Fondos: Caliente, Tibio o Frío

Esta dimensión no se preocupa por cómo se almacena la clave — solo por cuánto está expuesta la clave privada a internet, es decir, qué tan rápido y qué tan automáticamente puede moverse el dinero.

Las carteras calientes están siempre en línea, se utilizan para pagos instantáneos y pagos automáticos — las más rápidas y de mayor riesgo, generalmente manteniendo solo un porcentaje de un solo dígito del total de fondos. Las carteras tibias están en línea, pero con la clave privada aislada en un entorno protegido (un servicio de firma dedicado o HSM), requiriendo un humano en el ciclo de firma; estas manejan la liquidación operativa diaria. Las carteras frías están completamente fuera de línea y con espacio de aire, utilizadas para el almacenamiento a largo plazo de grandes reservas — la mayor seguridad, la más lenta de usar, y generalmente con la mayor parte de los fondos.

Para ser claros, la temperatura se trata fundamentalmente de la exposición en línea de la clave privada y de la facilidad con que se mueven los fondos; la frecuencia de transferencia y la proporción de fondos son consecuencias de eso, no la definición. Esta dimensión también es ortogonal a las dos primeras: una cartera fría puede usar multisig más HSM, y una cartera caliente puede usar MPC.

Combine las tres y obtendrá el panorama completo: el modelo de autorización, la protección de hardware y la temperatura de fondos son independientes, y una configuración real de gestión de claves combina las tres.

Configuraciones Comunes de Gestión de Claves

Así es como la industria comúnmente combina las tres dimensiones:

El punto de selección es estratificar por temperatura de fondos y usar la mejor combinación en cada nivel. Las carteras calientes necesitan velocidad, por lo que se prefiere MPC. Las carteras frías necesitan estabilidad y auditabilidad, por lo que se prefiere multisig más HSM. La gobernanza y los privilegios de contratos necesitan transparencia y responsabilidad, por lo que se prefiere multisig de contrato más timelock.

Arquitectura Híbrida Recomendada por BlockSec

BlockSec recomienda una arquitectura híbrida estratificada por temperatura.

Carteras calientes/tibias: firma MPC. Elimina el punto único de falla de una clave privada, mantiene baja la latencia de firma y es adecuada para pagos de alta frecuencia. Las participaciones deben distribuirse en diferentes ubicaciones físicas y dominios de seguridad.

Carteras frías: control multipartito más auditabilidad en la cadena, adecuado para grandes reservas. Qué implementación usar depende de la capacidad operativa en la cadena de su equipo — hay dos caminos:

• Para máxima transparencia, con operaciones en la cadena maduras: use multisig de contrato (p. ej., 3 de 5 de Safe), donde las reglas de umbral y cada firma son verificables públicamente en la cadena. En Bitcoin, use multisig nativo de la capa de script, con cada firmante protegiendo su propia clave en un HSM o cartera de hardware. Tenga en cuenta que las herramientas de análisis de firmas para el multisig de contrato aún son inmaduras, por lo que el equipo debe agregar verificación cruzada por sí mismo — las operaciones aquí no son ligeras.
• Para equipos menos familiarizados con la ejecución en la cadena que desean menos complejidad operativa: use firma de umbral MPC con participaciones en un TEE, luego incorpore un tercero independiente como cofirmante para ejecutar una verificación de seguridad de transacciones antes de cada firma. Esto evita la brecha de herramientas del multisig de contrato y construye verificación independiente de terceros directamente en el umbral de firma.

Actualizaciones de contratos y cambios de políticas: multisig más timelock. Cualquier operación que cambie privilegios requiere aprobación de múltiples personas y un retraso temporal.

Algunos parámetros importan independientemente del camino que tome. Use al menos 3 firmantes, con un umbral de al menos el 50% pero por debajo del recuento total — evite N-de-N, ya que un solo firmante inaccesible bloquearía la firma y bloquearía los fondos, y si cada firmante es indispensable, cada uno se convierte en un objetivo crítico de coacción o secuestro. Un umbral por debajo del total deja redundancia y reduce el valor de apuntar a cualquier firmante individual. Cada firmante también debe usar una dirección nueva y dedicada en cada multisig, nunca compartida con otros multisigs o carteras personales, y los firmantes deben ser diversos en geografía, rol organizacional y entidad legal — con dispersión que aumenta a medida que aumenta el nivel de riesgo de la cartera.

Ese nivel de riesgo debe provenir de una clasificación formal: evalúe cada cartera por su impacto financiero en el negocio, la dependencia del protocolo y el riesgo reputacional, y asigne a cada grado un umbral diferente, un flujo de aprobación y una densidad de monitoreo. Revise la clasificación cada 6 meses, e inmediatamente después de un gran cambio en el TVL, una actualización de contrato o un incidente de seguridad.

Firma Ciega y Aislamiento del Entorno de Firma

La firma ciega significa que su herramienta de firma le muestra un hash de calldata — no lo que realmente hace la transacción. No es un riesgo hipotético: en el momento de la firma, el firmante no puede comprender el significado real de una transacción desde la interfaz, y esa brecha fue una causa directa del incidente de Bybit, donde el front end o back end utilizado para firmar fue comprometido y los firmantes aprobaron una transacción maliciosa sin ningún error en los contratos mismos.

Bloquear las tres dimensiones anteriores solo funciona si el proceso de firma a su alrededor está igualmente reforzado. Algunos estándares se aplican independientemente de la configuración:

• Hardware de firma obligatorio. Todas las operaciones multisig de producción deben usar una cartera de hardware con una pantalla lo suficientemente grande para mostrar el resumen completo de la transacción y compatibilidad con Clear Signing, protección con PIN con verificación de integridad del firmware, y una cadena de suministro limitada al fabricante o revendedores autorizados — verifique la autenticidad al recibirla.
• Entorno de firma físicamente aislado. La firma debe ejecutarse en dispositivos con espacio de aire, sin compartir la red de oficina cotidiana; las operaciones de alto valor justifican dispositivos de firma dedicados. Implemente el servicio de firma en un dominio de seguridad independiente, físicamente aislado de la lógica de negocio y el front end. Los nodos de firma no deben estar directamente expuestos a internet público — conéctese a ellos solo a través de VPN o una línea privada. Los registros de operaciones de firma deben almacenarse por separado, no modificables por el sistema de negocio.
• Verificación independiente de transacciones. Verifique el contenido de la transacción a través de un canal independiente antes de firmar — un terminal dedicado, un dispositivo de hardware o un servicio de simulación/riesgo de transacciones de terceros. Esta verificación es mejor realizarla por un tercero independiente, no solo por su propio front end o back end — confiar solo en sistemas internos es en sí mismo un punto único de falla. Una vez que el front end o back end interno está comprometido, como con Bybit, lo que el firmante ve en pantalla es información falsa manipulada, y verificarse a sí mismo contra sí mismo no es ninguna verificación en absoluto. La ruta de pago especialmente necesita esta línea de defensa independiente.
• Clear Signing y verificación cruzada. Use herramientas que analicen la semántica de las transacciones, para que el firmante vea "transferir 1,000 USDC a 0x1234..." en lugar de una cadena de calldata, y verifique de forma cruzada los parámetros clave — ID de cadena, dirección de destino, calldata, valor, nonce y tipo de operación — como idénticos en al menos dos herramientas o interfaces independientes.
• Doble verificación humana y automatizada. Un motor de reglas automatizado maneja la detección de primera pasada, y un humano confirma las transacciones grandes antes de que salgan.
• Confianza cero y copias de seguridad. Implemente el servicio de firma, la lógica de negocio y la interfaz front end en diferentes dominios de seguridad, y mantenga alternativas para la IU de firma principal, RPC y el explorador de bloques, para que un fallo de un solo proveedor o servicio no pueda bloquear la firma de emergencia.

Estándares Operativos de Multisig

Las elecciones de claves y umbrales solo llegan hasta cierto punto. Algunos estándares operativos importan igual.

Registro de multisig. Mantenga un único registro de cada multisig, con cada entrada que incluya al menos: dirección, cadena, umbral de firma, grado de riesgo, propósito, direcciones de firmantes, contratos controlados, roles en la cadena y fecha de última revisión. Los cambios sensibles a la seguridad deben actualizar el registro en 24 horas, los cambios rutinarios en 3 días.

Gestión del ciclo de vida de los firmantes. Verifique las direcciones antes de la incorporación haciendo que la dirección prospectiva firme un mensaje específico, verificado con una herramienta independiente. Establezca SLA para eliminar los privilegios de un firmante que se va o es removido por grado de riesgo — urgente en 48-72 horas, crítico en 7 días, todo lo demás en 14 días. Ejecute una revisión de acceso trimestral para confirmar que cada firmante aún controla su clave, y renueve la capacitación de los firmantes al menos anualmente, cubriendo verificación de transacciones, procedimientos de emergencia y defensa contra ingeniería social/phishing, con una evaluación práctica después.

Protección de frases semilla y copias de seguridad. Sin almacenamiento digital de ningún tipo — sin unidades en la nube, álbumes de fotos o documentos. Almacene las copias de seguridad dispersas en diferentes ubicaciones geográficas, recuperables ante desastres naturales, robos y un operador desaparecido. Ningún punto único debe contener la información de recuperación completa.

Comunicaciones seguras. Coordine entre firmantes utilizando canales primarios y de respaldo en diferentes plataformas, cada uno con MFA obligatorio, cifrado de extremo a extremo y membresía solo por invitación. Antes de firmar, verifique la identidad de un firmante a través de un canal independiente — una videollamada, una frase de contraseña y un segundo canal autenticado — para evitar que una cuenta de mensajería instantánea comprometida suplante a un firmante.

SLA de respuesta a emergencias. Establezca tiempos de respuesta de los firmantes por gravedad del incidente, por ejemplo urgente en menos de 2 horas, tiempo sensible 2-12 horas, rutinario 24-48 horas. Pruebe la accesibilidad de los firmantes trimestralmente, no solo en papel, y ejecute al menos un simulacro de emergencia de extremo a extremo al año, cubriendo escenarios como una clave filtrada, un firmante inaccesible, un canal de comunicación comprometido y operaciones de protocolo de emergencia.

Monitoreo en la cadena de multisig. Monitoree cambios de firmante/umbral, transferencias por encima del umbral, brechas de nonce, interacciones con direcciones desconocidas, transacciones fallidas, cambios de Module/Guard y saldos anormales de carteras de proponentes. La propia infraestructura de monitoreo debe ser resistente a manipulaciones.

Seguridad de API

La seguridad de API es la primera línea de defensa para su backend de pagos. Eso significa autenticación mediante una clave API más firma HMAC o FIDO2/WebAuthn, limitación de velocidad para prevenir fuerza bruta y abuso, protección DDoS a través de un servicio CDN/WAF, validación estricta de cada parámetro de entrada para prevenir inyecciones, y auditoría de registros para que cada llamada a la API produzca una pista de auditoría completa.

Los entornos de firma deben estar aislados de todo eso, no solo protegidos por ello — razón por la cual el servicio de firma pertenece a su propio dominio de seguridad, como se explicó anteriormente.

Seguridad Operativa: Personas, Proveedores y Auditorías Independientes

Varios incidentes importantes en 2026 involucraron ingeniería social — reclutamiento falso, suplantación de soporte de TI e intercambio de rostros con IA entre ellos. Defenderse de ello requiere tres niveles trabajando juntos.

La capacitación y evaluación es lo primero: todos con acceso a sistemas de firma, credenciales de producción u operaciones sensibles completan capacitación en seguridad al incorporarse, la actualizan anualmente y actualizan el contenido en 30 días de cualquier cambio de proceso.

La separación de funciones importa igual: iniciación, aprobación y ejecución no pueden ser realizadas por la misma persona, y las cuentas de administrador no pueden pagar directamente. Las operaciones de alta sensibilidad como la firma deben usar dispositivos dedicados — cifrado de disco completo, bloqueo automático — con carteras de hardware guardadas en una caja fuerte cuando no estén en uso, y todo el acceso remoto enrutado a través de una VPN.

Los terceros necesitan la misma disciplina. Realice la debida diligencia antes de seleccionar un proveedor, revise anualmente el estado de cumplimiento y seguridad de los proveedores clave, y otorgue acceso de terceros con un alcance, propósito y vencimiento claros — revocados inmediatamente una vez que venza o termine el proyecto. Verifique la identidad del personal de terceros de forma independiente antes de otorgar cualquier acceso.

Nada de esto debe depender únicamente de autocomprobaciones internas. Ejecute evaluaciones de seguridad independientes de terceros regularmente, cubriendo al menos pruebas de penetración, ejercicios de equipo rojo y auditorías de código y contratos inteligentes. Corrija los hallazgos uno por uno y verifique el cierre en la siguiente ronda de evaluación.

Seguridad de Desarrollo e Infraestructura

Varios incidentes importantes de pagos y criptomonedas en los últimos años tienen su origen en un proceso de desarrollo comprometido — con los contratos y la lógica de firma perfectamente bien. Eso significa que la capa de desarrollo e infraestructura merece la misma atención que la capa de firma, en cuatro áreas.

El aislamiento del entorno de desarrollo mantiene las cuentas de desarrollo separadas de las cuentas privilegiadas (firma, gestión de nube), mantiene las credenciales de producción fuera del alcance del entorno de desarrollo, y pone las herramientas y extensiones de desarrollo en una lista de aprobación.

Sus repositorios de código y cadena de suministro necesitan protección de ramas, commits firmados y revisión multipersona en la rama principal. Extraiga dependencias solo de repositorios oficiales con versiones fijadas y verificaciones de typosquatting, y ejecute escaneo automático de secretos que revoque y rote cualquier clave expuesta de inmediato.

En CI/CD, los cambios de configuración del pipeline necesitan aprobación multipartita y control de versiones, con compilaciones reproducibles. Los secretos van a través de un gestor dedicado como Vault o un KMS en la nube — los secretos de producción nunca deben ser directamente accesibles para los humanos — y SAST más escaneo de dependencias son condiciones previas para la implementación, no extras opcionales.

Para infraestructura y nube, otorgue acceso privilegiado mediante aprovisionamiento justo a tiempo, aprobación multipartita y límites de tiempo. Mantenga cuentas break-glass para emergencias, pero alerte sobre cada uso. Ejecute registros de auditoría completos, alertas en tiempo real sobre operaciones administrativas, y copia de seguridad y recuperación ante desastres regularmente practicadas.

Dominio, DNS e Identidad: La Superficie de Ataque Subestimada

El dominio y el DNS son una superficie de ataque muy subestimada en las criptomonedas — muchos incidentes de phishing y robos se remontan a una cuenta de registrador comprometida o un DNS secuestrado. Proteger los dominios donde los usuarios inician operaciones de fondos importa tanto como proteger el entorno de firma en sí.

Gestione su cuenta de registrador como una cuenta de alto privilegio: aplique MFA con clave de hardware y requiera una segunda confirmación fuera de banda para cambios críticos como transferencias, eliminaciones o cambios de servidor de nombres. En el lado del DNS y el correo electrónico, habilite DNSSEC en dominios críticos, use CAA para limitar qué CA pueden emitir certificados, y configure SPF/DKIM/DMARC (p=reject) en todos los dominios de envío — establezca también dominios que no envían para rechazar explícitamente el correo, para prevenir la suplantación.

Monitoree continuamente los cambios de registros DNS, la delegación de servidores de nombres y la emisión anómala en registros de Transparencia de Certificados, utilizando infraestructura de monitoreo que no dependa del dominio que está vigilando. Documente su proceso de manejo para el secuestro de dominios y la transferencia no autorizada, practíquelo anualmente, y establezca advertencias de vencimiento escalonadas más renovación automática para que un dominio vencido no se convierta en un punto de entrada.

La identidad y las cuentas son el punto de entrada para casi todo el movimiento lateral. Un inventario completo de cuentas organizacionales, más un estándar MFA estricto, importa más que cualquier defensa de punto único.

Comience con un inventario de cuentas: registre cada cuenta organizacional — redes sociales, correo electrónico, SSO/IdP, registrador, plataformas de custodia, repositorios de código, raíz de nube, SaaS clave — con un propietario claro, y revíselas regularmente. Aplique MFA resistente al phishing con claves de hardware FIDO2/WebAuthn en cuentas de alto privilegio, y nunca confíe en SMS o voz como factor principal — el intercambio de SIM, SS7 y el phishing de voz los eluden todos. Esta es la defensa más efectiva contra la toma de control de cuentas.

Aplique un gestor de contraseñas con contraseñas únicas y fuertes, prohíba los inicios de sesión compartidos, y restrinja el correo electrónico y el teléfono de recuperación al dominio organizacional — mantenga los códigos de recuperación en almacenamiento seguro, no en correo personal ni en la nube. Cuando alguien se va, revoque todo su acceso en 24 horas y rote cualquier credencial compartida que haya tocado, y mantenga monitoreo continuo de comportamiento y fugas de credenciales en cuentas de alto privilegio durante todo el tiempo que estén activas.

Por Qué la Arquitectura de un Agente de IA Es Insegura por Diseño

Las empresas de pagos usan cada vez más herramientas y Agentes de IA para aumentar la eficiencia del desarrollo y las operaciones — pero eso abre una nueva superficie de ataque que, manejada incorrectamente, amenaza directamente los fondos.

Aquí está la parte que es fácil pasar por alto: un Agente de IA no es solo un modelo que responde preguntas. Es una máquina que puede leer contenido externo, llamar a herramientas, mantener credenciales y ejecutar acciones. La raíz del riesgo es que trata el texto leído de contenido no confiable como instrucciones a ejecutar.

Eso significa que un atacante no necesita ninguna vulnerabilidad ni ninguna cuenta robada. Ocultar una sola oración en un documento, una página web, un comentario de código o una descripción de PR puede secuestrar el comportamiento del Agente para filtrar datos o realizar acciones no autorizadas. Esto se llama inyección de prompt, y para 2026 se ha demostrado que escala directamente a ejecución remota de código — Microsoft demostró un único prompt lanzando un programa en la máquina que ejecuta un Agente, y GitHub Copilot, Cursor y la infraestructura MCP han divulgado cada uno vulnerabilidades de RCE con una calificación CVSS de 9.6 o superior.

Empeora para cualquier cosa privilegiada. Un Agente de desarrollo u operaciones hereda de forma predeterminada el acceso a archivos, los privilegios de shell y las claves de base de datos de su operador. Un estudio de 2026 que cubre los Agentes de codificación principales encontró que todos podían ser vulnerados mediante inyección de prompt, con una tasa de éxito de ataque adaptativo superior al 85%. Cualquier Agente que procese entradas no confiables debe tratarse como un posible infiltrado que posee sus credenciales — y la cadena de suministro también es un eslabón de alto riesgo: en marzo de 2026, una dependencia de puerta de enlace de IA envenenada estuvo en un repositorio público durante 3 horas y fue descargada casi 47,000 veces.

Cómo Obtener Eficiencia de los Agentes de IA Sin Perder el Control de los Fondos

El enfoque es someter al Agente a las mismas restricciones que aplicaría al código no confiable, en cinco controles:

• Ejecución aislada — ejecute la ejecución de herramientas del Agente en un sandbox, para que la inyección de prompt no pueda alcanzar el shell real, las claves de producción o el entorno de firma.
• Mínimo privilegio — otorgue a las herramientas del Agente, las claves de base de datos y los servicios MCP solo lo mínimo necesario para una sola operación, nunca una credencial de "acceso completo".
• Una puerta humana en operaciones de fondos — para cualquier cosa que involucre transferencias, firma o cambios de privilegios, el Agente solo puede proponer, nunca ejecutar automáticamente. La aprobación humana independiente también se aplica aquí, el mismo principio detrás de la verificación de firma explicada anteriormente.
• Separe las instrucciones de confianza de los datos no confiables — haga esto a nivel de arquitectura, y no espere que el modelo "los distinga por sí solo".
• Bloqueo de la cadena de suministro — aplique la misma fijación de versiones y verificaciones de procedencia a las dependencias relacionadas con IA que aplica a sus repositorios de código regulares.

Estas restricciones no tienen que quedarse en lo teórico. El Web3 Companion de código abierto de BlockSec es una implementación de referencia de una cartera agéntica segura (licencia MIT, vista previa de investigación). Permite que un Agente de IA ayude a un usuario a preparar transacciones en la cadena mientras mantiene las claves privadas y la autorización final completamente fuera del alcance del Agente. Su modelo de amenazas trata al Agente mismo como no confiable — todo el sistema debe garantizar que incluso un Agente completamente comprometido no pueda mover los fondos del usuario.

La arquitectura descansa en tres puntos. El aislamiento de claves significa que solo un módulo de firma independiente (un proceso Go separado) puede tocar la clave privada — el Agente obtiene un ID de intención de transacción, puede solicitar una firma, pero nunca ve una clave. Las claves se almacenan con cifrado de sobre (AWS KMS o AES-256 local), y el texto sin formato existe en memoria solo por el instante de la firma, luego se pone a cero.

Antes de la transmisión, una transacción pasa por cuatro capas en secuencia, cada una asumiendo que la anterior falló: simulación de transacciones (decodificación de calldata, predicción de reversiones), puntuación de riesgo de contraparte, límites de política estricta en Go puro (límite por transacción, presupuesto diario, lista blanca — ninguno de los cuales el Agente puede modificar), y finalmente confirmación humana mediante clave de paso, una huella digital WebAuthn o escaneo facial que un ataque solo de software no puede falsificar. La clave, la política y la clave de paso forman tres límites de confianza independientes, por lo que violar uno deja los otros dos intactos.

Un Agente de IA puede mejorar genuinamente la eficiencia, pero no debe tener control exclusivo sobre los fondos y la firma. Colóquelo en un sandbox de mínimo privilegio como asistente, y deje que los humanos tomen la decisión final sobre fondos y firma.

Poniéndolo Todo Junto

La gestión de claves no es una sola decisión — son tres, tomadas de forma independiente y luego combinadas: quién tiene que firmar, dónde vive físicamente la clave o participación, y cuánto está expuesta a internet. Obtener la combinación correcta para cada nivel de fondos, respaldándola con infraestructura de firma reforzada, y manteniéndola unida con los estándares operativos anteriores es cómo BlockSec enmarca el cierre de las brechas detrás de la mayoría de los incidentes relacionados con claves y firma de 2025-2026. Y dado que la superficie ahora se extiende más allá de las claves — a APIs, personas, proveedores, pipelines de código, dominios, identidad y Agentes de IA — cada uno de ellos necesita el mismo tratamiento: asumir que la capa anterior falló, y mantener a un humano en el ciclo dondequiera que los fondos puedan moverse.

Para el panorama completo de dónde encajan la gestión de claves y la seguridad operativa junto con el resto del programa de cumplimiento de un sistema de pagos, descargue nuestro manual de seguridad y cumplimiento de pagos con criptomonedas (PDF).

Preguntas Frecuentes

¿Cuál es la diferencia real entre MPC y multisig? Multisig son múltiples claves privadas completas, cada una verificada por separado en la cadena — transparente, pero costoso y engorroso para rotar firmantes. MPC (firmas de umbral) son múltiples participaciones de clave generadas de forma que nunca existe una clave privada completa; las firmas parciales se combinan fuera de la cadena en una sola firma — flexible y económico, pero dependiente de su infraestructura de coordinación.

¿Es Shamir Secret Sharing (SSS) lo mismo que MPC? No. SSS divide una clave privada completa ya existente en piezas y reconstruye la clave completa en memoria para firmar, lo que hace del momento de reconstrucción un punto único de falla. El MPC real (TSS) nunca reconstruye una clave privada completa en absoluto — cada parte solo calcula una firma parcial a partir de su propia participación.

¿Cuál es la diferencia entre un TEE y un HSM? Un TEE (como Intel SGX, AWS Nitro o Apple Secure Enclave) es una región aislada y cifrada en una CPU de propósito general que puede ejecutar código arbitrario, incluidos protocolos MPC — aislamiento lógico sólido, pero resistencia física a manipulaciones y certificación más débiles que un HSM. Un HSM es hardware dedicado resistente a manipulaciones donde la clave privada se genera internamente, se marca como no exportable y físicamente no puede salir.

¿Qué es una cartera tibia y en qué se diferencia de las calientes o frías? Una cartera tibia está en línea pero mantiene la clave privada aislada en un entorno protegido (un servicio de firma dedicado o HSM) y requiere un humano en el ciclo de firma, utilizada para la liquidación operativa diaria — situada entre una cartera caliente siempre en línea y automatizada y una cartera fría completamente fuera de línea y con espacio de aire.

¿Qué recomienda BlockSec específicamente para el almacenamiento en frío? Depende de la capacidad operativa en la cadena del equipo: los equipos con operaciones en la cadena maduras pueden usar multisig de contrato (p. ej., 3 de 5 de Safe) con la clave de cada firmante en un HSM o cartera de hardware; los equipos que desean menos complejidad operativa pueden usar firma de umbral MPC con participaciones en un TEE más un cofirmante independiente de terceros para verificaciones de seguridad de transacciones.

¿Qué es la firma ciega y por qué es peligrosa? La firma ciega es cuando una interfaz de firma solo muestra un hash de calldata en lugar de lo que realmente hace la transacción. El firmante no puede verificar el significado real de lo que está aprobando, lo que fue una causa directa del incidente de Bybit.

¿Se puede confiar en los Agentes de IA para las operaciones de pagos con criptomonedas? No con control exclusivo. A un Agente de IA solo se le debe permitir proponer operaciones de fondos, nunca ejecutarlas automáticamente — las transferencias, la firma y los cambios de privilegios necesitan aprobación humana independiente, con el Agente ejecutándose en un sandbox de mínimo privilegio.

¿Qué es la inyección de prompt y qué tan grave es? La inyección de prompt oculta instrucciones en contenido no confiable — un documento, una página web, un comentario de código o una descripción de PR — que secuestra el comportamiento de un Agente de IA. Para 2026 ha escalado a ejecución remota de código en vulnerabilidades divulgadas que afectan a herramientas de codificación principales, con una calificación CVSS de 9.6 o superior.

¿Cuál es la defensa más efectiva contra la toma de control de cuentas? MFA resistente al phishing — aplicando claves de hardware FIDO2/WebAuthn en cuentas de alto privilegio y nunca confiando en SMS o voz como factor principal, ya que el intercambio de SIM, SS7 y el phishing de voz pueden eludir esos canales.