La brecha de OpenCode muestra que en la era de los agentes el eslabón débil es el sistema heredado donde se guardan las claves

Por Startup Fortune · 17 de octubre de 2026.

Anomaly Innovations, la empresa antes conocida como SST y desarrolladora del agente de programación de código abierto OpenCode, ha avisado por correo a sus usuarios de que las claves de API de terceros (OpenAI, Anthropic y Google) guardadas en sus espacios de trabajo pueden haber quedado expuestas. Según la propia compañía, el incidente afecta a cerca del 1,4% de los usuarios de OpenCode Console, solo a quienes tenían proveedores externos vinculados a su cuenta.

La empresa atribuye el suceso a un «ataque de distillation a gran escala» y, según el mensaje que cita la fuente, habría detectado acceso no autorizado a un «sistema heredado» (legacy) que se estaba desmantelando. Dice trabajar con Anthropic, OpenAI y Google para remediarlo, que el incidente sigue en curso y que, hasta ahora, no ha hallado indicios de fuga de otros datos. Tampoco puede confirmar si las claves se usaron de forma maliciosa.

Hay indicios en sentido contrario, aunque no verificados: según la fuente, algunos usuarios dicen haber visto cargos de «cientos de dólares» por consultas que no hicieron, antes incluso del primer aviso. Otros afirman en X que Google suspendió su proyecto en la nube o que OpenAI les cerró la cuenta. Son testimonios individuales sin confirmar. Ni siquiera hay acuerdo sobre si los correos salieron el día 17 o el 18.

La terminología es lo que más se discute. La distillation consiste en entrenar un modelo con las respuestas de otro. Un «ataque de distillation» sería, en principio, lanzar consultas masivas contra un modelo para copiar su comportamiento, algo que un atacante podría hacer con claves robadas. Pero eso no explica cómo se obtuvieron las claves. El investigador Nathan Lambert preguntó públicamente si se trata de distillation para entrenar otros modelos o de un uso ilegítimo de tokens obtenidos ilícitamente. Ambas cosas pueden ser ciertas a la vez, pero la empresa no ha confirmado esa secuencia.

Quedan sin responder cuántas cuentas son ese 1,4%, cómo entraron los atacantes, cuándo se detectó el acceso y si las claves guardadas en archivos de configuración locales, y no en la Console, también se vieron afectadas.

La recomendación es la de cualquier respuesta a incidentes. Hay que revocar y regenerar las claves desde los paneles de cada proveedor, sin pulsar enlaces del correo. También conviene revisar el consumo desde el 17 de octubre y fijar límites de gasto. Para un desarrollador en solitario o una startup con OpenCode en producción, esto implica tocar cada pipeline, cada tarea de integración continua y cada equipo local.

**Nuestra lectura.** La tesis es sencilla: un agente de código con tus credenciales es tan seguro como el sistema menos mantenido de su proveedor. La documentación de OpenCode ya advertía, según la fuente, de que no aísla (sandbox) al agente y de que sus avisos de permisos son una comodidad de uso, no una barrera de seguridad. Pero esa advertencia protege frente al agente, no frente a una filtración en la trastienda del vendedor. Aquí el fallo no estuvo en el modelo ni en el criterio del desarrollador, sino en un sistema que seguía vivo mientras se apagaba.

En general, la industria ha cableado agentes a cuentas de facturación sensibles con más prisa que higiene. La consecuencia a corto plazo es incómoda: rotaciones de claves, facturas inesperadas y desconfianza. Es el precio de una transición rápida. Encaja con una idea que venimos defendiendo: el modelo se abarata y el riesgo real se mueve a la capa de identidad y permisos. Las claves de larga duración almacenadas por terceros son el patrón a erradicar, a favor de credenciales efímeras, de alcance limitado y con tope de gasto.

También hay una lección de comunicación. Llamar «ataque de distillation» a lo que, por lo que se sabe, es primero una exposición de claves invierte el orden de lo que le importa al usuario. Retener detalles durante una investigación activa es razonable. Pero un seguimiento claro, con alcance, causa y coste para los usuarios, restauraría más confianza que una lista de socios.

A largo plazo, el balance sigue siendo optimista: estas fricciones empujan hacia una infraestructura de agentes más madura, con identidades verificables y permisos mínimos. Esa base es la que hará falta para delegar en la IA trabajo de verdad, y no solo tareas de prueba.