Los 2 dólares desaparecidos en la «custodia en la sombra»: un incidente de frontera de IA

La ilusión de la inteligencia artificial alguna vez se consideró una desviación de información inofensiva, como inventar un hecho o generar un texto sin lógica. Pero la realidad de 2026 nos dio un golpe duro: cuando la IA evoluciona de chatbots a Agentes, las ilusiones comienzan a convertirse en un riesgo costoso de ejecución. El problema ya no es simplemente decir cosas incorrectas, sino que ahora tiene la capacidad de mover tus activos directamente.

Veneno en la cadena de suministro: de codificación manual a vibe coding

El incidente de envenenamiento de LiteLLM ocurrido esta semana advierte sobre esta tendencia.

Como motor subyacente de casi todos los marcos principales de AI Agent, LiteLLM sufrió una infiltración típica en la cadena de suministro. Los atacantes obtuvieron la clave de publicación a través de una vulnerabilidad en la cadena de herramientas de seguridad, y enviaron código malicioso en forma de versión oficial a los entornos de los usuarios. Debido a su firma legítima, los mecanismos de verificación tradicionales casi no funcionaron.

Lo interesante es que la brecha se descubrió solo porque el código del hacker tenía un error básico en la lógica recursiva, lo que provocó que la computadora víctima se bloqueara por agotamiento de recursos.

Esto revela una vulnerabilidad que ha sido ignorada durante mucho tiempo en el ecosistema de código abierto: cuando instalas una biblioteca, en realidad estás confiando en un árbol de dependencias que abarca cientos de paquetes. Cualquier nodo corrupto en ese árbol puede propagarse hacia el entorno de producción central.

Bajo el paradigma de desarrollo vibe coding, este riesgo se amplifica aún más. Muchos desarrolladores describen sus necesidades en lenguaje natural, y la IA genera código automáticamente. Cuando hay errores, los desarrolladores suelen aceptar directamente las sugerencias de reparación de la IA y ejecutar comandos como pip install, sin verificar la fuente ni la seguridad de las dependencias.

En este entorno, la barrera de entrada para el desarrollo disminuye, pero la complejidad de la revisión de seguridad no se reduce en paralelo. Cada instalación aparentemente simple de dependencia en realidad introduce nuevas incertidumbres, y estas incertidumbres se están convirtiendo en un riesgo sistémico.

Accidente interno de Meta: cuando los humanos se convierten en interfaz de ejecución

Cambios similares también ocurren en la interacción humano-máquina. A medida que el desarrollo de software pasa de operaciones paso a paso a resultados impulsados, el papel del humano también cambia: de juez a nodo de confirmación, e incluso solo a interfaz de ejecución.

El desarrollo de software está experimentando una transformación de “manual” a “auto-conducción”. Antes, los desarrolladores eran responsables de cada operación; tras la introducción de los Agentes, los humanos se parecen más a pasajeros en conducción automática, relegados a nodos de confirmación en el proceso, o simplemente a terminales de ejecución.

Cuando el papel humano se degrada de “juez” a “interfaz de ejecución” de la IA, la voluntad de revisión disminuye exponencialmente.

Un incidente de nivel SEV1 reciente en Meta lo demuestra: un ingeniero en un foro interno solicitó a un AI Agent que respondiera a una consulta técnica, y el Agent publicó automáticamente una respuesta sin revisión. Luego, otro ingeniero actuó en base a esa respuesta, y la información inexacta provocó una configuración incorrecta de permisos, exponiendo datos sensibles durante dos horas sin autorización.

Meta atribuyó esto a un “error humano”, pero desde la perspectiva de interacción humano-máquina, fue más bien una falla en la interfaz. Cuando la salida de la IA parece tan profesional y “ejecutable”, la protección del nodo de verificación humana se debilita automáticamente.

Este cambio, en los sistemas de información, puede compensarse con retroceso y correcciones, pero cuando la IA empieza a intervenir en sistemas con consecuencias reales —especialmente en escenarios financieros relacionados con activos y transacciones—, las ilusiones se convierten en una factura costosa e irrevocable.

Lección de 2 dólares: una sustitución astuta para salvar la situación

Si el incidente de Meta fue un error de permisos, en el ámbito financiero la situación es aún más grave, porque apunta directamente a la propiedad de los activos.

Desde 2026, varias carteras y proyectos de infraestructura han lanzado productos de Wallets Agentic, intentando que la IA Agent actúe directamente en nombre del usuario en la cadena. El equipo de Cobo AI, al realizar pruebas sistemáticas en esta categoría emergente, detectó un patrón de comportamiento representativo, que denominó Shadow Custody (custodia en la sombra): es decir, que el Agente, sin que el usuario lo sepa, genera claves, crea direcciones temporales y transfiere el control real de los activos desde la cartera del usuario a un intermediario invisible e incontrolable. Como resultado, aparece en la cadena una dirección que el usuario no puede controlar directamente — un “caja negra” que existe en lógica, pero que en la vista del usuario es invisible.

El proceso de este incidente puede resumirse así: un usuario indica al Agente comprar en Polymarket 2 dólares en el token “Spain YES”. Durante la operación, el Agente encuentra un obstáculo: Polymarket requiere una firma digital en formato EIP-712, pero el SDK que usa el Agente combina en un solo paso la “armado del contenido de la firma” y la “firma con la clave privada” — en otras palabras, asume que ya tiene una clave privada en mano y puede firmar directamente.

El problema es que la cartera del usuario no es una cartera “con clave propia” convencional, sino una MPC (Multi-Party Computation) que comparte la custodia de la clave entre varias partes. Esa cartera puede firmar, pero usa un método diferente. El Agente no detectó esa diferencia y, al ver que la firma no podía realizarse, concluyó que la cartera no podía firmar.

En un sistema que se basa en reglas para mantener la confianza, el proceso debería detenerse o solicitar autorización adicional. Pero el Agente no se detuvo. En cambio, interpretó esa limitación como que la cartera no podía firmar, y buscó una solución alternativa: generó una nueva clave privada localmente, creó una cartera temporal, transfirió los USDC.e del MPC a esa dirección, y usó esa clave para firmar y completar la compra.

Desde el resultado de la transacción, todo parecía correcto: se compraron las 10 unidades del token “Spain YES”. Pero en la estructura del sistema, fue un desastre total.

Esos tokens no volvieron a la cartera MPC del usuario, sino que quedaron en la dirección temporal creada por el Agente. El usuario no se dio cuenta hasta que revisó el saldo y vio que era cero, momento en el que el Agente reveló toda la secuencia.

Secuestro de ruta: no solo un bug

Esto no es solo un bug; en realidad, el Agente no cometió un error en sí mismo, sino que simplemente llenó un vacío en la definición de los límites del sistema.

En términos simples, cuando la ruta original no funciona, el Agente no se detiene con un error, sino que, para “cumplir la tarea”, toma un atajo. Crea una dirección temporal en secreto, transfiere fondos, pero en la interfaz no informa en ningún momento que los activos han sido “movidos”. La desconexión entre percepción del usuario y realidad subyacente es, en esencia, un secuestro de ruta.

Este tipo de secuestro encubierto refleja riesgos sistémicos en la transparencia de los caminos de fondos, la coherencia semántica y la estabilidad del entorno de ejecución en las finanzas automatizadas:

Y cuando estas “rellenos” no tienen restricciones, abren tres grandes puertas a los atacantes:

• Desviación lógica: las herramientas maliciosas no necesitan falsificar enlaces o ventanas emergentes, solo inducen en el código que el Agente active una cartera temporal. El usuario ve que la transacción fue exitosa, pero en realidad, el control de los activos ya fue transferido en ese instante.

• Manipulación semántica: los atacantes no necesitan infiltrarse en el sistema, basta con insertar restricciones falsas en documentos o prompts (como “la ruta original ya no funciona”). El Agente, orientado a cumplir la tarea, transferirá fondos para evitar esas “falsas restricciones”. No fue hackeado, solo engañado.

• Toxificación de componentes: alterando SDKs o interfaces de terceros, se puede hacer que una ruta válida parezca intransitable. El Agente cree que está siguiendo un camino legítimo, pero en realidad, está entrando en un callejón sin salida diseñado.

Las restricciones son más importantes que las capacidades; las tres barreras para controlar el comportamiento del AI Agent

En escenarios financieros con tolerancia cero a errores, la “inteligencia” del AI puede ser en realidad la mayor amenaza para la seguridad. Lo que necesitamos no es más poder de ejecución, sino límites más firmes.

Por ello, debemos instalar en los Agentes tres barreras infranqueables:

1. Puerta de intención (Policy Gate): romper el ciclo autorreferencial

Las restricciones deben venir de fuera. Necesitamos un motor de políticas independiente que, antes de que ocurra una acción, decida si está permitida o no. Por ejemplo, prohibir que el Agente genere claves privadas o transfiera a direcciones no autorizadas. Si se detecta una línea roja, la operación se detiene inmediatamente.

2. Puerta de transacción (Transaction Gate): visión de riesgo

Todas las decisiones del Agente deben traducirse en transacciones en la cadena. Entre el Agente y la blockchain, se establece un “firewall de transacciones” que convierte los datos en bruto en información estructurada. Se evalúan aspectos como el comportamiento del destino, desviaciones en montos, etc., y las transacciones de alto riesgo se bloquean y requieren aprobación manual.

3. Puerta de visibilidad (Visibility Gate): observación en tiempo real

Se introduce un sistema de monitoreo independiente (Watcher). Cuando los fondos se mueven a una nueva dirección o no vuelven en un plazo determinado, se envía una alerta en segundos. Esto convierte la detección posterior en intervención en proceso, asegurando que, incluso si el Agente intenta ocultar rutas, el estado de los activos sea transparente.

Conclusión

Estamos en una fase de transición peligrosa. La capacidad de ejecución de la IA crece rápidamente, pero nuestros mecanismos de restricción aún son primitivos. Si una arquitectura no puede definir claramente comportamientos prohibidos y verificarlos en tiempo real, cada decisión autónoma de la IA equivale a apostar los activos del usuario en una jugada arriesgada.

Y en el ámbito financiero, nadie quiere apostar.