Brecha de OpenCode: protege tu API key con Synthorai Trusted IPs

El 17 de octubre de 2026, OpenCode informó a sus usuarios de que un intruso había accedido a un sistema antiguo de OpenCode Console, su servicio alojado, y de que las claves de proveedores externos guardadas allí «podrían haber quedado expuestas». Después, varios usuarios denunciaron cargos de entre unos cientos de dólares y $1,700 en sus cuentas de OpenAI, Anthropic y Google. Una clave de proveedor es la clave de API que obtienes de OpenAI o Anthropic. Guardarla en una herramienta alojada para que esta pueda llamar al proveedor por ti se conoce como BYOK (bring your own key). El coste de una filtración depende de dos cosas: desde dónde se puede usar la clave y cuánto puede gastar antes de que algún control la bloquee.

TL;DR

• Según OpenCode, la brecha de Console afectó al 1.4% de sus usuarios. Las claves guardadas por la CLI local de OpenCode no se vieron afectadas.
• Las reglas de IP y los límites de gasto de un gateway solo controlan el tráfico que pasa por él. Una clave de proveedor filtrada necesita un límite estricto en el propio proveedor.
• Con la opción “Aprobación de IP nuevas” activada, Synthorai rechaza las llamadas de una clave de API desde cualquier dirección no aprobada para esa clave y devuelve HTTP 403 con ip_not_trusted.
• Cada clave de Synthorai puede tener un límite de gasto, límites de solicitudes y tokens por minuto y una fecha de caducidad.

¿Qué ocurrió en la brecha de OpenCode Console?

Un tercero no autorizado accedió a «un sistema antiguo que estábamos retirando», según el correo que OpenCode envió a los usuarios afectados. Las claves de proveedores guardadas en sus espacios de trabajo de Console podrían haberse leído. OpenCode situó el primer momento posible de exposición el 17 de octubre a las 00:30 UTC. Esta es la cronología, según las publicaciones de OpenCode, las de empleados de los proveedores y la cobertura de prensa:

Un ataque de destilación consiste en recopilar respuestas de un modelo a gran escala para entrenar otro. Las claves robadas son una de las formas de financiar esas llamadas. OpenCode no ha explicado qué relación tiene la brecha con la destilación. Su cofundador Dax Raad afirmó que la brecha afectaba a «OpenCode Console, no a OpenCode en sí», y que las claves añadidas en la CLI local nunca llegan a la empresa. A fecha de 21 de octubre, OpenCode no había publicado la causa raíz, si las claves almacenadas estaban cifradas, cuántas cuentas representaba ese 1.4%, una política de reembolso ni un análisis del incidente (The Hacker News, BleepingComputer).

¿Qué claves quedaron expuestas y qué controles sirven?

Las claves expuestas eran claves de proveedores. Una clave de proveedor robada se usa directamente contra el proveedor, sin pasar por la herramienta que la guardaba. Eso limita lo que puede hacer un gateway de LLM. El gateway es un servicio que se sitúa entre tu código y los proveedores de modelos y reenvía las solicitudes. Solo puede ver y limitar el tráfico que pasa por él. Conviene distinguir los dos tipos de clave:

Trusted IPs y los límites de gasto, que se describen en las dos secciones siguientes, protegen el primer caso. Para el segundo, la última barrera es el límite estricto que configures en OpenAI, Anthropic o Google. La sección posterior recoge esos ajustes.

¿Cómo protege Synthorai las claves de la plataforma y las claves BYOK?

Las claves de proveedores que añades a BYOK Vault se cifran en reposo con AES-256-GCM, un algoritmo estándar de cifrado autenticado. Una vez guardadas, ninguna API, herramienta MCP ni página de la consola vuelve a mostrarlas: la consola solo enseña los últimos cuatro caracteres. El gateway descifra cada clave únicamente en memoria y para la solicitud que la necesita. Solo el propietario del espacio de trabajo puede añadirla, rotarla o eliminarla. Las claves de proveedores que Synthorai usa para ofrecer su propia capacidad se almacenan del mismo modo. No aparecen en ninguna página de la consola ni en ninguna API, tampoco en la consola de administración. El cifrado protege las copias de la base de datos; si se compromete el servicio en ejecución, sigue siendo posible acceder a las claves mientras se usan. Por eso, el límite del proveedor que se describe más adelante es la última barrera para las claves BYOK.

Las claves de API que Synthorai te entrega se almacenan únicamente como un hash, una huella unidireccional que no permite recuperar la clave. La clave completa solo se muestra al crearla. Cualquier consulta posterior, desde la consola, la API de gestión o el servidor MCP, devuelve únicamente su prefijo. Una clave de inferencia solo permite llamar a modelos: la API de gestión la rechaza, así que quien robe una no podrá consultar logs, datos de uso ni otras claves (API keys, admin keys).

¿Cómo bloquea Trusted IPs una clave filtrada?

Trusted IPs rechaza las llamadas de una clave de API desde cualquier dirección que no esté aprobada para ella. Si alguien copia una clave de un log de CI o de un portátil y la usa desde otra dirección, recibe un error en lugar de una respuesta. Un propietario o administrador puede activarlo en Configuración › Seguridad con la opción “Aprobación de IP nuevas”. El diálogo muestra las direcciones desde las que se ha usado cada clave en los últimos siete días, todas marcadas para su aprobación. Revisa la lista antes de confirmar y desmarca las direcciones que no reconozcas: si la clave ya se ha filtrado y alguien la ha usado, la dirección del atacante también aparecerá.

A partir de entonces, una llamada desde una dirección nueva devuelve HTTP 403 (la dirección de este ejemplo está reservada para documentación):

{
  "error": {
    "type": "permission_error",
    "code": "ip_not_trusted",
    "ip": "203.0.113.9",
    "message": "Requests from IP address 203.0.113.9 are held until this address is approved for the key. ...",
    "approve_url": "https://synthorai.io/console/settings?tab=security"
  }
}

Quien creó la clave recibe un correo con la dirección, su ubicación, el cliente y el modelo solicitado. La aprobación se realiza en la consola después de iniciar sesión, así que reenviar el correo no aprueba nada. Se puede aprobar una dirección o su rango /24 (256 direcciones IPv4 contiguas) para clientes cuya dirección cambia. El gateway obtiene la dirección del cliente de la conexión tal como la ven sus propios proxies. El cliente no puede suplantar otra dirección enviando su propia cabecera X-Forwarded-For, que los proxies usan para transmitir la dirección original del cliente. Lo comprobamos con una cabecera falsificada y el rechazo siguió indicando la dirección real.

# From an address not yet approved for the key, with a forged header:
curl -s https://synthorai.io/v1/models \
  -H "Authorization: Bearer $SYNTHORAI_API_KEY" \
  -H "X-Forwarded-For: 203.0.113.9"
# The 403's "ip" field is the caller's real address, not 203.0.113.9.

También puedes crear una clave con una ip_allowlist fija, pero esa lista forma parte de la configuración de la clave: cada nueva oficina, servidor o salida de VPN obliga a editarla, y cualquier entrada olvidada sigue dando acceso. Trusted IPs parte de las direcciones desde las que ya se usa una clave, pide aprobación antes de confiar en una nueva y reúne las direcciones de todas las claves en una sola lista, donde puedes aprobar una dirección conocida con un clic. Si una clave tiene su propia lista de permitidos, solo se aplica esa lista. Usa una opción u otra para cada clave.

La confianza se configura por clave. Las funciones serverless y los runners de CI que usan una dirección nueva en cada ejecución quedarían pendientes de aprobación cada vez. No marques como fiables los rangos que publica un proveedor de CI alojado: los comparten todos sus clientes, así que cualquiera que ejecute un job allí pasaría el control. Encauza esas llamadas por una dirección de salida fija, mediante un runner propio o un gateway NAT, y aprueba esa dirección. Otra opción es darles una clave de corta duración y con un límite bajo.

¿Cómo limitan los topes de gasto el coste de una clave robada?

Cada clave de API de Synthorai puede tener su propio límite de gasto. Si acaba filtrándose, dejará de funcionar al alcanzar la cantidad que hayas elegido. Al crearla en la consola, puedes configurar el límite, los modelos permitidos y la caducidad:

Los límites de frecuencia por clave y el resto de los ajustes siguientes se configuran mediante la API de gestión:

Este ejemplo crea una clave para un único servicio, limitada a sus necesidades, mediante una clave de administrador (una clave de gestión que puede crear y limitar claves, pero no llamar a modelos):

curl https://synthorai.io/api/v1/keys \
  -H "Authorization: Bearer sk-syn-admin-..." \
  -H "Content-Type: application/json" \
  -d '{
    "name": "support-bot prod",
    "limit_usd": 50,
    "limit_reset": "daily",
    "rate_limit": {"rpm": 60, "tpm": 200000},
    "allowed_models": ["claude-haiku-5-5"],
    "expires_at": "2027-01-31T00:00:00Z"
  }'

Los propietarios de espacios de trabajo también pueden fijar un tope de gasto diario y mensual por miembro. Cuando un miembro alcanza el tope mensual, recibe HTTP 402 hasta el mes siguiente. Estos límites se aplican al tráfico que pasa por Synthorai. Si las llamadas BYOK cuentan para el límite, también cubren las solicitudes BYOK realizadas a través del gateway, pero no el uso directo de una clave de proveedor filtrada.

¿Qué no bloquean estos controles?

Trusted IPs bloquea el uso de una clave desde una dirección nueva, pero no interviene si se usa desde un equipo de confianza. Los robos más habituales ocurren precisamente ahí: malware en el portátil de un desarrollador, un job de CI comprometido o un servidor al que se engaña para que envíe solicitudes por cuenta de un atacante. En esos casos, lo que limita el daño es el tope de gasto de la clave, su lista de modelos y una caducidad corta.

La aprobación depende de una persona. Un atacante puede provocar una solicitud pendiente y esperar que alguien la apruebe por costumbre. La página de aprobación muestra la dirección, su ubicación, el cliente y el modelo. Aprueba solo si esos datos corresponden a una llamada que hayas hecho.

Un límite que se restablece a diario permite que una clave robada gaste esa cantidad cada día hasta que alguien lo detecte. Combina los límites con mecanismos de detección: el correo por cada dirección pendiente de aprobación, el gasto por clave en la consola y el registro de auditoría de los cambios en las claves. Si sospechas que una clave se ha filtrado, elimínala en la consola y crea otra. Para detectar claves antes de que se filtren, añade en la plataforma donde alojas el código un patrón de detección de secretos para el prefijo sk-syn-, por ejemplo un patrón personalizado de GitHub con protección de push.

¿Qué debes configurar en el proveedor para una clave BYOK?

Asigna a cada herramienta su propia clave de proveedor, dentro de un proyecto o espacio de trabajo independiente y con un límite estricto de gasto. Así, una clave filtrada solo podrá consumir el presupuesto de ese proyecto. Revoca la clave filtrada en el panel del proveedor: borrarla de la herramienta que la guardaba no la revoca. Ninguno de los tres proveedores permite fijar límites para una sola clave; la unidad mínima es el proyecto o el espacio de trabajo:

Las alertas de gasto y los presupuestos que solo envían correos no detienen un ataque en curso. Sirven como segunda señal, además de un límite estricto. La página BYOK de la consola de Synthorai incluye, debajo de las claves, enlaces a los ajustes de límites de cada proveedor:

¿Se puede usar OpenCode con Synthorai?

Sí. Las claves que usa la CLI local de OpenCode se quedan en tu equipo, una configuración que no se vio afectada por la brecha. opencode auth login https://synthorai.io inicia sesión en OpenCode a través del navegador con un código de un solo uso. OpenCode recibe una clave de API propia que caduca a los 7, 30 o 90 días (guía de configuración). Si “Aprobación de IP nuevas” está activado y autorizas el inicio de sesión desde la misma red, la dirección desde la que inicias sesión se aprueba automáticamente para esa clave. Las llamadas desde cualquier otra dirección quedan pendientes de aprobación. Si la solicitud de inicio de sesión procede de una red distinta a la del navegador, la página de confirmación te avisa y la dirección no se considera de confianza hasta que apruebes su primera llamada. Si no has ejecutado tú el comando, cancela la solicitud.

La clave aparece como «OpenCode» en la página de claves de API, donde puedes añadirle un límite de gasto o eliminarla. El malware de un portátil puede robar una clave guardada en ese mismo equipo. Elige una clave de 7 o 30 días y deja activada la opción “Aprobación de IP nuevas”: una copia de la clave no funcionará desde otra dirección y caducará pronto.

Preguntas frecuentes

¿Quedaron expuestas las claves guardadas en la CLI de OpenCode?

No. Según OpenCode, la brecha se limitó a OpenCode Console. Las claves añadidas en la CLI local o en la aplicación de escritorio se guardan en el equipo del usuario y nunca se envían a OpenCode.

¿Eliminar una clave de proveedor de una herramienta alojada la revoca?

No. Eliminarla de una herramienta solo borra la copia que tiene esa herramienta. La clave sigue funcionando en el proveedor hasta que la revoques en su panel y crees otra.

¿El límite de gasto de un gateway protege una clave de proveedor filtrada?

No. Los límites de un gateway solo contabilizan las solicitudes que pasan por él. Una clave de proveedor filtrada se usa directamente contra el proveedor, así que el límite que se aplica es el del propio proveedor.

Relacionado: Trusted IPs, BYOK Vault, claves de administrador y límites por clave, configuración de OpenCode.

Fuentes consultadas el 21 de octubre de 2026: publicaciones y correos de OpenCode citados por la prensa, publicaciones de empleados de los proveedores y documentación de los proveedores enlazada arriba. La prueba con la cabecera falsificada se realizó contra el gateway de producción de Synthorai el 21 de octubre de 2026.

← Volver al blog