La herramienta que uso todos los días anunció, en la noche del viernes, que fue hackeada. Las credenciales que se filtraron eran de los usuarios.
El comunicado oficial describe el incidente: acceso no autorizado a un sistema legado que OpenCode estaba desactivando. Ahí estaban las llaves de proveedores (OpenAI, Anthropic, Google) guardadas en la consola, el servicio hospedado en que el equipo usa los modelos sin nunca ver la llave. La orientación oficial fue directa: revocar y sustituir las llaves en los paneles de los proveedores, actualizar las aplicaciones que las usan y revisar el uso reciente por actividad extraña.
El escopo confirmado
1,4% de los usuarios de la consola, todos con proveedor externo vinculado. La empresa avisó a ese grupo por email en la mañana del sábado, con el asunto Action Required: Potential provider key breach, y el recado oficial es este: quien no recibió el email no fue afectado. Las llaves en riesgo son las pegadas en la consola; las del cliente de línea de comando y del desktop quedan en banco local, en tu máquina.
Los atacantes no quedaron en modo lectura
Según TechCrunch, corrieron cargas en las cuentas de IA de los usuarios y generaron costo. La lectura del mercado de seguridad es de destilación: inferencia con llave ajena para cosechar salidas y entrenar con ellas.
Es el detalle que separa filtración de credencial de filtración de dato: la llave robada sigue trabajando después del incidente, en tu cuenta, en tu factura. Por eso la respuesta empieza en la revocación, pero no termina en ella.
La lección queda en la dirección de la llave
Quien guarda la credencial en la consola de un proveedor hereda el incidente del proveedor, y la factura del incidente llega al dueño de la llave. El perímetro del agente se llama credencial, y el caso de esta semana mostró que a veces ella vive en casa ajena.
Es el mismo diseño que documentamos en el caso PocketOS: el agente usó la autoridad que recibió, y lo que faltó fue IAM. Aquí la autoridad ni era tuya: estaba hospedada en una consola de tercero que fue comprometida. Y la cadena de confianza de herramientas de agente es el mismo vector que la campaña TrapDoor exploró en archivos de configuración.
Lo que recomiendo, en este orden
- Revocar toda llave que esté guardada en consola de tercero y emitir una nueva, directamente en el proveedor.
- Revisar factura y logs de uso por actividad que no reconozcas.
- Adoptar el patrón que sobrevive al próximo aviso: llave de agente es revocable, tiene techo de gasto y nunca es la única.
En Tech86, inventario de credenciales es el primer trabajo de gobernanza de agente: dónde vive cada llave, qué puede hacer, cuándo se vuelve basura.
Conclusión
Para quien opera agente con llave de proveedor, el caso deja una regla: la llave vive en tu cofre o vive en la factura de alguien. El próximo comunicado de violación es cuestión de tiempo; el inventario es lo que decide si llega como aviso o como perjuicio.