El 16 de octubre, de madrugada, alguien entró a un sistema heredado de OpenCode — el agente de código open source que compite directo con Claude Code y Cursor — y se quedó ahí intentando sacar algo de valor durante 48 horas seguidas, según su propio cofundador. Lo que sacó fueron llaves de API: credenciales de OpenAI, Anthropic y Google que developers habían guardado en OpenCode Console, la capa hospedada que deja a un equipo compartir acceso a un modelo sin que cada persona vea la llave real. OpenCode reportó que fue 1.4% de los usuarios de Console los afectados — un número que suena pequeño hasta que ves los montos reales: un developer declaró $281 en cargos de OpenAI y $168 en Anthropic, otro calculó pérdidas de $1,700 dólares, y hay reportes de proyectos en Google Cloud suspendidos por exceder presupuesto. Si en tu agencia manejan llaves de API de clientes para correr agentes de código — y la mayoría de las que trabajamos con IA lo hacemos — esto no es una noticia de seguridad ajena. Es un espejo.
Qué pasó exactamente
La cronología, confirmada de forma cruzada por TechCrunch y The Hacker News, es la siguiente: un intruso llegó a un sistema legado de OpenCode la noche del 16 de octubre. La mañana del 17, OpenCode mandó un correo a los usuarios afectados con el asunto "Action Required: Potential provider key breach". Esa misma tarde publicó en X que el incidente seguía abierto. Un día después, el cofundador Dax Raad confirmó que los atacantes llevaban 48 horas intentando entrar a los sistemas de la empresa sin parar.
OpenCode calificó el ataque como relacionado con un "large-scale distillation attack" — es decir, alguien usando las llaves robadas para extraer respuestas masivas de los modelos y entrenar o afinar un modelo propio más barato. La compañía no explicó cómo llegaron al sistema legado, cuántas llaves tenía expuestas, ni desde cuándo había acceso no autorizado. Varios analistas de seguridad señalaron que la conexión con "distillation" es, por ahora, una afirmación sin evidencia pública.
Console sí, CLI y desktop no
Un detalle importante que evitó que este incidente fuera catastrófico: las llaves guardadas localmente por la app de escritorio y la línea de comandos de OpenCode, en una base SQLite en la máquina del usuario, no se vieron tocadas. El problema fue exclusivo de OpenCode Console, el servicio hospedado opcional donde un workspace guarda la llave del proveedor y Console hace las llamadas por el equipo, para que nadie más tenga que verla. Raad lo resumió así: las llaves de Console "nunca nos llegan a nosotros" — pero sí llegaron, de algún modo, a quien entró al sistema legado.
Los números que sí están confirmados
Más allá de las cifras de pérdidas individuales que circularon en redes (no verificadas de forma independiente, pero consistentes entre varios reportes), hay datos que ambas fuentes primarias confirman:
- 1.4% de los usuarios de OpenCode Console tenían un proveedor externo vinculado y fueron notificados por correo — quien no recibió el correo, según la empresa, no estuvo expuesto.
- Las llaves afectadas cubren los tres proveedores grandes: OpenAI, Anthropic y Google, lo que confirma que el vector fue el almacenamiento en Console y no una falla específica de un solo proveedor.
- Anthropic y Google bloquearon las llaves que identificaron como expuestas; OpenAI trabajó con OpenCode para restaurar acceso y reembolsar créditos usados durante el ataque.
Por qué "borrar la llave" no alcanza
Aquí está la parte técnica que casi nadie explica bien cuando habla de este tipo de incidentes: una llave de API es una credencial bearer — quien tiene una copia puede hacer solicitudes facturables hasta que el proveedor, no la herramienta, la revoque. Borrar la llave desde el dashboard de OpenCode Console no la revoca ante OpenAI, Anthropic o Google. Y los límites de presupuesto configurados dentro de Console tampoco sirven de nada si el atacante hace las llamadas directamente contra la API del proveedor, porque Console solo ve el tráfico que pasa por su propia puerta.
Esa es la trampa en la que caen muchos equipos: configuran un límite de gasto en la herramienta que usan todos los días y asumen que están protegidos, cuando el control real vive un nivel más arriba, en el dashboard de cada proveedor.
Lo que esto significa para agencias y developers
Para una agencia de desarrollo que entrega trabajo con agentes de código dentro de la infraestructura — propia o de un cliente — este incidente deja tres prácticas muy concretas:
- Una llave por proyecto, no una llave por agencia. Si cada cliente o cada herramienta tiene su propia llave, una fuga limita el daño a ese proyecto y hace el rastreo de uso indebido mucho más simple.
- Las alertas de gasto se configuran con el proveedor, no solo con la herramienta. Un límite dentro de Cursor, Claude Code o cualquier consola hospedada no protege contra tráfico que nunca pasa por ahí.
- Un protocolo de "vendor comprometido" que se pueda correr en menos de un día. Cuando una herramienta de la que depende tu stack anuncia una brecha, necesitas poder responder en horas — no días — qué llaves de qué clientes tocaban ese vendor, para revocarlas y rotarlas antes de que aparezca el primer cargo inesperado.
Ninguna de las tres cuesta más de una tarde de trabajo implementarla. Cuestan mucho más caro cuando se improvisan después del correo de "Action Required".
OpenCode hizo lo correcto una vez que se dio cuenta: notificó, está reembolsando los cargos no autorizados, y trabajó con los tres proveedores para contener el daño. Pero el incidente confirma algo que en Geek Vibes repetimos seguido a nuestros clientes: la conveniencia de una consola hospedada que esconde la llave de API tiene un costo de seguridad que rara vez se discute antes de adoptarla. Si tu stack de agentes de código guarda llaves de clientes en algún dashboard de terceros, este es un buen momento para auditar quién tiene acceso, revisar si cada proyecto tiene su propia credencial, y confirmar que las alertas de gasto están donde realmente importan. Si quieres que revisemos cómo está configurado el manejo de llaves y presupuestos de IA en tu agencia o tu producto, escríbenos a hello@geekvibes.agency.
