Robo de claves de API y ataques de destilación: cómo proteger las claves de tus herramientas de IA

Una clave de API de un proveedor de IA es una credencial al portador: quien la tiene puede gastar tu dinero y usar tu cuota, y el proveedor no distingue a quien la tiene de ti. Un ataque de destilación es una de las razones por las que alguien quiere muchas claves así. Entrena un modelo más barato con las respuestas de uno más potente y necesita un número muy grande de peticiones de pago. Si las peticiones pasan por claves robadas, las paga otra persona y el tráfico no parece el de un solo cliente. La defensa práctica es limitar lo que puede hacer cada clave, vigilar lo que hace y guardar las claves en el menor número de sitios posible.

El 17 de octubre de 2026 OpenCode comunicó un incidente de seguridad que vinculó con un ataque de destilación a gran escala. Este artículo parte de lo que dijo OpenCode, explica qué es la destilación y por qué las claves son el objetivo, enumera las señales de abuso y da listas de comprobación para quienes usan herramientas de IA y para quienes las construyen. También indica qué hace zn-gate ante este problema y qué no hace.

¿Qué dijo OpenCode que ocurrió?

Solo repetimos lo que OpenCode ha dicho en público. La publicación de OpenCode en X y su aviso a los usuarios afectados se citan abajo tal como los recogen Officechai y Blockonomi, con enlaces. Lo que OpenCode no ha dicho públicamente se marca como no confirmado.

El 17 de octubre de 2026, OpenCode escribió en X: "We had a security breach last night related to a large scale distillation attack that impacted 1.4% of OpenCode Console users" (en castellano: tuvimos una brecha de seguridad anoche, relacionada con un ataque de destilación a gran escala que afectó al 1,4 % de los usuarios de OpenCode Console). La misma publicación, según la cita Blockonomi, dice que los usuarios afectados fueron avisados por correo esa mañana y que "if you did not get an email you were not impacted" (si no recibiste un correo, no te afectó). OpenCode añadió que "it was a subset of users who had external providers" (fue un subconjunto de usuarios que tenían proveedores externos).

El aviso enviado a los usuarios afectados, según lo cita Officechai, dice que OpenCode "identified unauthorized access to a legacy system" (identificó un acceso no autorizado a un sistema heredado) y que "third party provider keys (eg OpenAI, Anthropic) saved in your workspace may have been exposed" (las claves de proveedores externos, por ejemplo OpenAI o Anthropic, guardadas en tu workspace pueden haberse expuesto). Añade que "the incident is ongoing so we cannot share more details at this point" (el incidente sigue en curso, así que no podemos dar más detalles por ahora).

Ese es todo el panorama confirmado. De él se deducen algunas cosas y otras no:

El 1,4 % es una parte de los usuarios de OpenCode Console, no de todos los que usan el agente de código de código abierto OpenCode. La documentación de OpenCode describe la Console como el lugar donde añades los datos de facturación y el crédito y copias tu clave de API, y dice que los propietarios y administradores del workspace pueden conectar sus propios proveedores.
Según el aviso, las claves en riesgo son claves de proveedores externos guardadas en un workspace.
OpenCode no ha publicado cómo entraron los atacantes, cuánto tiempo tuvieron acceso, cuántas claves se usaron ni qué modelos se llamaron. Todo lo que leas en otro sitio sobre esos puntos es una hipótesis.

Usamos OpenCode todos los días, en las versiones oficiales y en compilaciones que adaptamos a nuestra propia configuración, y confiamos en el producto. No tenemos ninguna relación comercial con el equipo de OpenCode. Escribimos sobre el incidente porque muestra un patrón que deben prever todos los proveedores de herramientas de IA y todos sus usuarios, y porque el equipo ha sido transparente mientras la investigación sigue abierta. No sabemos más de lo que ellos han dicho y no especulamos sobre sus sistemas.

¿Qué es un ataque de destilación y qué es la extracción de modelos?

La destilación es "training a less capable model on the outputs of a stronger one" (entrenar un modelo menos capaz con las salidas de uno más potente), en palabras de la publicación de Anthropic sobre ataques de destilación. La técnica es legítima y antigua. Hinton, Vinyals y Dean la describieron en 2015 en Distilling the Knowledge in a Neural Network como una forma de comprimir un conjunto de modelos en uno más pequeño y barato de ejecutar. Los proveedores destilan sus propios modelos para ofrecer versiones más pequeñas y baratas a sus clientes.

El abuso consiste en destilar el modelo de otro sin permiso. La publicación de Anthropic dice que los competidores lo usan para adquirir capacidades "in a fraction of the time, and at a fraction of the cost" (en una fracción del tiempo y del coste) de desarrollarlas, y que los modelos creados así difícilmente conservan las salvaguardas originales. En esa publicación Anthropic informa de tres campañas que juntas generaron más de 16 millones de intercambios con Claude a través de unas 24.000 cuentas fraudulentas y dice que las campañas ilícitas se reconocen por el patrón: "massive volume concentrated in a few areas, highly repetitive structures" (volumen masivo concentrado en pocas áreas, estructuras muy repetitivas).

Una idea relacionada es la extracción de modelos. En Stealing Machine Learning Models via Prediction APIs (USENIX Security 2016), Tramèr y sus coautores muestran que quien solo tiene acceso para consultar un modelo puede copiar su comportamiento con gran fidelidad, y que quitar los valores de confianza de las salidas no basta para impedirlo. El artículo trata de modelos clásicos, no de grandes modelos de lenguaje, pero la lección se mantiene: si puedes consultar un modelo lo suficiente, su comportamiento se puede copiar a partir de sus respuestas.

Ninguna de las dos técnicas necesita acceso a los pesos. Necesitan volumen. Ahí entran las claves.

¿Por qué usan los atacantes claves de API robadas para esto?

Hay dos razones y ambas tienen que ver con el coste y la visibilidad.

Paga la víctima. Una ejecución de destilación necesita muchas peticiones y el proveedor factura cada una. Con una clave robada, la factura va al dueño de la clave. El coste del atacante se reduce al esfuerzo de reunir claves.

El rastro se reparte. Un proveedor que ve una cuenta enviando millones de peticiones repetitivas puede detectarlo, como describe Anthropic, con clasificadores, huellas de comportamiento y herramientas que detectan actividad coordinada entre muchas cuentas. Si el mismo volumen se reparte entre cientos de claves de clientes distintos, cada clave envía una cantidad pequeña de tráfico de aspecto normal. La vista del proveedor sobre cualquier cuenta concreta parece corriente y el patrón solo aparece al mirar muchas cuentas juntas. La detección en el lado del proveedor es difícil por esta razón, y el dueño de la clave puede ser la primera persona que puede ver que algo va mal, porque solo él sabe cuál es su uso normal.

El resultado es que el dueño de la clave tiene un interés en vigilarla que nadie más tiene.

¿De dónde salen las claves robadas?

Las claves se filtran desde los sitios donde se guardan. En la práctica, los más comunes son estos:

Lugar	Cómo puede salir una clave de allí
Ficheros `.env` y perfiles de shell	Subidos a un repositorio por error, leídos por un script, una copia de seguridad o una dependencia, o leídos por un agente de código que luego los envía a su proveedor de modelo
Configuración de herramientas y editores	Una clave pegada en un fichero de ajustes que se sincroniza, se comparte o se incluye en un informe de error
Registros de CI y artefactos de compilación	Una clave impresa por una línea de depuración o copiada en un artefacto que otros pueden descargar
Chat, tickets y documentación	Una clave pegada para pedir ayuda y que se queda allí
Consolas y paneles de terceros	Una clave que guardaste en un servicio para que llame a un proveedor por ti. La clave es entonces tan segura como ese servicio

La última fila es la que señala este incidente. Cuando guardas una clave de proveedor en la consola de otra empresa, sumas la seguridad de esa empresa a la seguridad de la clave. Puede ser un buen intercambio, porque un servicio con un equipo detrás puede proteger una clave mejor que un portátil. También significa que un fallo en ese servicio puede exponer claves de clientes que hicieron todo bien en sus propias máquinas.

Este artículo no describe cómo se explotan estas fugas y no vamos a hacerlo. Las defensas no dependen de ello.

¿Cómo puedes saber que una clave se está usando mal?

Las señales aparecen en el lado del proveedor, así que el panel de cada proveedor es donde mirar. Busca:

Un gasto que sube sin que haya cambiado tu trabajo. Un salto entre dos días, o un aumento constante a una hora en que nadie trabaja.
Modelos que no usas. Si solo llamas a un modelo y la página de uso muestra otro, la clave la está usando otra persona.
Uso a horas extrañas o en volúmenes extraños, como una tasa alta y plana toda la noche.
Uso por clave que no se corresponde con la función de la clave. Una clave creada para una herramienta que muestra tráfico cuando esa herramienta está cerrada.
Cargos inesperados o llegar a un límite que no esperabas alcanzar.
Avisos del proveedor. Los proveedores también detectan abusos y pueden escribirte o desactivar una clave.

Ninguna de estas señales prueba el robo por sí sola. Cada una es un motivo para comprobar. La forma más barata de hacerlas visibles es configurar alertas antes de necesitarlas.

¿Cómo proteges tus claves como usuario?

El objetivo es que una clave robada pueda hacer poco daño, durante poco tiempo, y que lo notes pronto. Estas medidas funcionan juntas:

Usa una clave por herramienta y por finalidad. Cuando una clave se filtra sabes de dónde, puedes revocarla sin romper todo lo demás y su página de uso cuenta una historia clara. Los proveedores agrupan las claves en proyectos o workspaces, y es una buena forma de separar entornos. Las buenas prácticas de producción de OpenAI recomiendan proyectos separados para staging y producción, lo que también permite límites de uso y de gasto distintos para cada uno.
Fija límites de gasto y alertas. La documentación de OpenAI describe alertas que te avisan cuando el uso supera un importe en dólares y límites duros que detienen el tráfico cuando el gasto llega al límite. El límite duro es el control que convierte una pérdida sin tope en una pérdida acotada. Ponlo más bajo de lo que crees necesitar y súbelo cuando lo alcances.
Dale caducidad a las claves y rótalas. OpenAI recomienda fijar una fecha de caducidad al crear una clave de proyecto y tener un proceso de rotación periódico: crear una sustituta, actualizar tus aplicaciones, comprobar que funciona y revocar después la clave antigua. La documentación de Google recomienda rotar las claves periódicamente, dice que las claves de API sin restricciones son inseguras y recomienda restringir cada clave a las API que necesita.
Revoca, no te limites a sustituir, ante cualquier duda. Si una herramienta que usas comunica un incidente y no estás seguro de si tu clave se vio implicada, revoca la clave. Crear una nueva lleva un minuto. Después mira el uso de la clave antigua en los días anteriores a revocarla.
Mantén las claves fuera del código, los repositorios y los registros. Usa variables de entorno o un gestor de secretos, como recomienda OpenAI, y mantén .env fuera del control de versiones.
No guardes una clave en la consola de un tercero salvo que el servicio la necesite. Si la herramienta se ejecuta en tu máquina, la clave puede quedarse en tu máquina. Si el servicio tiene que llamar al proveedor por ti, usa una clave hecha solo para eso, con su propio proyecto, un límite de gasto y una caducidad.
Revisa de vez en cuando la lista de claves. Borra las claves de herramientas que ya no usas. Las consolas de los proveedores muestran cuándo se creó cada clave y algunas muestran cuándo se usó por última vez. La Admin API de Anthropic, por ejemplo, expone el estado, la fecha de creación y la caducidad de cada clave y nunca devuelve el secreto.

¿Qué deben hacer quienes crean herramientas de IA?

Si tu producto guarda claves que pertenecen a tus clientes, has asumido un deber que el portátil de un usuario no tiene, y el diseño debería reflejarlo.

Cifra las claves guardadas con un servicio de claves gestionado, como un KMS en la nube, con controles de acceso que separen a las personas y los servicios que pueden descifrar de los que solo ejecutan el producto. Guarda solo lo que necesitas para llamar al proveedor.
Aplica el mínimo privilegio entre tus componentes. La parte del sistema que llama a un proveedor debería poder leer las claves que necesita para la petición que tiene delante, no todo el almacén.
No muestres una clave de nuevo después de guardarla. Muestra una pista, como los últimos caracteres, y deja que el usuario la sustituya. Los objetos de clave de la Admin API de Anthropic funcionan así, con una pista parcial y sin el secreto.
Aplica cuotas por clave y comprobaciones de anomalías de tu lado. Ves el tráfico de todos tus clientes antes que ningún cliente por separado. Una clave que de pronto hace miles de peticiones con la misma forma merece una pausa y una pregunta.
Retira los sistemas antiguos. El código y los almacenes de datos que siguen accesibles pero ya no están en uso activo tienden a recibir la menor revisión. Elimínalos o mantenlos bajo los mismos controles que el sistema en producción.
Facilita la rotación. Si revocar y sustituir una clave es un procedimiento largo, los usuarios no lo hacen.
Avisa a los clientes pronto y con claridad, diciendo qué hacer después. Un mensaje corto que indique qué usuarios están afectados y qué deben rotar permite actuar antes de que termine la investigación.

¿Qué hace zn-gate ante esto y qué no hace?

zn-gate es una capa de seguridad de código abierto que se ejecuta en tu máquina, entre tu agente de código y las herramientas y contenidos que toca. Ayuda con la parte del problema que está en tu máquina. No ayuda con la parte que está en la nube de otra persona. Indicamos las dos para que no dependas de él para algo que no hace.

Lo que hace. Estas afirmaciones están en el README de zn-gate y en la documentación de Scrubber y vault de secretos:

Con el plugin de Claude Code, o los hooks de zn para Codex CLI, Cursor y OpenCode, se impide que el agente de código lea ficheros .env que contienen valores reales y ficheros de credenciales como ~/.aws/credentials. Es una barrera de protección, no un sandbox.
Los secretos en lo que devuelven las herramientas del agente, como lecturas de ficheros y salida de comandos, se sustituyen por marcadores antes de que los vea el modelo, y se bloquea un secreto pegado en un prompt. En Cursor solo se limpia la salida de las herramientas MCP.
zn env shadow .env mueve tus valores a un vault cifrado en tu máquina y deja marcadores como __ZN_STRIPE_KEY__ en el fichero. El vault es local y no se sincroniza.
Una clave se puede usar sin que el modelo la vea. Un comando que has permitido recibe el valor mediante zn run, y su salida se enmascara. Para las API HTTP, el servidor MCP secrets envía el valor solo a los hosts que has permitido y devuelve la respuesta con los secretos sustituidos por marcadores. Ninguna herramienta devuelve un valor al agente.

Lo que no hace.

No protege una clave guardada en la nube de un tercero. En el caso de arriba, las claves en riesgo eran las guardadas en un workspace de una consola alojada. zn-gate no está en el camino entre ese servicio y el proveedor, así que no puede reducir esa exposición. Solo el servicio y tú, limitando y rotando esa clave, podéis hacerlo.
No sustituye los límites de gasto, las alertas ni la rotación. Son tus controles en el proveedor.
No detiene un proceso que arrancas tú mismo, ni un malware que se ejecute como tu usuario. Su modelo de amenazas dice que cualquier programa que se ejecute como tu usuario del sistema operativo puede pedir un secreto por su nombre a un vault desbloqueado, y recomienda bloquear el vault con zn lock cuando no lo uses.
Un comando que has permitido sigue teniendo el valor mientras se ejecuta. zn controla adónde va una credencial, no lo que hace con ella un programa permitido.
No detecta un ataque de destilación. El tráfico en el lado del proveedor queda fuera de lo que ve.

Lo que zn-gate elimina es una fuente habitual de fugas: la clave que está en texto plano en un fichero .env donde un agente o una inyección de prompt pueden encontrarla. Una dependencia comprometida que se ejecuta como tu usuario es otro caso: consulta el modelo de amenazas de arriba. Mantener una clave fuera del alcance del agente en tu máquina es útil, y es una medida más entre las enumeradas arriba.

¿Qué lista de comprobación puedes usar hoy?

Para usuarios:

Cada herramienta tiene su propia clave, en su propio proyecto o workspace.
Cada clave tiene un límite de gasto y una alerta con un importe menor.
Cada clave tiene fecha de caducidad y sabes cuándo la rotarás.
Sabes dónde está guardada cada clave: entorno local, vault, secreto de CI o consola de un tercero.
Las claves en consolas de terceros son solo las que el servicio necesita, con un límite.
Los ficheros .env no están en el control de versiones y el agente de código no puede leerlos (npx -y zn-gate check).
Miras el uso por clave al menos una vez por semana, y tras cualquier aviso de incidente de un proveedor de herramientas.
Las claves sin uso están borradas.
Si un proveedor comunica un incidente que puede afectarte: crea una clave nueva, actualiza la herramienta, revoca la antigua y revisa su uso.

Para quienes construyen herramientas:

Las claves de los clientes se cifran con un servicio de claves gestionado, con permisos de descifrado estrechos.
Una clave no se vuelve a mostrar después de guardarla.
Hay cuotas por clave y alertas de anomalías de tu lado.
Los sistemas y almacenes antiguos están retirados o cubiertos por los mismos controles.
Existe un procedimiento probado para avisar a los clientes y rotar todas las claves guardadas.

¿Qué no cubre este artículo?

No describe cómo ocurrió el incidente de OpenCode más allá de lo que dijo OpenCode, porque no es público.
No da ningún método para robar claves ni para llevar a cabo una campaña de destilación.
No cubre la detección en el lado del proveedor más allá de lo que los proveedores han publicado.
No cubre claves de servicios que no son proveedores de IA, aunque la mayoría de los consejos les sirven.

Preguntas frecuentes

¿Qué es un ataque de destilación?

Entrenar un modelo menos capaz con las salidas de uno más potente. Anthropic describe la destilación ilícita como el uso que hacen competidores para adquirir capacidades en una fracción del tiempo y del coste que costaría desarrollarlas. Exige un número muy grande de peticiones al modelo más potente.

¿Por qué un atacante robaría claves de API para un ataque de destilación?

Porque las peticiones hay que pagarlas y tienen que salir de algún sitio. Con una clave robada, quien paga la factura es su dueño, y el tráfico se reparte entre muchas cuentas en lugar de una sola cuenta que el proveedor pueda detectar y bloquear.

¿Cómo sé si mi clave de un proveedor de IA se está usando mal?

Busca un gasto que sube sin que haya cambiado tu trabajo, peticiones a modelos que nunca usas, uso a horas en que nadie trabaja o tráfico de herramientas que no reconoces. Las alertas de gasto y las vistas de uso por clave son las primeras señales.

¿Qué hago si una herramienta que uso sufrió una fuga de claves?

Crea una clave nueva, actualiza la herramienta que la necesita, revoca la antigua y revisa después el uso de la clave antigua en el periodo anterior a la revocación. Hazlo aunque no estés seguro de que tu clave se viera afectada.

¿zn-gate protege una clave que guardé en la consola en la nube de un tercero?

No. zn-gate se ejecuta en tu máquina y evita que el agente de código lea tus ficheros .env y de credenciales, mantiene los valores secretos fuera de lo que ve el modelo y puede usar una clave de un vault local sin mostrársela al modelo. Una clave que pegaste en el servicio de un tercero queda fuera de su alcance.

¿Debo guardar mis claves de proveedor en la consola en la nube de una herramienta?

Solo si la herramienta las necesita para ejecutar un servicio por ti. Si puede funcionar en tu máquina con la clave en tu propio entorno o en un vault local, es un sitio menos que proteger. Si la guardas allí, ponle un límite de gasto y usa una clave que sirva solo para ese fin.

¿Cada cuánto debo rotar las claves de API?

La guía de OpenAI recomienda fijar una fecha de caducidad al crear una clave de proyecto y tener un proceso de rotación periódico. La frecuencia depende del daño que pueda hacer una sola clave: una clave con un límite de gasto bajo puede rotarse con menos frecuencia que una sin límite.

Para lo básico sobre cómo mantener un .env fuera del alcance de un agente, consulta cómo impedir con un solo comando que Claude Code, Codex CLI, Cursor y OpenCode lean tu .env. Para ver cómo se puede eludir un hook de agente y cómo se corrigió, lee cómo un agente de código podía leer tu fichero .env de forma indirecta. zn-gate tiene licencia MIT, se ejecuta en local y no necesita cuenta: GitHub e Install.