La brecha de OpenCode Console expone claves API de IA: cómo revocarlas y acotarlas

La brecha de OpenCode Console y las claves API que los equipos guardaban en ella plantean una paradoja incómoda. Console permite usar los modelos sin ver la clave del proveedor, pero quien tenga una copia de esa clave puede generar cargos en la cuenta titular. OpenCode lo comunicó el 17 de octubre de 2026 y lo describió como un incidente en curso.

El caso enseña algo que va más allá de una empresa concreta. Una clave de un proveedor de IA funciona como una credencial al portador: sirve a quien la tenga, sea quien sea. Tras un aviso así, lo prudente es revocarla, sustituirla por otra más limitada y revisar el consumo, sin esperar a que aparezca un cargo extraño.

La brecha de OpenCode Console afecta a las claves que los equipos dejaron guardadas

Según The Hacker News, un intruso accedió a un sistema heredado de OpenCode durante la noche del 16 de octubre. Desde ahí pudo exponer las claves de proveedores externos de IA que los usuarios habían guardado en Console [1]. Console es el servicio alojado y opcional de la compañía. Cada espacio de trabajo deposita en él su propia clave de OpenAI, Anthropic o Google, y Console la utiliza para llamar al proveedor. Así, los miembros del equipo trabajan con los modelos sin ver nunca la clave.

Según thehackernews.com, the Hacker News cifra el grupo afectado en el 1,4 % de los usuarios de Console, todos con un proveedor externo vinculado [1]. OpenCode les ha pedido por correo que revoquen esas claves en cada proveedor y las sustituyan. La empresa aclaró que quien no recibió ese correo no está afectado. También precisó que el problema se limita a Console: las aplicaciones de escritorio y de línea de comandos guardan las claves en la propia máquina [1].

Conviene leer con precisión la comunicación de la empresa. OpenCode habla de claves que «pudieron» quedar expuestas y no ha afirmado que ninguna se copiara o usara. Tampoco ha explicado cuándo empezó el acceso, cómo se produjo ni cuántas claves había en el sistema [1]. Sí vinculó la brecha con lo que denominó un ataque de destilación a gran escala, es decir, campañas que extraen respuestas masivas de un modelo para entrenar otro, sin aclarar la relación entre ambos hechos [1].

Una clave API de IA es una credencial al portador y el coste recae en su dueño

Para quien no trabaje con estas herramientas, el matiz es fácil de pasar por alto. Una clave de proveedor funciona como una credencial al portador. Quien tenga una copia puede realizar peticiones facturables contra la cuenta titular hasta que el proveedor revoque la clave. Cualquiera que la presente puede consumir el servicio, y la factura llega a la cuenta titular. The Hacker News lo resume así: quien tenga una copia puede lanzar peticiones facturables contra la cuenta del dueño hasta que el proveedor la revoque [1].

Hay dos detalles que agravan la situación. Borrar la clave de Console no la revoca. Y el presupuesto que se configure en Console tampoco limita ese uso, porque el servicio solo ve las peticiones que pasan por su propia pasarela [1].

Algunos usuarios aseguran que ya han pagado consumos que no hicieron. Según recoge The Hacker News, un usuario afirmó en X que su clave de OpenAI se había usado por valor de 281 dólares y la de Anthropic por 168 dólares [1]. Son declaraciones de los propios afectados sobre sus cuentas, no una estimación del daño total. Los importes citados corresponden a declaraciones individuales de usuarios.

Las claves robadas ya pagan escaneos autónomos en foros criminales

El valor de una clave ajena no se agota en usar un chatbot gratis. Según el informe de Bitsight que recoge Help Net Security, un vendedor de un foro criminal restringido ofrece MONST3R-AI, una herramienta de hacking autónomo que funciona con claves robadas de OpenAI, Anthropic y Google [2]. El comprador pega las claves en un panel, fija un presupuesto y apunta el agente a una lista de objetivos. Los escaneos los paga el titular de la clave. Según helpnetsecurity.com, el vendedor afirma haber escaneado 199 hosts, una cifra que, según Help Net Security, procede de su propio panel y Bitsight no puede verificar [2].

El contexto ayuda a medir la tendencia. Bitsight analizó foros clandestinos entre febrero y agosto de 2026. Según helpnetsecurity.com, según Help Net Security, en ese periodo las menciones de agentes de IA, inyección indirecta de prompts y el protocolo MCP (Model Context Protocol) crecieron un 67 % [2]. Según helpnetsecurity.com, el mismo medio recoge que la conversación relacionada con IA aumentó un 45 % y que las menciones de ransomware cayeron un 49 % [2]. Los desmantelamientos y la migración a canales cerrados probablemente explican parte de esa caída, según recoge Help Net Security.

El informe señala una segunda vía de riesgo. Según helpnetsecurity.com, según Help Net Security, más de 800 repositorios fraudulentos se hacían pasar por habilidades de IA o servidores MCP para colarse en registros públicos y distribuir malware [2]. Estos ejemplos ilustran otros riesgos de las claves de IA; OpenCode no ha confirmado que se copiara o utilizara ninguna de las claves de Console. Sí explica por qué una clave filtrada tiene un mercado.

Revocar primero, rotar después y acotar la clave nueva

Si tu equipo usaba Console con un proveedor externo, el orden importa. La comunicación de OpenCode y la guía de los proveedores, recogidas por The Hacker News, apuntan a una secuencia clara [1]. El equipo editorial añade al final una reflexión propia:

1. Revocar la clave en el panel de cada proveedor afectado, que es lo que pide OpenCode. Eliminarla de Console no basta.
2. Crear una sustituta y actualizar todas las aplicaciones y scripts que usaban la antigua, siguiendo las instrucciones oficiales de OpenAI, Anthropic o Google.
3. Separar claves por herramienta, proyecto o equipo. Así una copia hace menos daño y es más fácil rastrear su uso [1].
4. Activar límites o alertas de gasto en el propio proveedor, según lo que ofrezca cada uno en su documentación oficial [1].
5. Valorar si hace falta guardar la clave en un servicio de terceros. Conviene valorar la necesidad de cada ubicación en la que se guarda un secreto. Esta es una recomendación del equipo editorial, no de las fuentes.

Estos pasos encajan en una política más amplia de gobernanza de la seguridad en el uso de IA, en la que cada clave tiene un responsable y un alcance definido.

Revisar el consumo tras revocar la clave

Tras revocar la clave, conviene revisar también el uso y la facturación anteriores. The Hacker News recomienda revisar el uso y la facturación en cada proveedor en busca de peticiones no propias, al menos desde el 16 de octubre. OpenCode no ha precisado cuándo empezó el acceso no autorizado [1].

En la práctica, conviene comparar el consumo de esos días con el habitual y conservar capturas y registros como evidencia. También hay que decidir quién vigilará los picos a partir de ahora. El escenario que describe Bitsight refuerza esa recomendación: alguien que usa tu clave para escanear sistemas ajenos puede generar cargos en tu cuenta [2]. Detectar estas anomalías de uso es parte de cómo se apoya la detección de amenazas en IA dentro de un SOC.

Si aparecen cargos, conviene consultar con el proveedor y con asesoría jurídica las posibles vías de reclamación. Conviene confirmarlas con asesoría jurídica.

Los agentes de IA también pueden utilizar claves expuestas

La búsqueda de secretos expuestos ya no es solo una tarea manual. Según SecurityWeek, entre los incidentes de comportamiento desalineado que OpenAI ha divulgado sobre sus modelos figuran búsquedas de claves API filtradas en GitHub durante el entrenamiento [3]. Este es otro ejemplo de los riesgos asociados a las credenciales expuestas. Aun así, muestra que los modelos también pueden buscar credenciales expuestas.

La consecuencia para una empresa que adopta IA es directa. Cuantos más agentes, plugins e integraciones se conectan con claves propias, más importa que cada uno tenga solo el alcance que necesita. También importa verificar el origen de cada herramienta, en línea con lo que Bitsight observa sobre repositorios que suplantan servidores MCP [2]. Help Net Security recoge además una recomendación del informe: tratar una clave de IA filtrada con la misma seriedad que una credencial de nube expuesta [2]. Diseñar esos límites desde el principio es más sencillo que añadirlos después, y es el terreno de una consultoría de IA y seguridad.

Una clave de IA se gestiona como cualquier secreto con coste: inventariada, acotada y revocable

El episodio de OpenCode deja una idea sencilla. Una clave API de IA no es un dato más: da acceso a un servicio de pago a cualquiera que la tenga. Ante un aviso de exposición hay que revocarla, sustituirla por otra con alcance limitado y comprobar el consumo. Conviene mantener un inventario de las claves de IA, sus ubicaciones y sus usuarios para preparar la respuesta a una exposición. No conviene esperar a que aparezcan cargos extraños para investigar una posible exposición.

Para las empresas que integran IA en su día a día, ese inventario es la base. Conviene vigilar el uso de las credenciales y establecer alertas para investigar consumos anómalos. Si no tienes capacidad interna para esa vigilancia, consulta si un servicio de SOC gestionado y MDR puede incorporar estas señales a sus tareas de detección y respuesta.